[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1c37546a-e15e-465f-bcbb-6f39c0fcf82d@gmail.com>
Date: Fri, 13 Sep 2024 12:06:54 +0100
From: Usama Arif <usamaarif642@...il.com>
To: Dave Young <dyoung@...hat.com>, Ard Biesheuvel <ardb@...nel.org>
Cc: Breno Leitao <leitao@...ian.org>, linux-efi@...r.kernel.org,
kexec@...ts.infradead.org, ebiederm@...ssion.com, bhe@...hat.com,
vgoyal@...hat.com, tglx@...utronix.de, dave.hansen@...ux.intel.com,
x86@...nel.org, linux-kernel@...r.kernel.org, rmikey@...a.com,
gourry@...rry.net
Subject: Re: [RFC] efi/tpm: add efi.tpm_log as a reserved region in
820_table_firmware
On 13/09/2024 11:56, Dave Young wrote:
> On Thu, 12 Sept 2024 at 22:15, Ard Biesheuvel <ardb@...nel.org> wrote:
>>
>> (cc Dave)
>
> Thanks for ccing me.
>
>>
>> Full thread here:
>> https://lore.kernel.org/all/CAMj1kXG1hbiafKRyC5qM1Vj5X7x-dmLndqqo2AYnHMRxDz-80w@mail.gmail.com/T/#u
>>
>> On Thu, 12 Sept 2024 at 16:05, Ard Biesheuvel <ardb@...nel.org> wrote:
>>>
>>> On Thu, 12 Sept 2024 at 15:55, Usama Arif <usamaarif642@...il.com> wrote:
>>>>
>>>>
>>>>
>>>> On 12/09/2024 14:10, Ard Biesheuvel wrote:
>>>>> Does the below help at all?
>>>>>
>>>>> --- a/drivers/firmware/efi/tpm.c
>>>>> +++ b/drivers/firmware/efi/tpm.c
>>>>> @@ -60,7 +60,7 @@ int __init efi_tpm_eventlog_init(void)
>>>>> }
>>>>>
>>>>> tbl_size = sizeof(*log_tbl) + log_tbl->size;
>>>>> - memblock_reserve(efi.tpm_log, tbl_size);
>>>>> + efi_mem_reserve(efi.tpm_log, tbl_size);
>>>>>
>>>>> if (efi.tpm_final_log == EFI_INVALID_TABLE_ADDR) {
>>>>> pr_info("TPM Final Events table not present\n");
>>>>
>>>> Unfortunately not. efi_mem_reserve updates e820_table, while kexec looks at /sys/firmware/memmap
>>>> which is e820_table_firmware.
>>>>
>>>> arch_update_firmware_area introduced in the RFC patch does the same thing as efi_mem_reserve does at
>>>> its end, just with e820_table_firmware instead of e820_table.
>>>> i.e. efi_mem_reserve does:
>>>> e820__range_update(addr, size, E820_TYPE_RAM, E820_TYPE_RESERVED);
>>>> e820__update_table(e820_table);
>>>>
>>>> while arch_update_firmware_area does:
>>>> e820__range_update_firmware(addr, size, E820_TYPE_RAM, E820_TYPE_RESERVED);
>>>> e820__update_table(e820_table_firmware);
>>>>
>>>
>>> Shame.
>>>
>>> Using efi_mem_reserve() is appropriate here in any case, but I guess
>>> kexec on x86 needs to be fixed to juggle the EFI memory map, memblock
>>> table, and 3 (!) versions of the E820 table in the correct way
>>> (e820_table, e820_table_kexec and e820_table_firmware)
>>>
>>> Perhaps we can put this additional logic in x86's implementation of
>>> efi_arch_mem_reserve()? AFAICT, all callers of efi_mem_reserve() deal
>>> with configuration tables produced by the firmware that may not be
>>> reserved correctly if kexec looks at e820_table_firmware[] only.
>>
>
> I have not read all the conversations, let me have a look and response later.
>
> The first glance about the patch is that I think the kexec_file_load
> syscall (default of latest kexec-tools) will not use
> e820_table_firmware AFAIK. it will only use e820_table_kexec.
I initially thought that as well. But it looks like kexec just reads /sys/firmware/memmap
https://github.com/horms/kexec-tools/blob/main/kexec/firmware_memmap.h#L29
which is e820_table_firmware.
The patch that Ard sent in https://lore.kernel.org/all/20240912155159.1951792-2-ardb+git@google.com/
is the right approach to it I believe, and I dont see the issue anymore after applying that patch.
>
> Usama, can you confirm how you tested this?
> kexec -c -l will use kexec_load syscall
I am currently testing in my VM setup with kexec_load. But production is running
kexec_file_load and has the same issue.
Thanks,
Usama
> kexec [-s] -l will use kexec_file_load syscall
>
> Thanks
> Dave
>
Powered by blists - more mailing lists