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