From: Usama Arif <usamaarif642@gmail.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi@vger.kernel.org, devel@edk2.groups.io,
kexec@lists.infradead.org, hannes@cmpxchg.org, dyoung@redhat.com,
x86@kernel.org, linux-kernel@vger.kernel.org, leitao@debian.org,
gourry@gourry.net, kernel-team@meta.com
Subject: Re: [RFC 2/2] efi/memattr: add efi_mem_attr_table as a reserved region in 820_table_firmware
Date: Fri, 10 Jan 2025 15:50:02 +0000 [thread overview]
Message-ID: <fd63613c-fd26-42de-b5ed-cc734f72eb36@gmail.com> (raw)
In-Reply-To: <d3ee6521-fae3-41b2-a759-e454681dde6f@gmail.com>
On 10/01/2025 14:31, Usama Arif wrote:
>
>
> On 10/01/2025 07:32, Ard Biesheuvel wrote:
>> On Thu, 9 Jan 2025 at 17:32, Usama Arif <usamaarif642@gmail.com> wrote:
>>>
>>>
>>>
>>> On 09/01/2025 16:15, Ard Biesheuvel wrote:
>
>>> I think in the end whoevers' responsibility it is, the easiest path forward
>>> seems to be in kernel? (and not firmware or libstub)
>>>
>>
>> Agreed. But as I pointed out in the other thread, the memory
>> attributes table only augments the memory map with permission
>> information, and can be disregarded, and given how badly we mangle the
>> memory map on x86, maybe this is the right choice here.
>>
>>>>
>>>>> The next ideal place would be in libstub. However, it looks like
>>>>> InstallMemoryAttributesTable [2] is not available as a boot service
>>>>> call option [3], [4], and install_configuration_table does not
>>>>> seem to work as a valid substitute.
>>>>>
>>>>
>>>> To do what, exactly?
>>>>
>>>
>>> To change the memory type from System RAM to either reserved or
>>> something more appropriate, i.e. any type that is not touched by
>>> kexec or any other userspace.
>>>
>>> Basically the example code I attached at the end of the cover letter in
>>> https://lore.kernel.org/all/20250108215957.3437660-1-usamaarif642@gmail.com/
>>> It could be EFI_ACPI_RECLAIM_MEMORY or EFI_RESERVED_TYPE, both of which aren't
>>> touched by kexec.
>>>
>>
>> This is a kexec problem (on x86 only) so let's fix it there.
>
>
> I don't believe we can accurately tell if we are booting from a cold boot or kexec.
> There is bootloader_type available for x86, but not sure if we should rely on
> that. I think a way forward would be to move it behind a Kconfig option, something like
> below, which defaults to n for x86. Anyone who needs it can enable it. What do you think?
>
Or we can do something like below?
diff --git a/drivers/firmware/efi/memattr.c b/drivers/firmware/efi/memattr.c
index d131781e2d7b..4add694b18d0 100644
--- a/drivers/firmware/efi/memattr.c
+++ b/drivers/firmware/efi/memattr.c
@@ -24,6 +24,15 @@ int __init efi_memattr_init(void)
efi_memory_attributes_table_t *tbl;
unsigned long size;
+#ifdef CONFIG_X86_64
+ /*
+ * On x86_64, do not initialize memory attributes table
+ * if booting from kexec
+ */
+ if (bootloader_type >> 4 == 0xd)
+ return 0;
+#endif
+
if (efi_mem_attr_table == EFI_INVALID_TABLE_ADDR)
return 0;
next prev parent reply other threads:[~2025-01-10 16:14 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-08 21:53 [RFC 0/2] efi/memattr: Fix memory corruption and warning issues Usama Arif
2025-01-08 21:53 ` [RFC 1/2] efi/memattr: Use desc_size instead of total size to check for corruption Usama Arif
2025-01-09 15:45 ` Ard Biesheuvel
2025-01-09 16:36 ` Usama Arif
2025-01-10 7:21 ` Ard Biesheuvel
2025-01-10 10:53 ` Usama Arif
2025-01-10 17:25 ` Ard Biesheuvel
2025-01-13 2:33 ` Dave Young
2025-01-13 11:27 ` Usama Arif
2025-01-13 12:00 ` Usama Arif
2025-01-20 10:27 ` Usama Arif
2025-01-20 10:32 ` Ard Biesheuvel
2025-01-20 10:50 ` Usama Arif
2025-01-20 11:29 ` Ard Biesheuvel
2025-01-20 11:48 ` Usama Arif
2025-01-22 5:36 ` Dave Young
2025-01-22 11:50 ` Usama Arif
2025-01-08 21:53 ` [RFC 2/2] efi/memattr: add efi_mem_attr_table as a reserved region in 820_table_firmware Usama Arif
2025-01-09 16:15 ` Ard Biesheuvel
2025-01-09 16:32 ` Usama Arif
2025-01-09 16:47 ` Gregory Price
2025-01-10 7:32 ` Ard Biesheuvel
2025-01-10 11:36 ` Breno Leitao
2025-01-10 17:33 ` Ard Biesheuvel
2025-01-10 14:31 ` Usama Arif
2025-01-10 15:50 ` Usama Arif [this message]
2025-01-10 2:50 ` Dave Young
2025-01-10 11:12 ` Usama Arif
2025-01-10 11:18 ` Dave Young
2025-01-10 11:20 ` Dave Young
2025-01-10 11:42 ` Usama Arif
2025-01-10 6:56 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fd63613c-fd26-42de-b5ed-cc734f72eb36@gmail.com \
--to=usamaarif642@gmail.com \
--cc=ardb@kernel.org \
--cc=devel@edk2.groups.io \
--cc=dyoung@redhat.com \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@meta.com \
--cc=kexec@lists.infradead.org \
--cc=leitao@debian.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.