| Age | Commit message (Collapse) | Author |
|---|
|
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 <pjones@redhat.com>
Co-authored-by: Kamil Aronowski <kamil.aronowski@yahoo.com>
Signed-off-by: Dennis Tseng <dennis.tseng@suse.com>
|
|
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 <pjones@redhat.com>
|
|
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 <pjones@redhat.com>
|
|
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 <pjones@redhat.com>
|
|
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 <pjones@redhat.com>
|
|
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 <steve@einval.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
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 <amodra@gmail.com>
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 <pjones@redhat.com>
|
