From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by mx.groups.io with SMTP id smtpd.web09.1990.1663609164654799497 for ; Mon, 19 Sep 2022 10:39:24 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=T0acdtG+; spf=pass (domain: linux.ibm.com, ip: 148.163.156.1, mailfrom: stefanb@linux.ibm.com) Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 28JHNiW5015001 for ; Mon, 19 Sep 2022 17:39:24 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=59+aVz8o+p0nXsmfg3jisUJ6+JteqZ0bhIOwZroZMWE=; b=T0acdtG+xnrkR2LM31n3L04JqbejwDN45egNlQaKpGjtRlYk0wgnRFeWQ3iPfXFp5fGF pOZ7Osr9lhET1JTY7a6M1kRxUB+q8iSVWYZaNOOGBdtbAqdPCEQexZvqxe4uZEac1FBx 2gUkU4NvJid5tM/bxqmIx36sh3SSMC1eZ+x4+whYRA4wAFEP7ffhwhTmqDn658ob8Gsw UVfs8pXKpLcc/RZvNbnFsLmnWahLDoJYoTd5p3Um5+yM0p02FGorBfxQz/9oU5tWQu0q zxaqASE35KlDUMhylSjbXf3wtd5A8oOwFifzMxS1IpZl65nTDCqvL0plv8A2iAuAI9uQ UA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3jpvsprgva-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 19 Sep 2022 17:39:23 +0000 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 28JHNrxZ015691 for ; Mon, 19 Sep 2022 17:39:23 GMT Received: from ppma03wdc.us.ibm.com (ba.79.3fa9.ip4.static.sl-reverse.com [169.63.121.186]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3jpvsprgua-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Sep 2022 17:39:23 +0000 Received: from pps.filterd (ppma03wdc.us.ibm.com [127.0.0.1]) by ppma03wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 28JHaXr1031208; Mon, 19 Sep 2022 17:39:21 GMT Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by ppma03wdc.us.ibm.com with ESMTP id 3jn5v96xhe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Sep 2022 17:39:21 +0000 Received: from smtpav04.dal12v.mail.ibm.com ([9.208.128.131]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 28JHdMD166781504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Sep 2022 17:39:22 GMT Received: from smtpav04.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6D10358056; Mon, 19 Sep 2022 17:39:20 +0000 (GMT) Received: from smtpav04.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1FAD05805A; Mon, 19 Sep 2022 17:39:20 +0000 (GMT) Received: from [9.47.158.152] (unknown [9.47.158.152]) by smtpav04.dal12v.mail.ibm.com (Postfix) with ESMTP; Mon, 19 Sep 2022 17:39:20 +0000 (GMT) Message-ID: <76ef6453-78b6-c1de-809e-4bca6009078e@linux.ibm.com> Date: Mon, 19 Sep 2022 13:39:19 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [edk2-devel] TPM2 EventLog EFI vs. ACPI To: Jason Andryuk Cc: devel@edk2.groups.io, imammedo@redhat.com References: <20220919111753.0d17e87a@redhat.com> From: "Stefan Berger" In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: z3xtNtW-AraoX-W1qKBZvqkJ_S830yh5 X-Proofpoint-GUID: TgPncQQhJyVlMptsR5cxErbNAlmPir_I X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-09-19_05,2022-09-16_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 impostorscore=0 adultscore=0 suspectscore=0 mlxscore=0 lowpriorityscore=0 priorityscore=1501 clxscore=1015 phishscore=0 malwarescore=0 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2209190117 Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 9/19/22 12:55, Jason Andryuk wrote: > 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../SecurityPkg/Tcg/TcgDxe/TcgDxe.c:707:SetupEventLog ( I did take a look and it surprises me that we have 2 logs for TPM 1.2 and TPM 2 each plus the ACPI one. There are setup functions for TPM 1.2 and TPM 2 each: ./SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c:1546:SetupEventLog ./SecurityPkg/Tcg/TcgDxe/TcgDxe.c:707:SetupEventLog ( Though only one of them should initialize the log because calls to them are gated by DriverEntry checking which TPM version is in use (also my logs seems to say this that only TPM 2's setup is done). Status = Tpm2RequestUseTpm (); if (EFI_ERROR (Status)) { DEBUG ((DEBUG_ERROR, "TPM2 not detected!\n")); return Status; } Status = Tpm12RequestUseTpm (); if (EFI_ERROR (Status)) { DEBUG ((DEBUG_ERROR, "TPM not detected!\n")); return Status; } I have tried to skip over the allocation of memory based on the ability to find the TPM2 table in the SetupEventLog function for TPM 2: tpm2 = EfiLocateFirstAcpiTable (SIGNATURE_32('T', 'P, 'M', '2')); It doesn't find the table at this point. So maybe that's the wrong function to call? Another idea may be to search for the TPM2 table at the end and copy the log into the ACPI log area allocated by QEMU, if there is one (with QEMU there will be one), and use that address then also for the TPM2 log and free the UEFI log area that currently seems to be a duplicate. I don't know where that should be done, though. I always run into the following issue with EDK2 these days... Reserved variable store memory: 0x7FE7C000; size: 528kb NvVarStore Variable header State was invalid. ASSERT /home/stefanb/dev/edk2/OvmfPkg/Library/PlatformInitLib/Platform.c(807): ((BOOLEAN)(0==1)) Regards, Stefan > > Regards, > Jason