Re: SVSM initiated early attestation / guest secrets injection

[Dionna Amalie Glaze <dionnaglaze@google.com>]

>
> 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.
>

IIUC, the disk doesn't need to be encrypted, it needs integrity. We
can't treat booting to an encrypted disk as booting to the expected
encrypted disk.
Everything still depends on rooting your core secrets to your
workload's identity. This relies on an integrity-protected initrd that
has its root hash measured as part of the kernel_cmdline.

The secret-holding server should only ever release secrets encrypted
by an attested vTPM binary (SVSM-generated public key) that has sealed
the secret to the workload PCRs.
This kicks the problem to the server and VM having pre-agreed on
what's the expected combination of OVMF and SVSM. So yes the vTPM gets
its core secret transferred to it before the PCRs get set to the
expected values, but that's part of the attestation dance with the
initial registration with the secret-holding server.

> 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.
>
> If we don't do any of this, then the early attestation and secret
> fetch would have to be limited to /only/ the secret for unlocking
> the vTPM state, and not injected into the guest OS. The OS would
> have to do everything else with the vTPM and PCR sealed data to
> achieve the same end results of only getting access to secrets if
> the vTPM sees the set of PCR values corresponding to the desired
> UKI secureboot keys.
>
> Ultimately the latter is probably the more common case and more
> flexible.
>

I don't think there can ever be a one-size-fits all base measurement
to seal secrets to, since there's always the final variable of the
workload.


-- 
-Dionna Glaze, PhD (she/her)