Bug in Precision 7760 UEFI Secure Boot implementation

Hello. I think I've found an error in the current implementation of the UEFI Secure Boot standard in the latest (v1.16.0) version of the firmware for the Precision 7760.

If you attempt to enable BitLocker on these machines, the TPM will refuse to use the TPM's PCR 7 (the Secure Boot measurement), whose measurements depend on the secure boot signing keys.

For the record, according to Microsoft's public documentation, if the machine has TPM 2.0 (which it does), PCR 7 must be used for BitLocker support. Furthermore, all other Dell laptops (Latitude 5420, Latitude 7490, Latitude 5480) we currently own do properly implement Secure Boot PCR 7 calculation, which means this is some bug that affects this model in particular only.

Due to the bug in the current firmware implementation, BitLocker instead of using PCR 7 falls back to PCR 0+2+4 (firmware+option ROM hashes) in its place, which means on each firmware upgrade that value changes, and you get the BitLocker recovery screen. Best case you need to type in the recover key, worst case you don't have it and lose access to the data as a coworker experienced.

The reason for this according to msinfo32 is that linking is not possible, and further elaborates that it is due to an "Un-allowed DMA capable bus/device(s) detected". This is however, not the true cause - looking into event viewer I can see that BitLocker refuses to use it because "The signature contained in the EFI_SIGNATURE_DATA structure from the OS authority event could not be found in the verified certificate chain for the boot loader."

I further investigated more, and using an open source TCG log extraction tool I compared the PCR 7 event log from a working Latitude 5420 with the aforementioned 7760:

Working Latitude 5420:

EventType : EV_EFI_VARIABLE_DRIVER_CONFIG
Digest    : CCFC4BB32888A345BC8AEADABA552B627D99348C767681AB3141F5B01E40A40E
Event     : @{VariableGUID=8be4df61-93ca-11d2-aa0d-00e098032b8c; VariableName=SecureBoot; VariableData=System.Byte[]}

EventType : EV_EFI_VARIABLE_DRIVER_CONFIG
Digest    : 2ABFE9865A654102ACB12F0FEFE52DC4D01BCE40901410EB3DADAF212700A2B7
Event     : @{VariableGUID=8be4df61-93ca-11d2-aa0d-00e098032b8c; VariableName=PK; VariableData=}

EventType : EV_EFI_VARIABLE_DRIVER_CONFIG
Digest    : 63A525134BFBC242058C0E6B42794F8B1D142D13029A9AA38A3272C5CA2390C5
Event     : @{VariableGUID=8be4df61-93ca-11d2-aa0d-00e098032b8c; VariableName=KEK; VariableData=}

EventType : EV_EFI_VARIABLE_DRIVER_CONFIG
Digest    : 58A0C07F6F04C9D61AFE2B70E99BC3CAF569856119BD543CEBAE7DCD9AC2C7D1
Event     : @{VariableGUID=d719b2cb-3d3a-4596-a3bc-dad00e67656f; VariableName=db; VariableData=}

EventType : EV_EFI_VARIABLE_DRIVER_CONFIG
Digest    : D21D73E6F8916A289F46F28AAC092AE3175BE8AEA423BADFD85E290B3A6EBA3B
Event     : @{VariableGUID=d719b2cb-3d3a-4596-a3bc-dad00e67656f; VariableName=dbx; VariableData=}

EventType : EV_SEPARATOR
Digest    : DF3F619804A92FDB4057192DC43DD748EA778ADC52BC498CE80524C014B81119
Event     : 00:00:00:00

EventType : EV_EFI_VARIABLE_AUTHORITY
Digest    : 30BF464EE37F1BC0C7B1A5BF25ECED275347C3AB1492D5623AE9F7663BE07DD5
Event     : @{VariableGUID=d719b2cb-3d3a-4596-a3bc-dad00e67656f; VariableName=db; VariableData=}

Bugged Precision 7760:

EventType : EV_EFI_VARIABLE_DRIVER_CONFIG
Digest    : CCFC4BB32888A345BC8AEADABA552B627D99348C767681AB3141F5B01E40A40E
Event     : @{VariableGUID=8be4df61-93ca-11d2-aa0d-00e098032b8c; VariableName=SecureBoot; VariableData=System.Byte[]}

