Date
1 - 7 of 7
回复: 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
toggle quoted message
Show quoted text
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@...>
发送时间: 2021年3月11日 3:36
收件人: discuss@edk2.groups.io
抄送: bob.c.feng@...; gaoliming@...;
yuwei.chen@...
主题: 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:
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
On 03/11/21 05:44, gaoliming wrote:
Ross:I tried the "--zero" option myself (as seen in the BZ), but it didn't
I verify -z option. It can remove DEBUG entry and make sure the generated image be reproduced.
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@...>
发送时间: 2021年3月11日 3:36
收件人: discuss@edk2.groups.io
抄送: bob.c.feng@...; gaoliming@...;
yuwei.chen@...
主题: 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 <ross@...>
On Thu, 11 Mar 2021 at 17:30, Laszlo Ersek <lersek@...> wrote:
diffoscope:
https://try.diffoscope.org/takcczugyxzr.html
I'm failing at making this actually stick in the makefiles though...
Ross
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:
What is your exact "build" command line? (I'm looking for the "-a",
"-b", "-t" options.)
Thanks
Laszlo
On Thu, 11 Mar 2021 at 17:30, Laszlo Ersek <lersek@...> wrote:Can you provide your platform DSC file?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...
What is your exact "build" command line? (I'm looking for the "-a",
"-b", "-t" options.)
Thanks
Laszlo
Ross Burton <ross@...>
On Fri, 12 Mar 2021 at 18:37, Laszlo Ersek <lersek@...> wrote:
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
Essentially, OvmfPkg/build.sh -a X86 -b RELEASE -t GCC5. It appears II'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.)
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:
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
On Fri, 12 Mar 2021 at 18:37, Laszlo Ersek <lersek@...> wrote:I'm a bit torn myself (I can't imagine a good reason why we *wouldn't*Essentially, OvmfPkg/build.sh -a X86 -b RELEASE -t GCC5. It appears II'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.)
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?
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 <ross@...>
On Tue, 16 Mar 2021 at 16:15, Laszlo Ersek <lersek@...> wrote:
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
But: if you post such a patch for OVMF (modifying *all* DSC files inIs there any documentation for the dsc format? Specifically if a dsc
OvmfPkg), then I'll review & merge it.
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