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

["Yao, Jiewen" <jiewen.yao@intel.com>]

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

Hey, from security perspective, I am not clear what is difference on below 2 scenario – TPM or read-modify-write.

Whenever we return some data from SMM, we are in ring0, any program in ring0 may modify the variable content in the communication buffer.
If we assume ring0 is malicious, then the malicious code may let one AP keep looping to monitor the communication data, when BSP call get (authenticated) variable. Once communication buffer is updated and status is filled to EFI_SUCCESS, the AP may modify the communication buffer, then the BSP will return *modified* data to caller. Or an interrupt handler in BSP may also modify the communication buffer before the data is returned to caller. This race condition exists today.

I think putting cache buffer to SMM just raise the BAR, but *NOT* a security solution, because SMM communication buffer in reserved memory is same as cache buffer.

Thank you
Yao Jiewen

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Johnson, Michael
Sent: Saturday, September 7, 2019 5:52 AM
To: Kubacki, Michael A <michael.a.kubacki@intel.com>; devel@edk2.groups.io
Subject: Re: [edk2-devel] [edk2-rfc] [edk2-devel] UEFI Variable SMI Reduction

Yes - both things I bring up are just *different* ring 0 accesses than are (easily) allowed today, so are not fundamentally new.  Generally we either trust all of ring 0 or none of it, so neither is a showstopper.

Reading back from real varstore/SMM if the variable has the auth attribute removes any interesting vectors so all that changes is a bad ring 0 agent can go through memory instead of the RT API, which is not threatening.

I have no problems if write and auth-read come from SMM and all else comes from cache.

From: Kubacki, Michael A
Sent: Friday, September 6, 2019 2:48 PM
To: Johnson, Michael <michael.johnson@intel.com<mailto:michael.johnson@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Subject: RE: [edk2-devel] [edk2-rfc] [edk2-devel] UEFI Variable SMI Reduction

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<mailto:michael.johnson@intel.com>>
Sent: Thursday, September 5, 2019 1:59 PM
To: Kubacki; Kubacki, Michael A <michael.a.kubacki@intel.com<mailto:michael.a.kubacki@intel.com>>; devel@edk2.groups.io<mailto: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: 8263 bytes --]