From: "Usama Arif via groups.io" <usamaarif642=gmail.com@groups.io>
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: [edk2-devel] [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;
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#121014): https://edk2.groups.io/g/devel/message/121014
Mute This Topic: https://groups.io/mt/110518541/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
next prev parent reply other threads:[~2025-01-15 18:53 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-08 21:53 [edk2-devel] [RFC 0/2] efi/memattr: Fix memory corruption and warning issues Usama Arif via groups.io
2025-01-08 21:53 ` [edk2-devel] [RFC 1/2] efi/memattr: Use desc_size instead of total size to check for corruption Usama Arif via groups.io
2025-01-09 15:45 ` Ard Biesheuvel via groups.io
2025-01-09 16:36 ` Usama Arif via groups.io
2025-01-10 7:21 ` Ard Biesheuvel via groups.io
2025-01-10 10:53 ` Usama Arif via groups.io
2025-01-10 17:25 ` Ard Biesheuvel via groups.io
2025-01-13 2:33 ` Dave Young via groups.io
2025-01-13 11:27 ` Usama Arif via groups.io
2025-01-13 12:00 ` Usama Arif via groups.io
[not found] ` <ed7ad48f-2270-4966-bdba-ccd4592a0fd4@gmail.com>
2025-01-20 10:32 ` Ard Biesheuvel via groups.io
[not found] ` <029cff22-f2e0-4796-9c27-1df056e08f8f@gmail.com>
2025-01-20 11:29 ` Ard Biesheuvel via groups.io
2025-01-08 21:53 ` [edk2-devel] [RFC 2/2] efi/memattr: add efi_mem_attr_table as a reserved region in 820_table_firmware Usama Arif via groups.io
2025-01-09 16:15 ` Ard Biesheuvel via groups.io
2025-01-09 16:32 ` Usama Arif via groups.io
2025-01-09 16:47 ` Gregory Price
2025-01-10 7:32 ` Ard Biesheuvel via groups.io
2025-01-10 11:36 ` Breno Leitao
2025-01-10 17:33 ` Ard Biesheuvel via groups.io
2025-01-10 14:31 ` Usama Arif via groups.io
2025-01-10 15:50 ` Usama Arif via groups.io [this message]
2025-01-10 2:50 ` Dave Young via groups.io
2025-01-10 11:12 ` Usama Arif via groups.io
2025-01-10 11:18 ` Dave Young via groups.io
2025-01-10 11:20 ` Dave Young via groups.io
2025-01-10 11:42 ` Usama Arif via groups.io
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-list 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=devel@edk2.groups.io \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox