Bug 2002648

Summary: Shim refuses to boot the system when TPM event logging fails [rhel-7.9.z]
Product: Red Hat Enterprise Linux 7 Reporter: Renaud Métrich <rmetrich>
Component: shimAssignee: Bootloader engineering team <bootloader-eng-team>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team-automation>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.9CC: jwboyer, kpfleming, mlewando, pjanda, raravind, rharwood, sbarcomb
Target Milestone: rcKeywords: OtherQA, Triaged, ZStream
Target Release: ---Flags: pm-rhel: mirror+
Hardware: x86_64   
OS: Linux   
URL: https://github.com/rhboot/shim/pull/414
Whiteboard:
Fixed In Version: shim-signed-15.6-1.el7_9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-04-25 13:26:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Renaud Métrich 2021-09-09 12:36:57 UTC
This bug was initially created as a copy of Bug #2002265

I am copying this bug because: 

Also applies to RHEL7, customer verified it's also failing

Description of problem:

On Dell hardware (at least PowerEdge T340 with BIOS 2.6.3), when selecting option "TPM 1.2 On without Pre-Boot Measurements" in the UEFI firmware, Shim refuses to boot the system the system because the call of mirror_one_mok_variable() function on MokListRT, MokListXRT and SbatLevelRT fails.

Actually the failure is not when creating the variables, but calling tpm_log_event() (line 819):
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
 532 static EFI_STATUS NONNULL(1)
 533 mirror_one_mok_variable(struct mok_state_variable *v,
 534                         BOOLEAN only_first)
 535 {
 :
 544         BOOLEAN log = v->flags & MOK_VARIABLE_LOG;
 :
 812                 if (log) {
 813                         /*
 814                          * Log this variable into whichever PCR the table
 815                          * says.
 816                          */
 817                         EFI_PHYSICAL_ADDRESS datap =
 818                                         (EFI_PHYSICAL_ADDRESS)(UINTN)FullData,
 819                         efi_status = tpm_log_event(datap, FullDataSize,
 820                                                    v->pcr, (CHAR8 *)v->name8);
 821                         if (EFI_ERROR(efi_status)) {
 822                                 dprint(L"tpm_log_event(0x%llx, %lu, %lu, \"%s\")->%r\n",
 823                                        FullData, FullDataSize, v->pcr, v->name,
 824                                        efi_status);
 825                                 return efi_status;
 826                         }
 827                 }
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Verbose mode snippet:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
mok.c:358:mirror_mok_db() SetVariable("MokListRT", ... varsz=0x826) = Success
mok.c:792:mirror_one_mok_variable() mirror_mok_db("MokListRT",  datasz=2086) returned Success
mok.c:823:mirror_one_mok_variable() tpm_log_event(0x5C506020, 2086, 14, "MokList")->Unsupported
Could not create MokListRT: Unsupported
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------


Talking to Javier, he believes that having tpm_log_event() fail should NOT make the mirror_one_mok_variable() function fail, exactly as the code in Grub does (i.e. ignore errors at TPM level):
see patch https://src.fedoraproject.org/rpms/grub2/raw/rawhide/f/0152-tpm-Don-t-propagate-TPM-measurement-errors-to-the-ve.patch


Version-Release number of selected component (if applicable):

All shim releases, customer reproduces with latest for RHEL8.4 (shim-x64-15.4-2.el8_1.x86_64)


How reproducible:

Always on customer system, I don't have the hardware to test myself.

Comment 3 raravind 2023-04-05 12:26:25 UTC
Hi Petr/Marta,

Since it is POST for long time are we good to close this?Not sure whether you need to test with new shim?Please advise.

Comment 16 errata-xmlrpc 2023-04-25 13:26:46 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (shim bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:1991