Commit Graph

8 Commits

Author SHA1 Message Date
Ard Biesheuvel 3cf41b8728 BaseTools: GCC: move most AutoGen.obj contents back to .data section
The generated AutoGen.c files mostly contain read-only data, but due to
lacking annotations, all of it is emitted into the .data section by the
compiler.

Given that GUIDs are UEFI's gaffer tape, having writable GUIDs is a
security hazard, and this was the main rationale for putting AutoGen.obj
in the .text section. However, as it turns out, patchable PCDs are emitted
there as well, which can legally be modified at runtime.

So update the wildcard pattern to only match g...Guid sections, and move
everything else back to .data (Note that this relies on -fdata-sections,
without that option, everything is emitted into .data)

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Fixes: 233bd25b00
[lersek@redhat.com: add reference to previous commit being fixed up]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2017-02-24 11:27:56 +01:00
Ard Biesheuvel 669a7562cb BaseTools/GccBase.lds: don't copy RELA section to PE/COFF
The CLANG38 toolchain creates a PIE binary at link time. This is
necessary since the LTO code generation may otherwise result in
code that cannot execute correctly when loaded above 2 GB.

PIE executables contain a RELA section consisting of dynamic
relocation entries that are intended for consumption by the loader
at runtime. For this reason, it has the SHF_ALLOC attribute set by
default, and will be identified by GenFw as a section that needs to
be copied into the PE/COFF binary, resulting in waste of space since
the PE/COFF loader does not use this data at all.

So mark the RELA section as informational: this will prevent the
linker from setting the SHF_ALLOC attribute, causing GenFw to
ignore it.

DxeCore.efi before:

    Detected 'X64' type PE/COFF image consisting of 3 sections
    Section alignment:      0x40
    File alignment:         0x40
    Section '.text' @ 0x00000240
    File offset:            0x240
    Virtual size:           0x21000
    Raw size:               0x21000
    Section '.data' @ 0x00021240
    File offset:            0x21240
    Virtual size:           0x3640
    Raw size:               0x3640
    Section '.reloc' @ 0x00024880
    File offset:            0x24880
    Virtual size:           0x280
    Raw size:               0x280

DxeCore.efi after:

    Detected 'X64' type PE/COFF image consisting of 3 sections
    Section alignment:      0x40
    File alignment:         0x40
    Section '.text' @ 0x00000240
    File offset:            0x240
    Virtual size:           0x1f440
    Raw size:               0x1f440
    Section '.data' @ 0x0001f680
    File offset:            0x1f680
    Virtual size:           0x3640
    Raw size:               0x3640
    Section '.reloc' @ 0x00022cc0
    File offset:            0x22cc0
    Virtual size:           0x280
    Raw size:               0x280

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-08-22 12:26:42 +02:00
Ard Biesheuvel 7fd5d61980 BaseTools GCC: drop GNU notes section from EFI image
Recent versions of GNU ld automatically emit a .notes section into
the ELF binary containing a build id. Since this is an allocatable
section by default, it will be identified by GenFw as a section
that requires PE/COFF conversion, which may cause sections to be
moved around unexpectedly.

So retain the section, but tag it as INFO, which tells the linker
that it should not be accounted for in the binary's memory layout.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-08-02 10:54:11 +02:00
Thomas Palmer 03630a8148 Preserve hii section in GCC binaries
According to UEFI spec:
Once an image is loaded, LoadImage() installs
EFI_HII_PACKAGE_LIST_PROTOCOL on the handle if the image contains a
custom PE/COFF resource with the type 'HII'. The protocol's
interface pointer points to the HII package list which is contained
in the resource's data.

This is controlled by the UEFI_HII_RESOURCE_SECTION define in the INF
file.  When present the HII resource is linked with the module
binary.

Unfortunately GCC-built binaries have been stripping the .hii section
entirely.  See  "[edk2] HII gEfiHiiPackageListProtocolGuid problem
with  GCC48(VS2012x86 works)"
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/13438
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/14899

