#
891f8890 |
| 16-Jan-2024 |
Ard Biesheuvel <ardb@kernel.org> |
efi/x86: Set the PE/COFF header's NX compat flag unconditionally
Now that the proper section and file alignment is used, and the EFI memory attributes protocol to manage executable permissions where
efi/x86: Set the PE/COFF header's NX compat flag unconditionally
Now that the proper section and file alignment is used, and the EFI memory attributes protocol to manage executable permissions where needed is invoked, set the NX compat flag unconditionally.
[ bp: Remove the "we"s. ]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20240116085347.2193966-2-ardb+git@google.com
show more ...
|
#
1ad55cec |
| 05-Feb-2024 |
Ard Biesheuvel <ardb@kernel.org> |
x86/efistub: Use 1:1 file:memory mapping for PE/COFF .compat section
The .compat section is a dummy PE section that contains the address of the 32-bit entrypoint of the 64-bit kernel image if it is
x86/efistub: Use 1:1 file:memory mapping for PE/COFF .compat section
The .compat section is a dummy PE section that contains the address of the 32-bit entrypoint of the 64-bit kernel image if it is bootable from 32-bit firmware (i.e., CONFIG_EFI_MIXED=y)
This section is only 8 bytes in size and is only referenced from the loader, and so it is placed at the end of the memory view of the image, to avoid the need for padding it to 4k, which is required for sections appearing in the middle of the image.
Unfortunately, this violates the PE/COFF spec, and even if most EFI loaders will work correctly (including the Tianocore reference implementation), PE loaders do exist that reject such images, on the basis that both the file and memory views of the file contents should be described by the section headers in a monotonically increasing manner without leaving any gaps.
So reorganize the sections to avoid this issue. This results in a slight padding overhead (< 4k) which can be avoided if desired by disabling CONFIG_EFI_MIXED (which is only needed in rare cases these days)
Fixes: 3e3eabe26dc8 ("x86/boot: Increase section and file alignment to 4k/512") Reported-by: Mike Beaton <mjsbeaton@gmail.com> Link: https://lkml.kernel.org/r/CAHzAAWQ6srV6LVNdmfbJhOwhBw5ZzxxZZ07aHt9oKkfYAdvuQQ%40mail.gmail.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
3e3eabe2 |
| 15-Sep-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/boot: Increase section and file alignment to 4k/512
Align x86 with other EFI architectures, and increase the section alignment to the EFI page size (4k), so that firmware is able to honour the s
x86/boot: Increase section and file alignment to 4k/512
Align x86 with other EFI architectures, and increase the section alignment to the EFI page size (4k), so that firmware is able to honour the section permission attributes and map code read-only and data non-executable.
There are a number of requirements that have to be taken into account: - the sign tools get cranky when there are gaps between sections in the file view of the image - the virtual offset of each section must be aligned to the image's section alignment - the file offset *and size* of each section must be aligned to the image's file alignment - the image size must be aligned to the section alignment - each section's virtual offset must be greater than or equal to the size of the headers.
In order to meet all these requirements, while avoiding the need for lots of padding to accommodate the .compat section, the latter is placed at an arbitrary offset towards the end of the image, but aligned to the minimum file alignment (512 bytes). The space before the .text section is therefore distributed between the PE header, the .setup section and the .compat section, leaving no gaps in the file coverage, making the signing tools happy.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20230915171623.655440-18-ardb@google.com
show more ...
|
#
34951f3c |
| 15-Sep-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/boot: Split off PE/COFF .data section
Describe the code and data of the decompressor binary using separate .text and .data PE/COFF sections, so that we will be able to map them using restricted
x86/boot: Split off PE/COFF .data section
Describe the code and data of the decompressor binary using separate .text and .data PE/COFF sections, so that we will be able to map them using restricted permissions once we increase the section and file alignment sufficiently. This avoids the need for memory mappings that are writable and executable at the same time, which is something that is best avoided for security reasons.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20230915171623.655440-17-ardb@google.com
show more ...
|
#
fa575052 |
| 15-Sep-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/boot: Drop PE/COFF .reloc section
Ancient buggy EFI loaders may have required a .reloc section to be present at some point in time, but this has not been true for a long time so the .reloc secti
x86/boot: Drop PE/COFF .reloc section
Ancient buggy EFI loaders may have required a .reloc section to be present at some point in time, but this has not been true for a long time so the .reloc section can just be dropped.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20230915171623.655440-16-ardb@google.com
show more ...
|
#
efa089e6 |
| 15-Sep-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/boot: Construct PE/COFF .text section from assembler
Now that the size of the setup block is visible to the assembler, it is possible to populate the PE/COFF header fields from the asm code dire
x86/boot: Construct PE/COFF .text section from assembler
Now that the size of the setup block is visible to the assembler, it is possible to populate the PE/COFF header fields from the asm code directly, instead of poking the values into the binary using the build tool. This will make it easier to reorganize the section layout without having to tweak the build tool in lockstep.
This change has no impact on the resulting bzImage binary.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20230915171623.655440-15-ardb@google.com
show more ...
|
#
aeb92067 |
| 15-Sep-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/boot: Derive file size from _edata symbol
Tweak the linker script so that the value of _edata represents the decompressor binary's file size rounded up to the appropriate alignment. This removes
x86/boot: Derive file size from _edata symbol
Tweak the linker script so that the value of _edata represents the decompressor binary's file size rounded up to the appropriate alignment. This removes the need to calculate it in the build tool, and will make it easier to refer to the file size from the header directly in subsequent changes to the PE header layout.
While adding _edata to the sed regex that parses the compressed vmlinux's symbol list, tweak the regex a bit for conciseness.
This change has no impact on the resulting bzImage binary when configured with CONFIG_EFI_STUB=y.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20230915171623.655440-14-ardb@google.com
show more ...
|
#
093ab258 |
| 15-Sep-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/boot: Define setup size in linker script
The setup block contains the real mode startup code that is used when booting from a legacy BIOS, along with the boot_params/setup_data that is used by l
x86/boot: Define setup size in linker script
The setup block contains the real mode startup code that is used when booting from a legacy BIOS, along with the boot_params/setup_data that is used by legacy x86 bootloaders to pass the command line and initial ramdisk parameters, among other things.
The setup block also contains the PE/COFF header of the entire combined image, which includes the compressed kernel image, the decompressor and the EFI stub.
This PE header describes the layout of the executable image in memory, and currently, the fact that the setup block precedes it makes it rather fiddly to get the right values into the right place in the final image.
Let's make things a bit easier by defining the setup_size in the linker script so it can be referenced from the asm code directly, rather than having to rely on the build tool to calculate it. For the time being, add 64 bytes of fixed padding for the .reloc and .compat sections - this will be removed in a subsequent patch after the PE/COFF header has been reorganized.
This change has no impact on the resulting bzImage binary when configured with CONFIG_EFI_MIXED=y.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20230915171623.655440-13-ardb@google.com
show more ...
|
#
eac95634 |
| 15-Sep-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/boot: Set EFI handover offset directly in header asm
The offsets of the EFI handover entrypoints are available to the assembler when constructing the header, so there is no need to set them from
x86/boot: Set EFI handover offset directly in header asm
The offsets of the EFI handover entrypoints are available to the assembler when constructing the header, so there is no need to set them from the build tool afterwards.
This change has no impact on the resulting bzImage binary.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20230915171623.655440-12-ardb@google.com
show more ...
|
#
2e765c02 |
| 15-Sep-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/boot: Grab kernel_info offset from zoffset header directly
Instead of parsing zoffset.h and poking the kernel_info offset value into the header from the build tool, just grab the value directly
x86/boot: Grab kernel_info offset from zoffset header directly
Instead of parsing zoffset.h and poking the kernel_info offset value into the header from the build tool, just grab the value directly in the asm file that describes this header.
This change has no impact on the resulting bzImage binary.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20230915171623.655440-11-ardb@google.com
show more ...
|
#
7448e8e5 |
| 12-Sep-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/boot: Drop redundant code setting the root device
The root device defaults to 0,0 and is no longer configurable at build time [0], so there is no need for the build tool to ever write to this fi
x86/boot: Drop redundant code setting the root device
The root device defaults to 0,0 and is no longer configurable at build time [0], so there is no need for the build tool to ever write to this field.
[0] 079f85e624189292 ("x86, build: Do not set the root_dev field in bzImage")
This change has no impact on the resulting bzImage binary.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20230912090051.4014114-23-ardb@google.com
show more ...
|
#
8eace5b3 |
| 12-Sep-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/boot: Omit compression buffer from PE/COFF image memory footprint
Now that the EFI stub decompresses the kernel and hands over to the decompressed image directly, there is no longer a need to pr
x86/boot: Omit compression buffer from PE/COFF image memory footprint
Now that the EFI stub decompresses the kernel and hands over to the decompressed image directly, there is no longer a need to provide a decompression buffer as part of the .BSS allocation of the PE/COFF image. It also means the PE/COFF image can be loaded anywhere in memory, and setting the preferred image base is unnecessary. So drop the handling of this from the header and from the build tool.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20230912090051.4014114-22-ardb@google.com
show more ...
|
#
768171d7 |
| 12-Sep-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/boot: Remove the 'bugger off' message
Ancient (pre-2003) x86 kernels could boot from a floppy disk straight from the BIOS, using a small real mode boot stub at the start of the image where the B
x86/boot: Remove the 'bugger off' message
Ancient (pre-2003) x86 kernels could boot from a floppy disk straight from the BIOS, using a small real mode boot stub at the start of the image where the BIOS would expect the boot record (or boot block) to appear.
Due to its limitations (kernel size < 1 MiB, no support for IDE, USB or El Torito floppy emulation), this support was dropped, and a Linux aware bootloader is now always required to boot the kernel from a legacy BIOS.
To smoothen this transition, the boot stub was not removed entirely, but replaced with one that just prints an error message telling the user to install a bootloader.
As it is unlikely that anyone doing direct floppy boot with such an ancient kernel is going to upgrade to v6.5+ and expect that this boot method still works, printing this message is kind of pointless, and so it should be possible to remove the logic that emits it.
Let's free up this space so it can be used to expand the PE header in a subsequent patch.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com> Link: https://lore.kernel.org/r/20230912090051.4014114-21-ardb@google.com
show more ...
|
#
bfab35f5 |
| 12-Sep-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/efi: Drop alignment flags from PE section headers
The section header flags for alignment are documented in the PE/COFF spec as being applicable to PE object files only, not to PE executables suc
x86/efi: Drop alignment flags from PE section headers
The section header flags for alignment are documented in the PE/COFF spec as being applicable to PE object files only, not to PE executables such as the Linux bzImage, so let's drop them from the PE header.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20230912090051.4014114-20-ardb@google.com
show more ...
|
#
ff61f079 |
| 14-Mar-2023 |
Jonathan Corbet <corbet@lwn.net> |
docs: move x86 documentation into Documentation/arch/
Move the x86 documentation under Documentation/arch/ as a way of cleaning up the top-level directory and making the structure of our docs more c
docs: move x86 documentation into Documentation/arch/
Move the x86 documentation under Documentation/arch/ as a way of cleaning up the top-level directory and making the structure of our docs more closely match the structure of the source directories it describes.
All in-kernel references to the old paths have been updated.
Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: linux-arch@vger.kernel.org Cc: x86@kernel.org Cc: Borislav Petkov <bp@alien8.de> Cc: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/lkml/20230315211523.108836-1-corbet@lwn.net/ Signed-off-by: Jonathan Corbet <corbet@lwn.net>
show more ...
|
#
29636a5c |
| 09-Nov-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: Put Linux specific magic number in the DOS header
GRUB currently relies on the magic number in the image header of ARM and arm64 EFI kernel images to decide whether or not the image in question
efi: Put Linux specific magic number in the DOS header
GRUB currently relies on the magic number in the image header of ARM and arm64 EFI kernel images to decide whether or not the image in question is a bootable kernel.
However, the purpose of the magic number is to identify the image as one that implements the bare metal boot protocol, and so GRUB, which only does EFI boot, is limited unnecessarily to booting images that could potentially be booted in a non-EFI manner as well.
This is problematic for the new zboot decompressor image format, as it can only boot in EFI mode, and must therefore not use the bare metal boot magic number in its header.
For this reason, the strict magic number was dropped from GRUB, to permit essentially any kind of EFI executable to be booted via the 'linux' command, blurring the line between the linux loader and the chainloader.
So let's use the same field in the DOS header that RISC-V and arm64 already use for their 'bare metal' magic numbers to store a 'generic Linux kernel' magic number, which can be used to identify bootable kernel images in PE format which don't necessarily implement a bare metal boot protocol in the same binary. Note that, in the context of EFI, the MS-DOS header is only described in terms of the fields that it shares with the hybrid PE/COFF image format, (i.e., the MS-DOS EXE magic number at offset #0 and the PE header offset at byte offset #0x3c). Since we aim for compatibility with EFI only, and not with MS-DOS or MS-Windows, we can use the remaining space in the MS-DOS header however we want.
Let's set the generic magic number for x86 images as well: existing bootloaders already have their own methods to identify x86 Linux images that can be booted in a non-EFI manner, and having the magic number in place there will ease any future transitions in loader implementations to merge the x86 and non-x86 EFI boot paths.
Note that 32-bit ARM already uses the same location in the header for a different purpose, but the ARM support is already widely implemented and the EFI zboot decompressor is not available on ARM anyway, so we just disregard it here.
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
cc3fdda2 |
| 22-Nov-2022 |
Ard Biesheuvel <ardb@kernel.org> |
x86/efi: Make the deprecated EFI handover protocol optional
The EFI handover protocol permits a bootloader to invoke the kernel as a EFI PE/COFF application, while passing a bootparams struct as a t
x86/efi: Make the deprecated EFI handover protocol optional
The EFI handover protocol permits a bootloader to invoke the kernel as a EFI PE/COFF application, while passing a bootparams struct as a third argument to the entrypoint function call.
This has no basis in the UEFI specification, and there are better ways to pass additional data to a UEFI application (UEFI configuration tables, UEFI variables, UEFI protocols) than going around the StartImage() boot service and jumping to a fixed offset in the loaded image, just to call a different function that takes a third parameter.
The reason for handling struct bootparams in the bootloader was that the EFI stub could only load initrd images from the EFI system partition, and so passing it via struct bootparams was needed for loaders like GRUB, which pass the initrd in memory, and may load it from anywhere, including from the network. Another motivation was EFI mixed mode, which could not use the initrd loader in the EFI stub at all due to 32/64 bit incompatibilities (which will be fixed shortly [0]), and could not invoke the ordinary PE/COFF entry point either, for the same reasons.
Given that loaders such as GRUB already carried the bootparams handling in order to implement non-EFI boot, retaining that code and just passing bootparams to the EFI stub was a reasonable choice (although defining an alternate entrypoint could have been avoided.) However, the GRUB side changes never made it upstream, and are only shipped by some of the distros in their downstream versions.
In the meantime, EFI support has been added to other Linux architecture ports, as well as to U-boot and systemd, including arch-agnostic methods for passing initrd images in memory [1], and for doing mixed mode boot [2], none of them requiring anything like the EFI handover protocol. So given that only out-of-tree distro GRUB relies on this, let's permit it to be omitted from the build, in preparation for retiring it completely at a later date. (Note that systemd-boot does have an implementation as well, but only uses it as a fallback for booting images that do not implement the LoadFile2 based initrd loading method, i.e., v5.8 or older)
[0] https://lore.kernel.org/all/20220927085842.2860715-1-ardb@kernel.org/ [1] ec93fc371f01 ("efi/libstub: Add support for loading the initrd from a device path") [2] 97aa276579b2 ("efi/x86: Add true mixed mode entry point into .compat section")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/20221122161017.2426828-18-ardb@kernel.org
show more ...
|
#
ca209f8b |
| 01-Jun-2022 |
Lukas Bulwahn <lukas.bulwahn@gmail.com> |
efi: x86: Fix config name for setting the NX-compatibility flag in the PE header
Commit 21b68da7bf4a ("efi: x86: Set the NX-compatibility flag in the PE header") intends to set the compatibility fla
efi: x86: Fix config name for setting the NX-compatibility flag in the PE header
Commit 21b68da7bf4a ("efi: x86: Set the NX-compatibility flag in the PE header") intends to set the compatibility flag, i.e., IMAGE_DLL_CHARACTERISTICS_NX_COMPAT, but this ifdef is actually dead as the CONFIG_DXE_MEM_ATTRIBUTES Kconfig option does not exist.
The config is actually called EFI_DXE_MEM_ATTRIBUTES. Adjust the ifdef to use the intended config name.
The issue was identified with ./scripts/checkkconfigsymbols.py.
Fixes: 21b68da7bf4a ("efi: x86: Set the NX-compatibility flag in the PE header") Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20220601115043.7678-1-lukas.bulwahn@gmail.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
24b72bb1 |
| 29-Mar-2022 |
Peter Jones <pjones@redhat.com> |
efi: x86: Set the NX-compatibility flag in the PE header
Following Baskov Evgeniy's "Handle UEFI NX-restricted page tables" patches, it's safe to set this compatibility flag to let loaders know they
efi: x86: Set the NX-compatibility flag in the PE header
Following Baskov Evgeniy's "Handle UEFI NX-restricted page tables" patches, it's safe to set this compatibility flag to let loaders know they don't need to make special accommodations for kernel to load if pre-boot NX is enabled.
Signed-off-by: Peter Jones <pjones@redhat.com> Link: https://lore.kernel.org/all/20220329184743.798513-1-pjones@redhat.com/ Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
0fe4f4ef |
| 30-Jul-2020 |
Nick Terrell <terrelln@fb.com> |
x86: Bump ZO_z_extra_bytes margin for zstd
Bump the ZO_z_extra_bytes margin for zstd.
Zstd needs 3 bytes per 128 KB, and has a 22 byte fixed overhead. Zstd needs to maintain 128 KB of space at all
x86: Bump ZO_z_extra_bytes margin for zstd
Bump the ZO_z_extra_bytes margin for zstd.
Zstd needs 3 bytes per 128 KB, and has a 22 byte fixed overhead. Zstd needs to maintain 128 KB of space at all times, since that is the maximum block size. See the comments regarding in-place decompression added in lib/decompress_unzstd.c for details.
The existing code is written so that all the compression algorithms use the same ZO_z_extra_bytes. It is taken to be the maximum of the growth rate plus the maximum fixed overhead. The comments just above this diff state that:
Signed-off-by: Nick Terrell <terrelln@fb.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20200730190841.2071656-6-nickrterrell@gmail.com
show more ...
|
#
26725192 |
| 08-Mar-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi/x86: Add kernel preferred address to PE header
Store the kernel's link address as ImageBase in the PE header. Note that the PE specification requires the ImageBase to be 64k aligned. The preferr
efi/x86: Add kernel preferred address to PE header
Store the kernel's link address as ImageBase in the PE header. Note that the PE specification requires the ImageBase to be 64k aligned. The preferred address should almost always satisfy that, except for 32-bit kernel if the configuration has been customized.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200303221205.4048668-4-nivedita@alum.mit.edu Link: https://lore.kernel.org/r/20200308080859.21568-18-ardb@kernel.org
show more ...
|
#
148d3f71 |
| 20-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Introduce symbolic constants for the stub major/minor version
Now that we have added new ways to load the initrd or the mixed mode kernel, we will also need a way to tell the loader abo
efi/libstub: Introduce symbolic constants for the stub major/minor version
Now that we have added new ways to load the initrd or the mixed mode kernel, we will also need a way to tell the loader about this. Add symbolic constants for the PE/COFF major/minor version numbers (which fortunately have always been 0x0 for all architectures), so that we can bump them later to document the capabilities of the stub.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
a3326a0d |
| 20-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/x86: Use symbolic constants in PE header instead of bare numbers
Replace bare numbers in the PE/COFF header structure with symbolic constants so they become self documenting.
Signed-off-by: Ard
efi/x86: Use symbolic constants in PE header instead of bare numbers
Replace bare numbers in the PE/COFF header structure with symbolic constants so they become self documenting.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
97aa2765 |
| 12-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/x86: Add true mixed mode entry point into .compat section
Currently, mixed mode is closely tied to the EFI handover protocol and relies on intimate knowledge of the bootparams structure, setup h
efi/x86: Add true mixed mode entry point into .compat section
Currently, mixed mode is closely tied to the EFI handover protocol and relies on intimate knowledge of the bootparams structure, setup header etc, all of which are rather byzantine and entirely specific to x86.
Even though no other EFI supported architectures are currently known that could support something like mixed mode, it still makes sense to abstract a bit from this, and make it part of a generic Linux on EFI boot protocol.
To that end, add a .compat section to the mixed mode binary, and populate it with the PE machine type and entry point address, allowing firmware implementations to match it to their native machine type, and invoke non-native binaries using a secondary entry point.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
832187f0 |
| 12-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/x86: Drop redundant .bss section
In commit
c7fb93ec51d462ec ("x86/efi: Include a .bss section within the PE/COFF headers")
we added a separate .bss section to the PE/COFF header of the compr
efi/x86: Drop redundant .bss section
In commit
c7fb93ec51d462ec ("x86/efi: Include a .bss section within the PE/COFF headers")
we added a separate .bss section to the PE/COFF header of the compressed kernel describing the static memory footprint of the decompressor, to ensure that it has enough headroom to decompress itself.
We can achieve the exact same result by increasing the virtual size of the .text section, without changing the raw size, which, as per the PE/COFF specification, requires the loader to zero initialize the delta.
Doing so frees up a slot in the section table, which we will use later to describe the mixed mode entrypoint.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|