public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "gaoliming" <gaoliming@byosoft.com.cn>
To: <devel@edk2.groups.io>, <afish@apple.com>, <ross@burtonini.com>
Cc: <lersek@redhat.com>
Subject: 回复: [edk2-devel] [PATCH v2] OvmfPkg: strip build paths in release builds
Date: Thu, 25 Mar 2021 10:24:29 +0800	[thread overview]
Message-ID: <00b301d7211d$fc148390$f43d8ab0$@byosoft.com.cn> (raw)
In-Reply-To: <A984AFFA-910A-450F-A4E4-35E816B3298F@apple.com>

[-- Attachment #1: Type: text/plain, Size: 6662 bytes --]

Andrew:

 GenFw generates debug entry, and zero debug entry. Its functionality is same to the image without debug entry. So, new option is not introduced to control whether GenFw generates debug entry when it converts ELF image to EFI image. 

 

Thanks

Liming

发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Andrew Fish via groups.io
发送时间: 2021年3月25日 7:26
收件人: edk2-devel-groups-io <devel@edk2.groups.io>; ross@burtonini.com
抄送: lersek@redhat.com
主题: Re: [edk2-devel] [PATCH v2] OvmfPkg: strip build paths in release builds

 

This breaks some usage we have have in our fork. We have symbols turned on for Release builds, so this change would break that. 

 

It looks to me that the root cause of this issue might be that the GenFw is blindly writing the debug directory entry into the PE/COFF? For native PE/COFF I think this is controlled by linker flags? For Xcode/clang it is controlled by the *_XCODE5_*_MTOC_FLAGS. So at this point it is kind of up to each toolchain how they want to deal with symbols on release builds. 

 

 

It seems kind of strange to insert a section and then zero it. Almost seems like the intent of —zero was to post process compare images? 





  -z, --zero            Zero the Debug Data Fields in the PE input image file.

                        It also zeros the time stamp fields.

                        This option can be used to compare the binary efi image.

                        It can't be combined with other action options

                        except for -o, -r option. It is a action option.

                        If it is combined with other action options, the later

                        input action option will override the previous one.





And in case you are going to ask our fork uses relative paths from the Build directory and/or a UUID string for the Debug Directory entry file name so it is a constant value and does not impact build reproducibility. 





>From a feature stand point this change will break any hope of source level debugging with RELEASE builds. I also think it changes the exception handler code output in OVMF [1] for ELF toolchains. You are going to get the (No PDB) vs. the file and path you were getting today. I assume if you had tools that natively produce PE/COFF and did not have a Debug Directory entry the same thing would happen prior to this change. 





	
    Status = PeCoffLoaderGetEntryPoint ((VOID *) Pe32Data, &EntryPoint);

	
    if (EFI_ERROR (Status)) {

	
      EntryPoint = NULL;

	
    }

	
    InternalPrintMessage ("!!!! Find image based on IP(0x%x) ", CurrentEip);

	
    PdbPointer = PeCoffLoaderGetPdbPointer ((VOID *) Pe32Data);

	
    if (PdbPointer != NULL) {

	
      InternalPrintMessage ("%a", PdbPointer);

	
    } else {

	
      InternalPrintMessage ("(No PDB) " );

	
    }

	
    InternalPrintMessage (

	
      " (ImageBase=%016lp, EntryPoint=%016p) !!!!\n",

	
      (VOID *) Pe32Data,

	
      EntryPoint

	
      );

		





Not saying we have to "stop the presses", but just trying to point out the side effects of this change. It is not so much that this change is bad, but that we have no way to turn off the Debug Directory Entry for ELF conversion, so we seem to be working around that issue with a bigger hammer?

 

[1] https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c#L117

 

Thanks,





Andrew Fish





On Mar 24, 2021, at 4:58 AM, Ross Burton <ross@burtonini.com <mailto:ross@burtonini.com> > wrote:

 

GenFw will embed a NB10 section which contains the path to the input file,
which means the output files have build paths embedded in them.  To reduce
information leakage and ensure reproducible builds, pass --zero in release
builds to remove this information.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3256
Signed-off-by: Ross Burton <ross.burton@arm.com <mailto:ross.burton@arm.com> >
---
OvmfPkg/AmdSev/AmdSevX64.dsc | 1 +
OvmfPkg/Bhyve/BhyveX64.dsc   | 1 +
OvmfPkg/OvmfPkgIa32.dsc      | 1 +
OvmfPkg/OvmfPkgIa32X64.dsc   | 1 +
OvmfPkg/OvmfPkgX64.dsc       | 1 +
OvmfPkg/OvmfXen.dsc          | 1 +
6 files changed, 6 insertions(+)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index 65c42284d9..69a05feea9 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -78,6 +78,7 @@
  GCC:*_*_X64_GENFW_FLAGS   = --keepexceptiontable
  INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable
!endif
+  RELEASE_*_*_GENFW_FLAGS = --zero

  #
  # Disable deprecated APIs.
diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index 4a1cdf5aca..132f55cf69 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -76,6 +76,7 @@
  GCC:*_*_X64_GENFW_FLAGS   = --keepexceptiontable
  INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable
!endif
+  RELEASE_*_*_GENFW_FLAGS = --zero

  #
  # Disable deprecated APIs.
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 1eaf3e99c6..93c209950c 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -80,6 +80,7 @@
!if $(TOOL_CHAIN_TAG) != "XCODE5" && $(TOOL_CHAIN_TAG) != "CLANGPDB"
  GCC:*_*_*_CC_FLAGS                   = -mno-mmx -mno-sse
!endif
+  RELEASE_*_*_GENFW_FLAGS = --zero

  #
  # Disable deprecated APIs.
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 4a5a430147..97cc438250 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -84,6 +84,7 @@
  GCC:*_*_X64_GENFW_FLAGS   = --keepexceptiontable
  INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable
!endif
+  RELEASE_*_*_GENFW_FLAGS = --zero

  #
  # Disable deprecated APIs.
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index d4d601b444..f544fb04bf 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -84,6 +84,7 @@
  GCC:*_*_X64_GENFW_FLAGS   = --keepexceptiontable
  INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable
!endif
+  RELEASE_*_*_GENFW_FLAGS = --zero

  #
  # Disable deprecated APIs.
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 507029404f..fcaa35acf1 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -74,6 +74,7 @@
  GCC:*_*_X64_GENFW_FLAGS   = --keepexceptiontable
  INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable
!endif
+  RELEASE_*_*_GENFW_FLAGS = --zero

  #
  # Disable deprecated APIs.
-- 
2.25.1







 




[-- Attachment #2: Type: text/html, Size: 24078 bytes --]

  reply	other threads:[~2021-03-25  2:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-24 11:58 [PATCH v2] OvmfPkg: strip build paths in release builds Ross Burton
2021-03-24 22:23 ` [edk2-devel] " Laszlo Ersek
2021-03-24 23:25 ` Andrew Fish
2021-03-25  2:24   ` gaoliming [this message]
2021-03-25  3:38     ` Andrew Fish
2021-03-25  3:47       ` Andrew Fish
2021-03-25 17:26         ` Laszlo Ersek
2021-03-25 17:19   ` Laszlo Ersek
2021-03-25 19:43     ` Andrew Fish

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='00b301d7211d$fc148390$f43d8ab0$@byosoft.com.cn' \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox