[libvirt] [PATCH v5 05/10] qemu: add support to launch SEV guest

[Brijesh Singh]

On 04/04/2018 09:22 AM, John Ferlan wrote:
> 
> I understand - your other option is to make required. This is one of
> those cases where there is a gray area with respect to libvirt picking
> some default or policy that we generally prefer to avoid.
> 

I think now I am more inclined towards making it required from libvirt 
-- this matches with SEV spec.


> As noted before/elsewhere - what happens when the default changes...
> 


Theoretically speaking, change in default policy should not cause any 
issue when creating the guest. But the policy change can limit us what a 
hypervisor can do after the boots, e.g disable or disable debug, 
migration or save/restore etc.


On side note, I will be going on 4 weeks of paternity leave starting 
next week and will submit the series after I am back from leave.


>>>> +    }
>>> Check out storageBackendCreateQemuImgSecretPath which just goes straight
>>> to safewrite when writing to the file or qemuDomainWriteMasterKeyFile
>>> which is a similar w/r/t a single key file for the domain.
>>>
>>> The one thing to think about being the privileges for the file being
>>> created and written and the expectations for QEMU's usage. I think this
>>> is more like the storage secret code, but I could be wrong!
>>
>> The data is public in this case, we do not need to protect it with
>> secret. Hence I am keeping all this certificate keys in unsecure place.
> 
> It wasn't so much the public keys as it was me (more or less) thinking
> out loud about the protections on the file that you're "temporarily"
> creating and using to pass the keys.
> 
> I noted two other areas which libvirt does something similarly - one is
> the master public key file for decrypting the AES secrets for
> libvirt/qemu secret manipulation.  The second is the "temporary" file we
> create in the storage driver to handle the luks encryption password for
> create/resize of a luks encrypted file when using qemu-img. Now that is
> slightly different than using a temporary file for the emulator binary.
> 
> In any case, since you're creating in libDir it's probably OK as is, but
> I know when reading files libvirt creates which qemu will use there have
> been issues in the past - I always have to refresh my memory what those
> issues are though.
> 


IIRC, Daniel recommended to use libDir in previous reviews, if its not a 
big deal then we lets use libDir in initial patches and if need arises 
then we can revisit it later.

thanks for all your feedback.