回复: Non-reproducible binaries generated by GenFw


gaoliming
 

Ross:
I verify -z option. It can remove DEBUG entry and make sure the generated image be reproduced.

PlatformPkg.dsc:

[BuildOptions]
RELEASE_*_*_GENFW_FLAGS = -z

Thanks
Liming

-----邮件原件-----
发件人: Ross Burton <ross@burtonini.com>
发送时间: 2021年3月11日 3:36
收件人: discuss@edk2.groups.io
抄送: bob.c.feng@intel.com; gaoliming@byosoft.com.cn;
yuwei.chen@intel.com
主题: Non-reproducible binaries generated by GenFw

Hi,

As per https://bugzilla.tianocore.org/show_bug.cgi?id=3256, GenFw
writes non-reproducible binaries by embedding a build path. In fact in
a build of ovmf with embedded shell, this one path is the sole source
of non-determinism.

WriteDebug64() is always called in GenFw on output and that embeds
into the NB10 entry the input filename. As build paths change this is
a source of non-determinism. There already exists a --zero option to
wipe out debug paths but this is in release builds so I'm not sure
what the best solution is. I can see several options:

1) Release builds should not call WriteDebug64() at all
2) --zero should wipe the NB10 entry, and release builds should pass that
3) GenFw should support path remapping (like gcc's -ffile-prefix-map)
to turn build paths into something consistent.

Any suggestions?

Cheers,
Ross


Laszlo Ersek
 

Hi Liming,

On 03/11/21 05:44, gaoliming wrote:
Ross:
I verify -z option. It can remove DEBUG entry and make sure the generated image be reproduced.
I tried the "--zero" option myself (as seen in the BZ), but it didn't
work. What I did was the following: in the original run of the "build"
utility, I redirected the standard output and the standard error to a
log file. Then, I located the "GenFw" invocation that produced the
"Shell.efi" binary from the "Shell.dll" file. I also checked that the
"Shell.dll" file did not contain the full pathname, embedded -- so it
was GenFw that embedded the full file path indeed.

Then, I re-run the GenFw utility myself, interactively, and added the
"--zero" flag to the command line. The output did not change,
"Shell.efi" still contained the full pathname embedded. I also couldn't
find a spot in the GenFw source code where "--zero" would have prevented
a call to WriteDebug64(), or otherwise eliminated the NB10 entry.

... So at this point I'm not sure if I simply messed up my testing. :(

Ross -- can you please confirm? Does Liming's suggestion work for you?

Thanks,
Laszlo


PlatformPkg.dsc:

[BuildOptions]
RELEASE_*_*_GENFW_FLAGS = -z

Thanks
Liming
-----邮件原件-----
发件人: Ross Burton <ross@burtonini.com>
发送时间: 2021年3月11日 3:36
收件人: discuss@edk2.groups.io
抄送: bob.c.feng@intel.com; gaoliming@byosoft.com.cn;
yuwei.chen@intel.com
主题: Non-reproducible binaries generated by GenFw

Hi,

As per https://bugzilla.tianocore.org/show_bug.cgi?id=3256, GenFw
writes non-reproducible binaries by embedding a build path. In fact in
a build of ovmf with embedded shell, this one path is the sole source
of non-determinism.

WriteDebug64() is always called in GenFw on output and that embeds
into the NB10 entry the input filename. As build paths change this is
a source of non-determinism. There already exists a --zero option to
wipe out debug paths but this is in release builds so I'm not sure
what the best solution is. I can see several options:

1) Release builds should not call WriteDebug64() at all
2) --zero should wipe the NB10 entry, and release builds should pass that
3) GenFw should support path remapping (like gcc's -ffile-prefix-map)
to turn build paths into something consistent.

Any suggestions?

Cheers,
Ross






Ross Burton
 

On Thu, 11 Mar 2021 at 17:30, Laszlo Ersek <lersek@redhat.com> wrote:
Ross -- can you please confirm? Does Liming's suggestion work for you?
If I manually call GenFw with -z then it does in fact work. Proof via
diffoscope:

https://try.diffoscope.org/takcczugyxzr.html

I'm failing at making this actually stick in the makefiles though...

Ross


Laszlo Ersek
 

On 03/11/21 20:37, Ross Burton wrote:
On Thu, 11 Mar 2021 at 17:30, Laszlo Ersek <lersek@redhat.com> wrote:
Ross -- can you please confirm? Does Liming's suggestion work for you?
If I manually call GenFw with -z then it does in fact work. Proof via
diffoscope:

https://try.diffoscope.org/takcczugyxzr.html

I'm failing at making this actually stick in the makefiles though...
Can you provide your platform DSC file?

What is your exact "build" command line? (I'm looking for the "-a",
"-b", "-t" options.)

Thanks
Laszlo


Ross Burton
 

On Fri, 12 Mar 2021 at 18:37, Laszlo Ersek <lersek@redhat.com> wrote:
I'm failing at making this actually stick in the makefiles though...
Can you provide your platform DSC file?

What is your exact "build" command line? (I'm looking for the "-a",
"-b", "-t" options.)
Essentially, OvmfPkg/build.sh -a X86 -b RELEASE -t GCC5. It appears I
should be editing OvmfPkg/OvmfX86.dsc instead of ShellPkg.dsc.

Is it agreed that this should be fixed? Is putting
RELEASE_*_*_GENFW_FLAGS=-z all over the repository the right solution,
or is there a better solution that can be done once centrally?

Ross


Laszlo Ersek
 

On 03/15/21 18:40, Ross Burton wrote:
On Fri, 12 Mar 2021 at 18:37, Laszlo Ersek <lersek@redhat.com> wrote:
I'm failing at making this actually stick in the makefiles though...
Can you provide your platform DSC file?

What is your exact "build" command line? (I'm looking for the "-a",
"-b", "-t" options.)
Essentially, OvmfPkg/build.sh -a X86 -b RELEASE -t GCC5. It appears I
should be editing OvmfPkg/OvmfX86.dsc instead of ShellPkg.dsc.

Is it agreed that this should be fixed? Is putting
RELEASE_*_*_GENFW_FLAGS=-z all over the repository the right solution,
or is there a better solution that can be done once centrally?
I'm a bit torn myself (I can't imagine a good reason why we *wouldn't*
want to make --zero the default for GenFw in RELEASE builds).

But: if you post such a patch for OVMF (modifying *all* DSC files in
OvmfPkg), then I'll review & merge it.

OvmfPkg/AmdSev/AmdSevX64.dsc
OvmfPkg/Bhyve/BhyveX64.dsc
OvmfPkg/OvmfPkgIa32.dsc
OvmfPkg/OvmfPkgIa32X64.dsc
OvmfPkg/OvmfPkgX64.dsc
OvmfPkg/OvmfXen.dsc

Thanks
Laszlo


Ross Burton
 

On Tue, 16 Mar 2021 at 16:15, Laszlo Ersek <lersek@redhat.com> wrote:
But: if you post such a patch for OVMF (modifying *all* DSC files in
OvmfPkg), then I'll review & merge it.
Is there any documentation for the dsc format? Specifically if a dsc
already has:

!if $(SOURCE_DEBUG_ENABLE) == TRUE
INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable
!endif

Can I just do:
RELEASE_*_*_GENFW_FLAGS = --zero

Or do I need to use += or something else?

Ross