<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/x86/boot/header.S, branch linux-6.15.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.15.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.15.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2024-02-28T13:23:55Z</updated>
<entry>
<title>efi/x86: Set the PE/COFF header's NX compat flag unconditionally</title>
<updated>2024-02-28T13:23:55Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2024-01-16T08:53:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=891f8890a4a3663da7056542757022870b499bc1'/>
<id>urn:sha1:891f8890a4a3663da7056542757022870b499bc1</id>
<content type='text'>
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 &lt;ardb@kernel.org&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Link: https://lore.kernel.org/r/20240116085347.2193966-2-ardb+git@google.com
</content>
</entry>
<entry>
<title>x86/efistub: Use 1:1 file:memory mapping for PE/COFF .compat section</title>
<updated>2024-02-05T10:24:51Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2024-02-05T08:11:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1ad55cecf22f05f1c884adf63cc09d3c3e609ebf'/>
<id>urn:sha1:1ad55cecf22f05f1c884adf63cc09d3c3e609ebf</id>
<content type='text'>
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 (&lt; 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 &lt;mjsbeaton@gmail.com&gt;
Link: https://lkml.kernel.org/r/CAHzAAWQ6srV6LVNdmfbJhOwhBw5ZzxxZZ07aHt9oKkfYAdvuQQ%40mail.gmail.com
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/boot: Increase section and file alignment to 4k/512</title>
<updated>2023-09-17T17:48:44Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2023-09-15T17:16:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3e3eabe26dc88692d34cf76ca0e0dd331481cc15'/>
<id>urn:sha1:3e3eabe26dc88692d34cf76ca0e0dd331481cc15</id>
<content type='text'>
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 &lt;ardb@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230915171623.655440-18-ardb@google.com
</content>
</entry>
<entry>
<title>x86/boot: Split off PE/COFF .data section</title>
<updated>2023-09-17T17:48:43Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2023-09-15T17:16:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=34951f3c28bdf6481d949a20413b2ce7693687b2'/>
<id>urn:sha1:34951f3c28bdf6481d949a20413b2ce7693687b2</id>
<content type='text'>
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 &lt;ardb@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230915171623.655440-17-ardb@google.com
</content>
</entry>
<entry>
<title>x86/boot: Drop PE/COFF .reloc section</title>
<updated>2023-09-17T17:48:43Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2023-09-15T17:16:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fa5750521e0a4efbc1af05223da9c4bbd6c21c83'/>
<id>urn:sha1:fa5750521e0a4efbc1af05223da9c4bbd6c21c83</id>
<content type='text'>
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 &lt;ardb@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230915171623.655440-16-ardb@google.com
</content>
</entry>
<entry>
<title>x86/boot: Construct PE/COFF .text section from assembler</title>
<updated>2023-09-17T17:48:43Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2023-09-15T17:16:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=efa089e63b56bdc5eca754b995cb039dd7a5457e'/>
<id>urn:sha1:efa089e63b56bdc5eca754b995cb039dd7a5457e</id>
<content type='text'>
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 &lt;ardb@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230915171623.655440-15-ardb@google.com
</content>
</entry>
<entry>
<title>x86/boot: Derive file size from _edata symbol</title>
<updated>2023-09-17T17:48:42Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2023-09-15T17:16:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=aeb92067f6ae994b541d7f9752fe54ed3d108bcc'/>
<id>urn:sha1:aeb92067f6ae994b541d7f9752fe54ed3d108bcc</id>
<content type='text'>
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 &lt;ardb@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230915171623.655440-14-ardb@google.com
</content>
</entry>
<entry>
<title>x86/boot: Define setup size in linker script</title>
<updated>2023-09-17T17:48:42Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2023-09-15T17:16:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=093ab258e3fb1d1d3afdfd4a69403d44ce90e360'/>
<id>urn:sha1:093ab258e3fb1d1d3afdfd4a69403d44ce90e360</id>
<content type='text'>
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 &lt;ardb@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230915171623.655440-13-ardb@google.com
</content>
</entry>
<entry>
<title>x86/boot: Set EFI handover offset directly in header asm</title>
<updated>2023-09-17T17:48:42Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2023-09-15T17:16:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=eac956345f99dda3d68f4ae6cf7b494105e54780'/>
<id>urn:sha1:eac956345f99dda3d68f4ae6cf7b494105e54780</id>
<content type='text'>
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 &lt;ardb@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230915171623.655440-12-ardb@google.com
</content>
</entry>
<entry>
<title>x86/boot: Grab kernel_info offset from zoffset header directly</title>
<updated>2023-09-17T17:48:42Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2023-09-15T17:16:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2e765c02dcbfc2a8a4527c621a84b9502f6b9bd2'/>
<id>urn:sha1:2e765c02dcbfc2a8a4527c621a84b9502f6b9bd2</id>
<content type='text'>
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 &lt;ardb@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230915171623.655440-11-ardb@google.com
</content>
</entry>
</feed>
