All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jirislaby@kernel.org>
To: Ard Biesheuvel <ardb+git@google.com>, linux-efi@vger.kernel.org
Cc: Ard Biesheuvel <ardb@kernel.org>,
	stable@vger.kernel.org, Breno Leitao <leitao@debian.org>,
	Usama Arif <usamaarif642@gmail.com>
Subject: Re: [PATCH] efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption
Date: Thu, 24 Oct 2024 18:20:31 +0200	[thread overview]
Message-ID: <ec7db629-61b0-49aa-a67d-df663f004cd0@kernel.org> (raw)
In-Reply-To: <20240912155159.1951792-2-ardb+git@google.com>

On 12. 09. 24, 17:52, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
> 
> The TPM event log table is a Linux specific construct, where the data
> produced by the GetEventLog() boot service is cached in memory, and
> passed on to the OS using a EFI configuration table.
> 
> The use of EFI_LOADER_DATA here results in the region being left
> unreserved in the E820 memory map constructed by the EFI stub, and this
> is the memory description that is passed on to the incoming kernel by
> kexec, which is therefore unaware that the region should be reserved.
> 
> Even though the utility of the TPM2 event log after a kexec is
> questionable, any corruption might send the parsing code off into the
> weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY
> instead, which is always treated as reserved by the E820 conversion
> logic.
> 
> Cc: <stable@vger.kernel.org>
> Reported-by: Breno Leitao <leitao@debian.org>
> Tested-by: Usama Arif <usamaarif642@gmail.com>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>   drivers/firmware/efi/libstub/tpm.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/efi/libstub/tpm.c b/drivers/firmware/efi/libstub/tpm.c
> index df3182f2e63a..1fd6823248ab 100644
> --- a/drivers/firmware/efi/libstub/tpm.c
> +++ b/drivers/firmware/efi/libstub/tpm.c
> @@ -96,7 +96,7 @@ static void efi_retrieve_tcg2_eventlog(int version, efi_physical_addr_t log_loca
>   	}
>   
>   	/* Allocate space for the logs and copy them. */
> -	status = efi_bs_call(allocate_pool, EFI_LOADER_DATA,
> +	status = efi_bs_call(allocate_pool, EFI_ACPI_RECLAIM_MEMORY,
>   			     sizeof(*log_tbl) + log_size, (void **)&log_tbl);

Hi,

this, for some reason, corrupts system configuration table. On good 
boots, memattr points to 0x77535018, on bad boots (this commit applied), 
it points to 0x77526018.

And the good content at 0x77526018:
tab=0x77526018 size=16+45*48=0x0000000000000880

bad content at 0x77535018:
tab=0x77535018 size=16+2*1705353216=0x00000000cb4b4010

This happens only on cold boots. Subsequent boots (having the commit or 
not) are all fine.

Any ideas?

DMI: Dell Inc. Latitude 7290/09386V, BIOS 1.39.0 07/04/2024

This was reported downstream at:
https://bugzilla.suse.com/show_bug.cgi?id=1231465

thanks,
-- 
js
suse labs


  parent reply	other threads:[~2024-10-24 16:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-12 15:52 [PATCH] efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption Ard Biesheuvel
2024-09-13  6:27 ` Ilias Apalodimas
2024-09-13 10:00 ` Breno Leitao
2024-10-24 16:20 ` Jiri Slaby [this message]
2024-10-25  5:07   ` Jiri Slaby
2024-10-25  5:09     ` Jiri Slaby
2024-10-25  7:30       ` Ard Biesheuvel
2024-10-30 16:32         ` Gregory Price
2024-10-31  7:55         ` Jiri Slaby
2024-10-31  9:04           ` Ard Biesheuvel
2024-10-25 13:27       ` Usama Arif
2024-10-30  5:25         ` Jiri Slaby
2024-10-30 17:13           ` Usama Arif
2024-10-30 18:02             ` Gregory Price
2024-10-30 18:24               ` Usama Arif
2024-10-31  8:38                 ` Jiri Slaby
2024-10-30 18:26             ` Gregory Price
2024-10-30 19:43               ` Ard Biesheuvel
2024-10-30 20:30                 ` Gregory Price
2024-10-31  8:19               ` Jiri Slaby

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=ec7db629-61b0-49aa-a67d-df663f004cd0@kernel.org \
    --to=jirislaby@kernel.org \
    --cc=ardb+git@google.com \
    --cc=ardb@kernel.org \
    --cc=leitao@debian.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=usamaarif642@gmail.com \
    /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.