Re: SVSM draft specification

Comments and Suggestions:

* Bit 2 of Flags (Table 23):

The description for bit 2 is, "Secure boot databases are updatable by
the guest (db/dbx)."

Does this also apply to other updatable Secure Boot databases like
Platform Key (PK), Key Exchange Key (KEK), and Timestamp Signature
Database (dbt)? If not, perhaps allocating one bit per UEFI database
could enhance flexibility.

* Confusing Statement:

The following statement is unclear:

"If a database does not contain any data or is not present, the offset
and size for that database must be 0."

My understanding is that bit 2 is meant to specify whether databases
are updatable, not to define thier sizes.. Could you clarify this?

* Typo:

There is a typo in the text: "Secure boot is enabledn." It should be  "enabled."


Geoffrey

On Mon, Jun 30, 2025 at 5:38 PM Tom Lendacky <[email protected]> wrote:
>
> Attached is a draft specification with the following changes:
>
>   - New single service extended attestation request
>   - vTPM service update for single service extended attestation request
>   - UEFI Management Mode service
>     - Needs references to the request/response formats
>   - Placeholder for the APIC emulation service
>
> I just noticed that Dionna is now looking instead at adding a new
> manifest version that would return a list of the various forms of the
> storage and signing keys. This would eliminate any kernel changes as the
> caller would now just request the new manifest version in the attest
> single service request.
>
> I would prefer this as it would eliminate the need for the single
> service extended attestation request and support for that within each
> service. For now, this draft specification has the original changes
> requested. Please review at least for the UEFI MM service, if the
> direction is to move to a new vTPM manifest version.
>
> Thanks,
> Tom