Re: SVSM draft specification

James Bottomley <[email protected]> Wed, 02 Jul 2025 08:44:59 -0400
Newsgroups dev.linux.lists.coconut-svsm
Message-ID <b2cab079872b6e0588743d4f93a769f1844cda6e.camel@HansenPartnership.com>
On Wed, 2025-07-02 at 08:28 -0400, James Bottomley wrote:
[...]
>    3. Preventing updates to db/dbx will require code changes to the
>       reference implementation ... that's always a bad idea since it
>       moves us away from what the TCG publishes and means we have to
>       keep an out of tree patch.  What's the point of it anyway?  The
>       way to ensure the guest can't update db/dbx is what we have
> today
>       for physical systems: not knowing the private key in KEK.

Sorry, not enough tea yet.  This, again, is actually nothing to do with
the TPM (so at least we wouldn't have to change the implementation). 
However, even if we get a UEFI flash persistence service, updates to
variables will again be the province of OVMF and the SVSM will just be
providing backing storage.  Sure, it can snoop the updates but it still
looks like something that's already covered adequately today as stated
above.

Regards,

James