<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/firmware/efi/libstub/alignedmem.c, branch linux-6.18.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.18.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.18.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2024-01-30T20:44:21Z</updated>
<entry>
<title>efi/libstub: Add one kernel-doc comment</title>
<updated>2024-01-30T20:44:21Z</updated>
<author>
<name>Yang Li</name>
<email>yang.lee@linux.alibaba.com</email>
</author>
<published>2024-01-19T10:06:35Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=aa0e784dea7c1a026aabff9db1cb5d2bd92b3e92'/>
<id>urn:sha1:aa0e784dea7c1a026aabff9db1cb5d2bd92b3e92</id>
<content type='text'>
Add the description of @memory_type to silence the warning:
drivers/firmware/efi/libstub/alignedmem.c:27: warning: Function parameter or struct member 'memory_type' not described in 'efi_allocate_pages_aligned'

Signed-off-by: Yang Li &lt;yang.lee@linux.alibaba.com&gt;
[ardb: tweak comment]
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: efi: Limit allocations to 48-bit addressable physical region</title>
<updated>2022-12-07T18:50:44Z</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ardb@kernel.org</email>
</author>
<published>2022-12-05T08:10:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a37dac5c5dcfe0f1fd58513c16cdbc280a47f628'/>
<id>urn:sha1:a37dac5c5dcfe0f1fd58513c16cdbc280a47f628</id>
<content type='text'>
The UEFI spec does not mention or reason about the configured size of
the virtual address space at all, but it does mention that all memory
should be identity mapped using a page size of 4 KiB.

This means that a LPA2 capable system that has any system memory outside
of the 48-bit addressable physical range and follows the spec to the
letter may serve page allocation requests from regions of memory that
the kernel cannot access unless it was built with LPA2 support and
enables it at runtime.

So let's ensure that all page allocations are limited to the 48-bit
range.

Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>efi: libstub: use EFI_LOADER_CODE region when moving the kernel in memory</title>
<updated>2022-11-18T08:14:08Z</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ardb@kernel.org</email>
</author>
<published>2022-08-02T09:00:16Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9cf42bca30e98a1c6c9e8abf876940a551eaa3d1'/>
<id>urn:sha1:9cf42bca30e98a1c6c9e8abf876940a551eaa3d1</id>
<content type='text'>
The EFI spec is not very clear about which permissions are being given
when allocating pages of a certain type. However, it is quite obvious
that EFI_LOADER_CODE is more likely to permit execution than
EFI_LOADER_DATA, which becomes relevant once we permit booting the
kernel proper with the firmware's 1:1 mapping still active.

Ostensibly, recent systems such as the Surface Pro X grant executable
permissions to EFI_LOADER_CODE regions but not EFI_LOADER_DATA regions.

Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>efi/libstub: Fix gcc error around __umoddi3 for 32 bit builds</title>
<updated>2020-07-09T06:45:09Z</updated>
<author>
<name>Atish Patra</name>
<email>atish.patra@wdc.com</email>
</author>
<published>2020-06-25T23:45:06Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=950accbabd4cfa83519fa920f99428bcc131c3c9'/>
<id>urn:sha1:950accbabd4cfa83519fa920f99428bcc131c3c9</id>
<content type='text'>
32bit gcc doesn't support modulo operation on 64 bit data. It results in
a __umoddi3 error while building EFI for 32 bit.

Use bitwise operations instead of modulo operations to fix the issue.

Signed-off-by: Atish Patra &lt;atish.patra@wdc.com&gt;
Link: https://lore.kernel.org/r/20200625234516.31406-2-atish.patra@wdc.com
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>efi/libstub: Add API function to allocate aligned memory</title>
<updated>2020-04-24T12:52:16Z</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ardb@kernel.org</email>
</author>
<published>2020-03-27T15:09:40Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=43b1df0e013c25abb536699f46d0e9f291b586a0'/>
<id>urn:sha1:43b1df0e013c25abb536699f46d0e9f291b586a0</id>
<content type='text'>
Break out the code to create an aligned page allocation from mem.c
and move it into a function efi_allocate_pages_aligned() in alignedmem.c.
Update efi_allocate_pages() to invoke it unless the minimum alignment
equals the EFI page size (4 KB), in which case the ordinary page
allocator is sufficient. This way, efi_allocate_pages_aligned() will
only be pulled into the build if it is actually being used (which will
be on arm64 only in the immediate future)

Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
</feed>