This patch tells the linker to preserve the .hii sections

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Palmer <thomas.palmer@hpe.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Bruce Cran <bruce.cran@gmail.com>
Reviewed-by: Bruce Cran <bruce.cran@gmail.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-07-26 10:21:45 +08:00
Ard Biesheuvel 214a3b7941 BaseTools GCC: avoid the use of COMMON symbols
The default behavior of the GCC compiler is to emit uninitialized globals
with external linkage into a COMMON section, where duplicate definitions
are merged. This may result in unexpected behavior, since global variables
defined under the same name in different C files may not refer to the same
logical data item.

For instance, the definitions of EFI_EVENT mVirtualAddressChangeEvent that
[used to] appear in the following files:

  CryptoPkg/Library/BaseCryptLib/SysCall/RuntimeMemAllocation.c
  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c

will be folded into a single instance of the variable when the latter
module includes the former library, which can lead to unexpected results.

Even if some may argue that there are legal uses for COMMON allocation, the
high modularity of EDK2 combined with the low level of awareness of the
intracicies surrounding common allocation and the generally poor EDK2
developer discipline regarding the use of the STATIC keyword* make a strong
case for disabling it by default, and re-enabling it explicitly for packages
that depend on it.

So prevent GCC from emitting variables into the COMMON section, by passing
-fno-common to the compiler, and discarding the section in the GNU ld linker
script.

* Any function or variable that is only referenced from the translation unit
  that defines it could be made STATIC. This does not only prevent issues
  like the above, it also allows the compiler to generate better code, e.g.,
  drop out of line function definitions after inlining all invocations or
  perform constant propagation on variables.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19164 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-08 07:40:12 +00:00
Ard Biesheuvel 233bd25b00 BaseTools GCC: move AutoGen.obj contents to .text section
All AutoGen.obj files consist of global GUID definitions, fixed
and patchable PCDs and other data that is essentially read-only at
runtime but has not been declared as such for various reasons.

By moving these contents to .text we achieve two things:
- global GUIDs and other data items which must be constant for correct
  program operation can no longer be modified, for instance, when
  running a DXE_RUNTIME_MODULE binary under the OS with the Properties
  Table feature for memory protection enabled;
- the .data section becomes smaller, and may be dropped completely for
  many XIP modules, which reduces wasted FV space if the PE/COFF section
  alignment is large.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Liming Gao <liming.gao@intel.com>
Tested-by: Leif Lindholm <leif.lindholm@linaro.org>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18137 6f19259b-4bc3-4df7-8a09-765794883524
2015-08-03 08:22:50 +00:00
Ard Biesheuvel 56948ba190 BaseTools GCC: align start of .data to .text alignment
Now that GenFw honors the ELF section alignment when placing the
PE/COFF sections in the output, the start of the PE/COFF version of
.data will be aligned to the alignment of .text if its alignment is
higher than the default. So duplicate this behavior in the ELF output,
this will make the memory layout of the PE/COFF binary match the
layout of the ELF version more closely.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Liming Gao <liming.gao@intel.com>
Tested-by: Leif Lindholm <leif.lindholm@linaro.org>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18136 6f19259b-4bc3-4df7-8a09-765794883524
2015-08-03 08:22:39 +00:00
Ard Biesheuvel efe690cab3 BaseTools GCC: add unified GCC linker script for all archs and versions
This unifies all GCC linker scripts into a single parametrised GCC
linker script that can be used for all GCC versions and architectures.

The two parameters that can be set on the linker command line are:
- PECOFF_HEADER_SIZE, this is a build time property of GenFw, but
  its value is different between 32-bit and 64-bit;
- common-page-size, this can be set using -z on the ld command line,
  and controls the value of the COMMONPAGESIZE constant when used in
  a linker script. This value is used for the minimum section alignment.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Liming Gao <liming.gao@intel.com>
Tested-by: Leif Lindholm <leif.lindholm@linaro.org>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18135 6f19259b-4bc3-4df7-8a09-765794883524
2015-08-03 08:22:28 +00:00