Hi, > One option I've illustrated before is that have SVSM (or equiv) > expose an encrypted storage service to EDK2. Given the proposed EDK2 > side protocol/modifications for variable storage, I wonder if it is > viable for SVSM (or equiv) to replace QEMU in providing the backend > storage impl ? IOW, host QEMU would expose a pflash to the guest, > to which SVSM would apply full disk encryption, and then store the > EFI variables in it
Yes. IIRC (it's been a while I've looked at the spec) the SVSM can request that access to specific pages trap, so it could use that to emulate the mmio/sysbus variant of the device. Not sure if that could work for io/isa too. Another option would be to add a third interface variant which uses SVSM service calls. And one advantage of a rust implementation would be that integrating with coconut-svsm (which is written in rust too) might be easier. On the other hand the SVSM is a very different environment, the rust stdlib is not available for example, and the way persistence is implemented will probably look very different too. Another difference is crypto support, qemu uses nettle / gnutls whereas svsm will probably use openssl. So not sure how big the opportunity to share the code between qemu and svsm on the backend side actually is. take care, Gerd
