From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) by mx.groups.io with SMTP id smtpd.web11.1504.1663606567283811898 for ; Mon, 19 Sep 2022 09:56:07 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=XvSKSGPg; spf=pass (domain: gmail.com, ip: 209.85.166.46, mailfrom: jandryuk@gmail.com) Received: by mail-io1-f46.google.com with SMTP id b23so49552iof.2 for ; Mon, 19 Sep 2022 09:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=+77fHT+5jusrQVZdB2XsBML+IZFAEYA1/4pdWcpxeBg=; b=XvSKSGPgZW2lYIHOlidiIvHUYP0yd8k7eM1B8kTG/NBiAKSDJANTvWoiNiliPIXv/k ZOhaC9mxK2D6u7s3zL1bVNlh/sNkRzv5DPRQcsPbCuzFPPGdH/TxruKzt/VJ7PcSFlIZ haAg1TzdFyAzJ/TgLq9v0NjD3PrfnwmgbeS4OS2lHerB1ATCYzHPVpXIWBeM2T/eoMrf vYYpOG3XX07/zYJhdbSUGMuswaKf4f41VFqRIfniWvaXnvaBNArVNDqp2v4YyTX0NaWZ Y5P6O1PjDsKdCXSpYmCOsOnA8yNLj4JhrqvldhCbdlH5wYj7C5g6N+WsLPBoHgQCeBpW GEpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=+77fHT+5jusrQVZdB2XsBML+IZFAEYA1/4pdWcpxeBg=; b=DTn8BbJ2wpTkkesKdRKU95lPxsSGuT0Ze7+TxDP9WR+uJbfypxJNC6G+dDu0cogWqY f2APn+f0NtRGpjr7fFvMOttA9CICax6FS9zTEkWadfVTdW/Lhnw0JGUfiel9xQrjhYWO 7Qw8CIRTYxP+GGZSvw7sqHMpjXViBXVIF1VW299O73eVx8Zo+mqeNsFqSzmo2qyPiDfD RcJOrCeuHQOnnTuGNY12kbZL/zw35R5bsGC1fT2spirIoFAfSCBYkhRwuYO8AY4Tcfj9 KxpnEtOoWfgebvX7EsSB8GBmRyOANSzi33/pmjGgM2GSUUHldmvPLARxVNOpDfe4cHZ2 ujVQ== X-Gm-Message-State: ACrzQf3mg4bgqcNraT0z4olmPzde286dxhKWtPSH7rx64HVHEJsMfpbb qbVYzP4RZ2bt2wxGOSSQso0OKj5EJdwTKnydLrQ= X-Google-Smtp-Source: AMsMyM7J9xDUKP/jhQd4vBCO6LX8JlQ6dKcc3qNPpYbQr+ACGgLbiSUCRzNsAh1J4KzFwGargJhWBnmNYdVia4NXGFs= X-Received: by 2002:a05:6638:4107:b0:358:4a01:e1e3 with SMTP id ay7-20020a056638410700b003584a01e1e3mr9022495jab.189.1663606566685; Mon, 19 Sep 2022 09:56:06 -0700 (PDT) MIME-Version: 1.0 References: <20220919111753.0d17e87a@redhat.com> In-Reply-To: From: "Jason Andryuk" Date: Mon, 19 Sep 2022 12:55:55 -0400 Message-ID: Subject: Re: [edk2-devel] TPM2 EventLog EFI vs. ACPI To: Stefan Berger Cc: devel@edk2.groups.io, imammedo@redhat.com Content-Type: text/plain; charset="UTF-8" Hi, Stefan, On Mon, Sep 19, 2022 at 8:22 AM Stefan Berger wrote: > > > > On 9/19/22 05:17, Igor Mammedov wrote: > > On Fri, 16 Sep 2022 15:45:38 -0400 > > "Jason Andryuk" wrote: > > > > CCing Stefan as he is probably the best person to talk about qemu > > impl. of TPM > > > >> Hi, > >> > >> I've noticed an issue with the TPM2 EventLog. OVMF exposes the TPM > >> Event Log via EFI and ACPI, but they have different addresses. The > >> EFI one retrievable by GetEventLog() is populated. The ACPI is empty. > > The ACPI one is for SeaBIOS. Yes, ACPI is the only option for SeaBIOS. Still, I expect GetEventLog and the ACPI table to point at the same location. > >> Oh, there are actually two EFI Event Logs for the two formats: > >> EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2 > >> EFI_TCG2_EVENT_LOG_FORMAT_TCG_2 > >> > >> The debug log from the Fedora 36 OVMF shows: > >> Tcg2GetEventLog (EventLogLocation - 7EEB2000) > >> which matches the address retrieved with GetEventLog(). > >> And hexdump-ing the TPM2 ACPI table shows 0x7fbe6000. > >> > >> On a different build, I added output for both EFI logs, and the addresses are: > >> 0x7ec3d000 - EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2 > >> 0x7ec1b000 - EFI_TCG2_EVENT_LOG_FORMAT_TCG_2 > > I am also not familiar with the origin of the EDK2 code as to why it was > done this way. Maybe typical builds for EDK2 don't include TPM 1.2 and > TPM 2 and OVMF is an outlier here... The two log formats are both in the TPM 2 code, so it's independent from including TPM 1.2 and 2 hardware support. > >> 0x7fbe6000 - ACPI > >> > >> The ACPI one is a little more user friendly as its address is > >> available through the table during runtime. The EFI addresses can > >> only be grabbed before exiting boot services. > >> > >> I think the issue is that the ACPI tables are created from Qemu fw_cfg > >> data, which allocates memory for the log and places the address in > >> ACPI tables. Meanwhile, > > That's because of SeaBIOS iirc. I looked at SeaBIOS, and it finds the address in the ACPI TPM2 table and uses it as its log area. > >> SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c:SetupEventLog() allocates its own > >> event log memory. SetupEventLog() saves the size and address in > >> PcdTpm2AcpiTableLaml & PcdTpm2AcpiTableLasa, but nothing puts those > >> values in the actual ACPI tables. > >> > >> It seems like SetupEventLog would be better structured to check > >> existing ACPI tables and look for a log in a TPM2 section. If found, > >> use that, otherwise create a new log area. > >> > >> The other wrinkle is that the Tcg2 code is keeping two event logs in > >> the two formats. It seems to me that for TPM2, it would be easier to > > Does it log everything twice? Yes, it logs everything twice. The sha1 hashes match between the two logs. For the newer format, it generates sha1, sha256, sha384 & sha512 digests for each entry. So there are 3 ~64k memory regions set aside from logs. OVMF code populates the 2 EFI ones. Linux only grabs the EFI logs when entered via EFI stub - a direct UEFI load of the kernel. Booting via grub-efi doesn't grab the EFI log addresses, so only the empty ACPI entry is discovered. Being empty, Linux doesn't expost a TPM event log through sysfs. I tried searching for the TPM2 table in SetupEventLog(), but it wasn't found. SetupEventLog() runs before InstallQemuFwCfgTables(), which makes sense given the existing code to supply the log addresses to Tpm2Acpi. OVMF has already logged things into the event log by the time InstallQemuFwCfgTables() is called. Thanks for taking a look. Regards, Jason