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.john...@intel.com>; 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.john...@intel.com<mailto:michael.john...@intel.com>> Sent: Thursday, September 5, 2019 1:59 PM To: Kubacki; Kubacki, Michael A <michael.a.kuba...@intel.com<mailto:michael.a.kuba...@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. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#46989): https://edk2.groups.io/g/devel/message/46989 Mute This Topic: https://groups.io/mt/33158252/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
