Il 20/03/26 16:03, Tommaso Califano ha scritto:
>
>
> 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
LAUNCH_UPDATE_DATA is supported in the sense that the called
memory regions are saved for measurement calculation. With this
method, even if kernel-hashes is active, the measurement remains
correct and the attestation workflow stays the same.
Thinking of it now, I could add a small improvement by checking
if the memory region is already in the QEMUIOVector ld_data,
avoiding multiple addition of the same region.
>>>
>>>
>>> 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).
>
Apologies for the multiple emails; I forgot to explain the kernel-hashes
implementation.
Best regards,
Tommaso Califano
