Re: [edk2-devel] [edk2-rfc] [edk2-devel] UEFI Variable SMI Reduction

["Kubacki, Michael A" <michael.a.kubacki@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]

My understanding is both of your points return to the issue of a ring 0 entity potentially modifying the runtime cache. As the SetVariable ( ) API is already accessible to ring 0, the variables could similarly be updated today so that should not be an issue. You have a good point for authenticated variables where the update is authenticated in SMM so the variable data should continue to be returned from SMM.

How about if the variable has the authenticated attribute set, those are sent to GetVariable ( ) in SMM? This should be relatively rare with the most common case likely being secure boot related keys.

From: Johnson, Michael <michael.johnson@intel.com>
Sent: Thursday, September 5, 2019 1:59 PM
To: Kubacki; Kubacki, Michael A <michael.a.kubacki@intel.com>; devel@edk2.groups.io
Subject: Re: [edk2-devel] [edk2-rfc] [edk2-devel] UEFI Variable SMI Reduction

Your primary concern is my primary concern.  I can think of two scenarios where a runtime memory varstore would hurt.

The less severe one is that any variables measured into a TPM could appear to be modified when read back so that if/when some entity wants to verify or unseal something, they would be unable to match the TPM's PCR values and unable to verify/unseal.  This turns access to runtime EFI memory into a denial of service for TPM-based post-boot software.

The more worrying possibility is if somebody decides to use a read-modify-write pattern for some variable they have an interest in and thus end up defeating the security of the variable write method.  Today a read-modify-write is safe, but after this change it would not be.

[-- Attachment #2: Type: text/html, Size: 4059 bytes --]