efi-boot-shim.git/post-process-pe.c, branch rolling

post-process-pe: add tests to validate NX compliance

2025-02-18T15:47:34+00:00

This changes post-process-pe to give warnings, and optionally errors, if a shim binary is built with Section Alignment or characteristics are not compatible with NX, or if the EFI_IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag is not set and require_nx_compat is true. Co-authored-by: Peter Jones Co-authored-by: Kamil Aronowski Signed-off-by: Dennis Tseng

post-process-pe: Don't set the NX_COMPAT flag by default after all.

2024-01-22T19:17:20+00:00

We thought we would fully support NX compatibility in the full stack for this release, but all of the necessary components aren't *quite* ready for this release. This patch switches back the default that was changed in a53b9f7ceec1d, but it leaves the build infrastructure in place. Signed-off-by: Peter Jones

Enable the NX compatibility flag by default.

2023-01-27T18:03:31+00:00

Currently by default, when we build shim we do not set the PE NX-compatibility DLL Characteristic flag. This signifies to the firmware that shim (including the components it loads) is not prepared for several related firmware changes: - non-executable stack - non-executable pages from AllocatePages()/AllocatePool()/etc. - non-writable 0 page (not strictly related but some firmware will be transitioning at the same time) - the need to use the UEFI 2.10 Memory Attribute Protocol to set page permissions. This patch changes that default to be enabled by default. Distributors of shim will need to ensure that either their builds disable this bit (using "post-process-pe -N"), or that the bootloaders and kernels you support loading are all compliant with this change. A new make variable, POST_PROCESS_PE_FLAGS, has been added to simplify doing so. Signed-off-by: Peter Jones

post-process-pe: set EFI_IMAGE_DLLCHARACTERISTICS_NX_COMPAT

2022-05-17T23:01:03+00:00

Currently, system firmware has no means to discover that an EFI Application is compatible with the security feature variously known as NX or w^x. Since at least Revision 8.1, the PE spec supports setting a flag the Optional Header's DllCharacteristics field to inform loaders that an application supports being loaded with NX enabled. In the case of UEFI, there are several things that should be enabled if this flag is set: - EFI_BOOT_SERVICES.AllocatePages() with MemoryType = EfiLoaderCode, EfiBootServicesCode, EfiRuntimeServicesCode, etc, currently must set memory as rwx. This flag set implies that rw- is appropriate, and that the application knows how to use the EFI_MEMORY_ATTRIBUTE protocol to change that to r-x. - EFI_BOOT_SERVICES.AllocatePool() - same as AllocatePages() - EFI_BOOT_SERVICES.LoadImage() - currently must set the stack as rwx. This flag states that it is allowed to be rw- - currently a binary can probably have writable PLTs? This flag allows the loader to not set them writable - I have heard that some firmwares have the 0 page mapped rwx. Obviously this should not be done. Signed-off-by: Peter Jones

post-process-pe: there is no 's' argument.

2022-05-17T23:01:03+00:00

There is no 's' argument to post-process-pe, so we shouldn't tell getopt that there is. This patch takes the 's' out of the getopt short option list. Signed-off-by: Peter Jones

post-process-pe: Fix format string warnings on 32-bit platforms

2022-05-04T18:54:49+00:00

With -Werror these were causing build failures with stricter gcc: .../post-process-pe.c: In function 'load_pe': .../post-process-pe.c:177:55: error: format '%ld' expects argument of type 'long int', but argument 4 has type 'size_t' {aka 'unsigned int'} [-Werror=format=] .../post-process-pe.c:192:56: error: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'UINT64' {aka 'long long unsigned int'} [-Werror=format=] .../post-process-pe.c:236:31: error: format '%zu' expects argument of type 'size_t', but argument 2 has type 'UINT64' {aka 'long long unsigned int'} [-Werror=format=] .../post-process-pe.c:39:32: note: in definition of macro 'debug' .../post-process-pe.c:236:60: note: format string is defined here .../post-process-pe.c:240:31: error: format '%zu' expects argument of type 'size_t', but argument 2 has type 'UINT64' {aka 'long long unsigned int'} [-Werror=format=] .../post-process-pe.c:39:32: note: in definition of macro 'debug' .../post-process-pe.c:240:60: note: format string is defined here .../post-process-pe.c:274:30: error: format '%zu' expects argument of type 'size_t', but argument 2 has type 'UINTN' {aka 'long unsigned int'} [-Werror=format=] .../post-process-pe.c:39:32: note: in definition of macro 'debug' .../post-process-pe.c:274:34: note: format string is defined here Signed-off-by: Steve McIntyre

post-process-pe: Fix a missing return code check

2022-04-19T19:46:41+00:00

Signed-off-by: Peter Jones

Post-process our PE to be sure.

2021-05-25T15:03:26+00:00

On some versions of binutils[0], including binutils-2.23.52.0.1-55.el7, do not correctly initialize the data when computing the PE optional header checksum. Unfortunately, this means that any time you get a build that reproduces correctly using the version of objcopy from those versions, it's just a matter of luck. This patch introduces a new utility program, post-process-pe, which does some basic validation of the resulting binaries, and if necessary, performs some minor repairs: - sets the timestamp to 0 - this was previously done with dd using constant offsets that aren't really safe. - re-computes the checksum. [0] I suspect, but have not yet fully verified, that this is accidentally fixed by the following upstream binutils commit: commit cf7a3c01d82abdf110ef85ab770e5997d8ac28ac Author: Alan Modra Date: Tue Dec 15 22:09:30 2020 +1030 Lose some COFF/PE static vars, and peicode.h constify This patch tidies some COFF and PE code that unnecessarily used static variables to communicate between functions. v2 - MAP_PRIVATE was totally wrong... Signed-off-by: Peter Jones