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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#80107): https://edk2.groups.io/g/devel/message/80107 Mute This Topic: https://groups.io/mt/85242567/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
