Re: SVSM initiated early attestation / guest secrets injection

["Jörg Rödel" <jroedel@suse.de>]

On Fri, Jan 13, 2023 at 06:28:32PM +0000, Daniel P. Berrangé wrote:
> Aside from what James' says, one option is to lockdown the OVMF and
> secureboot chain. eg OVMF built with SecureBoot=on, and instead of
> having the generic Microsoft keys enrolled, have a distro specific
> key enrolled. That distro key would have to be one that is only
> used for signing UKIs (Unified Kernel Images), and the initrd embedded
> in the UKI would need to be designed abort if it finds the disk is
> not encrypted.
> 
> The main challenge here is that you don't have a single OVMF anymore.
> You have many OVMFs, one for each distinct set of distro SecureBoot
> keys, and the attestation server has to decide which one it wants
> based on the distro the VM is expected to use.

Yeah, as you said, this requires OS-vendor specific firmware in the VM,
I doubt the CSPs will implement offerings this way. More likely is
that a CSP will deploy its forked OVMF BIOS with a set of secure boot
keys, which will likely also include keys from the CSP (especially if
the CSP also provides its own distro). So you still need to trust the
CSP that it will not fake one of your VMs to steal secrets.

As James also said, the measurement to unlock secrets need to include
all software/data components up to the point where the encrypted disk
gets mounted.

Regards,

-- 
Jörg Rödel
jroedel@suse.de

SUSE Software Solutions Germany GmbH
Frankenstraße 146
90461 Nürnberg
Germany

(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman