linux-kernel - Re: [RFC] efi/tpm: add efi.tpm_log as a reserved region in 820_table

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXG1hbiafKRyC5qM1Vj5X7x-dmLndqqo2AYnHMRxDz-80w@mail.gmail.com>
Date: Thu, 12 Sep 2024 16:05:50 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Usama Arif <usamaarif642@...il.com>
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 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.