EventType : EV_EFI_VARIABLE_DRIVER_CONFIG
Digest    : 2ABFE9865A654102ACB12F0FEFE52DC4D01BCE40901410EB3DADAF212700A2B7
Event     : @{VariableGUID=8be4df61-93ca-11d2-aa0d-00e098032b8c; VariableName=PK; VariableData=}

EventType : EV_EFI_VARIABLE_DRIVER_CONFIG
Digest    : 63A525134BFBC242058C0E6B42794F8B1D142D13029A9AA38A3272C5CA2390C5
Event     : @{VariableGUID=8be4df61-93ca-11d2-aa0d-00e098032b8c; VariableName=KEK; VariableData=}

EventType : EV_EFI_VARIABLE_DRIVER_CONFIG
Digest    : 58A0C07F6F04C9D61AFE2B70E99BC3CAF569856119BD543CEBAE7DCD9AC2C7D1
Event     : @{VariableGUID=d719b2cb-3d3a-4596-a3bc-dad00e67656f; VariableName=db; VariableData=}

EventType : EV_EFI_VARIABLE_DRIVER_CONFIG
Digest    : F0BF49C6A2D3E170077F1F66875D6CB9B2AA382060CAC5C0B645660BB95BC058
Event     : @{VariableGUID=d719b2cb-3d3a-4596-a3bc-dad00e67656f; VariableName=dbx; VariableData=}

EventType : EV_SEPARATOR
Digest    : DF3F619804A92FDB4057192DC43DD748EA778ADC52BC498CE80524C014B81119
Event     : 00:00:00:00

EventType : EV_EFI_VARIABLE_AUTHORITY
Digest    : 4D4A8E2C74133BBDC01A16EAF2DBB5D575AFEB36F5D8DFCF609AE043909E2EE9
Event     : @{VariableGUID=d719b2cb-3d3a-4596-a3bc-dad00e67656f; VariableName=db; VariableData=}

EventType : EV_EFI_VARIABLE_AUTHORITY
Digest    : 30BF464EE37F1BC0C7B1A5BF25ECED275347C3AB1492D5623AE9F7663BE07DD5
Event     : @{VariableGUID=d719b2cb-3d3a-4596-a3bc-dad00e67656f; VariableName=db; VariableData=}

The former is creating only a "EV_EFI_VARIABLE_AUTHORITY" event with digest 30BF464EE37F1BC0C7B1A5BF25ECED275347C3AB1492D5623AE9F7663BE07DD5, which corresponds to "Microsoft Windows Production PCA 2011" (aka the correct key for signing Microsoft products)

The 7760, on the other hand, is creating two EV_EFI_VARIABLE_AUTHORITY events - first one with the correct key, and a second one with 4D4A8E2C74133BBDC01A16EAF2DBB5D575AFEB36F5D8DFCF609AE043909E2EE9, which corresponds to "Microsoft Corporation Third Party Marketplace Root" (aka the key used to firm third party shims like Ubuntu's, Debian's...)

This is a violation of the Trusted Computing Group Secure Boot standard (page 45 of the TCG PC Client Platform Firmware Profile), and it is being caught by Windows as an error, therefore refusing to use PCR 7:

Before launching a UEFI Driver or a UEFI Boot Application (and regardless of whether the launch is due to the UEFI Boot Manager picking an image from the DriverOrder or BootOrder UEFI variables or an already launched image calling the UEFI LoadImage() function), the UEFI firmware SHALL determine if the entry in the UEFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE variable that was used to validate the UEFI image has previously been measured with the EV_EFI_VARIABLE_AUTHORITY event type in PCR[7]. If it has not been, it MUST be measured into PCR[7] as follows. If it has been measured previously, it MUST NOT be measured again. The measurement SHALL occur in conjunction with image load.

The bug therefore consists in that the current implementation is both:

• Creating an event for a signing key that is unrelated to the UEFI image being currently loaded
• Measuring twice, despite the standard explicitely saying it must not be done.