Il 20/03/26 13:39, Daniel P. Berrangé ha scritto:
> On Thu, Mar 19, 2026 at 05:49:18PM +0000, Daniel P. Berrangé wrote:
>> On Tue, Mar 17, 2026 at 12:38:36PM +0100, Tommaso Califano wrote:
>>> With this change it is possible to run a VM with the SEV CPUID active
>>> adding:
>>>
>>> -accel tcg \
>>> -object sev-emulated,id=sev0,cbitpos=47,reduced-phys-bits=1 \
>>> -machine memory-encryption=sev0
>>
>> snip
>>
>>> diff --git a/qapi/qom.json b/qapi/qom.json
>>> index c653248f85..35cda819ec 100644
>>> --- a/qapi/qom.json
>>> +++ b/qapi/qom.json
>>> @@ -1057,6 +1057,19 @@
>>> '*handle': 'uint32',
>>> '*legacy-vm-type': 'OnOffAuto' } }
>>>
>>> +##
>>> +# @SevEmulatedProperties:
>>> +#
>>> +# Properties for sev-emulated objects.
>>> +# This object functionally emulates AMD SEV hardware via TCG, so
>>> +# it does not require real hardware to run.
>>> +#
>>> +# Since: 10.1.0
>>> +##
>>> +{ 'struct': 'SevEmulatedProperties',
>>> + 'base': 'SevGuestProperties',
>>> + 'data': {}}
>>
>> This is deriving 'sev-emulated' from 'sev-guest' which means it
>> supports all the properties that 'sev-guest' does, which for
>> the record is:
>>
>> sev-guest options:
>> dh-cert-file=<string> - guest owners DH certificate (encoded with base64)
>> kernel-hashes=<bool> - add kernel hashes to guest firmware for measured
>> Linux boot
>> legacy-vm-type=<OnOffAuto> - use legacy VM type to maintain measurement
>> compatibility with older QEMU or kernel versions.
>> session-file=<string> - guest owners session parameters (encoded with
>> base64)
>> sev-device=<string> - SEV device to use
>
> Sigh, I was mislead by '-object sev-guest,help' omitting
> information about anything that is not a class property.
> So there is also
>
> - cbitpos=<int>
> - reduced-phys-bits=<int>
> - handle=<int>
> - policy=<int>
>
>>
>>
>> Of those properties
>>
>> * dh-cert-file + session-file are traditionally used
>> as a means to transfer the TIK+TEK to the SEV firmware,
>> with wrapping to protect them from the hypervisor.
>>
>> These can't be used with sev-emulated, as implemented,
>> since they require a key derivation from the PDH, a
>> concept which IIUC is not implemented in this series.
>>
>> Instead, in a later patch 'tik' and 'tek' properties
>> are added to 'sev-emulated', and to pass the TIK+TEK
>> in clear text.
>>
>> * sev-device + legacy-vm-type - these are only relevant
>> to the KVM integration, so not applicable for emulation
>>
>> * kernel-hashes - would be relevant if formally emulating
>> LAUNCH_UPDATE_DATA for attestation, but IIUC, this is
>> not done/used by this series
>>
>>
>> IOW, we're deriving from 'sev-guest' but AFAICT none of
>> its properties are relevant to the emulation. The
>> dh-cert-file and session-file could potentially be
>> relevant if implementing the PDH concept and key
>> derivation, but that's not done, instead the tik/tek
>> are passed explicitly.
>>
>> What is the value we get from this sev-guest -> sev-emulated
>> inheritance ? My gut feeling is that this perhaps isn't
>> the right way to be modelling things unless there's a plan
>> for future work that would benefit from them.
>>
I know most of these properties aren't used in emulation. I chose
to derive from `sev-guest' primarily for the policy property
(needed for SEV-ES future implementation).
For the TIK and TEK properties, I considered reusing dh-cert-file
and session-file, but since those keys are CPU-generated anyway,
I opted to simplify the cryptographic protocol given the fact
that security isn't the focus here.
That said, you're right that sev-guest inheritance may not add
much value. If you'd prefer interface consistency for testing
(reusing dh-cert-file/session-file) those properties could then
become relevant. Otherwise, for pure SEV emulation, deriving from
sev-common makes sense instead; though I'm unsure how that would
impact the SEV-ES implementation, perhaps we could re-add just the
policy property if needed.
>> Another question related to modelling is whether there is
>> an intention to support SEV-SNP at a later date, would that
>> imply a sev-snp-emulated object type too ? If so, would it
>> inherit from sev-emulated or from sev-snp-guest ?
>>
While I haven't studied it in depth, I think it will. It seems
best to derive a new object (sev-snp-emulated) from sev-guest-snp
because of the sev_snp_enabled() function, which will work through
TYPE_SEV_SNP_GUEST casting (similar to the current sev_enabled()
function).
Best regards,
Tommaso Califano
