Re: SVSM draft specification

On 7/2/25 06:40, Geoffrey Ndu wrote:
> 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."

Ah, forgot to remove this statement when I removed the db/dbx from the
manifest. Will delete this.

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

Got it.

Thanks,
Tom

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