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(a)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