Re: [edk2-devel] [PATCH V5 1/2] OvmfPkg: Introduce Tdx BFV/CFV PCDs and PcdOvmfImageSizeInKb

["Andrew Fish" <afish@apple.com>]

> On Sep 1, 2021, at 9:53 AM, James Bottomley <jejb@linux.ibm.com> wrote:
> 
> On Wed, 2021-09-01 at 08:59 +0000, Yao, Jiewen wrote:
>> Hi Min
>> I agree with Gerd and Ard in this case.
>> 
>> It is NOT so obvious that the FTW is produced then consumed in the
>> code. What if the attacker prepares some special configuration to
>> trigger the FTW process at the first boot, the code will do *read*
>> before *write*? That is a potential attack surface.
> 
> It's not just that: even if you can ensure nothing in the host changed
> the variables, how do you know *your* code inside the guest is updating
> them?  In ordinary OVMF we try to ensure that by having the variables
> SMM protected so the only update path available to the kernel is via
> the setVariable interface, but we can't do that in the confidential
> computing case because SMM isn't supported.  That means a random kernel
> attacker in the guest can potentially write to the var store too.
> 
> At least for the first SEV prototype I had to make the var store part
> of the first firmware volume firstly so it got measured but secondly so
> it couldn't be used as a source of configuration attacks.
> 
> I have a nasty feeling that configuration attacks are going to be the
> bane of all confidential computing solutions because they give the
> untrusted VMM a wide attack surface.
> 

James,

If we take a big step back the requirement for an EFI Runtime Service, like the variable API, is just exclusive access to hardware at OS runtime. The variable store needs to be on a hardware device that has a persistent reliable store. The FTW is really about maintaining the consistency of the store if the power gets yanked at the wrong moment. So the fact that the UEFI Variable Store is in NOR FLASH is a historical artifact more than architecture. Also on physical devices hardware cost money, and you need the NOR FLASH for the firmware so why change it. Thus conceptually the variable store could be backed by a virtual hardware device that was designed with security in mind. Maybe more of message passing interface and the reliability of updates is maintained by the hardware device not the UEFI code. It would also be possible for the hardware device to enforce security policy. You could even have EFI send a one shot message per 1st boot to the hardware to define a security policy. If you wanted the hardware device could even implement the UEFI Secure Boot infrastructure so the UEFI Variable Driver could be untrusted. I guess this hypothetical variable store virtual hardware device could also have hardware access to other security hardware resources (like a TPM) and implement security policies based on that. 

FYI on Macs with a T2 (security chip) the UEFI variable store lives on the T2. 

Thanks,

Andrew Fish


> James
> 
> 
> 
> 
> 
> 
>