[RFC PATCH 1/3] libvirt: Introduce virDomainInjectLaunchSecret public API

Jim Fehlig jfehlig at suse.com
Tue Nov 23 17:47:30 UTC 2021


On 11/17/21 03:33, Peter Krempa wrote:
> On Tue, Nov 16, 2021 at 19:23:52 -0700, Jim Fehlig wrote:
>> An API inject a launch secret into the domain's memory.
>>
>> Signed-off-by: Jim Fehlig <jfehlig at suse.com>
>> ---
>>   include/libvirt/libvirt-domain.h |  6 ++++
>>   src/driver-hypervisor.h          |  8 +++++
>>   src/libvirt-domain.c             | 50 ++++++++++++++++++++++++++++++++
>>   src/libvirt_public.syms          |  5 ++++
>>   4 files changed, 69 insertions(+)
> 
> Note that I don't know enough about SEV to do a full review. These are
> merely observations based on the interface of qemu and the documentation
> for them.
> 
> 
>> diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
>> index ce7cafde36..877c65c04f 100644
>> --- a/src/libvirt-domain.c
>> +++ b/src/libvirt-domain.c
>> @@ -12818,6 +12818,56 @@ int virDomainGetLaunchSecurityInfo(virDomainPtr domain,
>>   }
>>   
>>   
>> +/**
>> + * virDomainInjectLaunchSecret:
>> + * @domain: a domain object
>> + * @secrethdr: Base64 encoded secret header
>> + * @secret: Base64 encoded secret
>> + * @injectaddr: Domain memory address where the secret will be injected
>> + * @flags: currently used, set to 0.
>> + *
>> + * Inject a launch secret in the domain's memory. secrethdr and secret are
>> + * passed to the underlying hypervisor as is.
> 
> While this might be true for qemu IMO it doesn't make much sense to
> mention this in the documentation because it's not exactly important to
> the user that it's not modified.

Ok. I need to improve the description in a V1.

> 
>> injectaddr can be used to
>> + * specify an address in the domain memory where the secret will be injected.
>> + * It can be set to 0 for the hypervisor default.
> 
> This makes an assumption that address 0 will never be used to inject the
> secret. Note that qemu actually supports that as the 'gpa' attribute of
> the command is optional, so you can populate it with a 0 to inject into
> address 0.

Good point, thanks!

> In general the API feels too-much tied to the implementation of sev used
> here and IMO isn't future proof, but I don't have enough examples to
> prove my point.

Using virTypedParams for input will help with future-proofness. I'm still not 
fond of the API name. I see Daniel has suggested a better name. I'll respond to 
his post with some other ideas I had.

Regards,
Jim




More information about the libvir-list mailing list