[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