[libvirt] [PATCH v9 4/4] qemu: Add TLS support for Veritas HyperScale (VxHS)

[Daniel P. Berrange]

On Wed, Sep 27, 2017 at 05:08:51PM +0200, Peter Krempa wrote:
> On Wed, Sep 27, 2017 at 11:05:01 -0400, John Ferlan wrote:
> > 
> > 
> > On 09/27/2017 10:25 AM, Peter Krempa wrote:
> > > On Tue, Sep 19, 2017 at 21:32:46 -0400, John Ferlan wrote:
> > >> From: Ashish Mittal <Ashish.Mittal at veritas.com>
> > >>
> > >> Alter qemu command line generation in order to possibly add TLS for
> > >> a suitably configured domain.
> > >>
> > >> Sample TLS args generated by libvirt -
> > >>
> > >>     -object tls-creds-x509,id=objvirtio-disk0_tls0,dir=/etc/pki/qemu,\
> > >>     endpoint=client,verify-peer=yes \
> > >>     -drive file.driver=vxhs,file.tls-creds=objvirtio-disk0_tls0,\
> > >>     file.vdisk-id=eb90327c-8302-4725-9e1b-4e85ed4dc251,\
> > >>     file.server.type=tcp,file.server.host=192.168.0.1,\
> > >>     file.server.port=9999,format=raw,if=none,\
> > >>     id=drive-virtio-disk0,cache=none \
> > >>     -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,\
> > >>     id=virtio-disk0
> > >>
> > >> Update the qemuxml2argvtest with a couple of examples. One for a
> > >> simple case and the other a bit more complex where multiple VxHS disks
> > >> are added where at least one uses a VxHS that doesn't require TLS
> > >> credentials and thus sets the domain disk source attribute "tls = 'no'".
> > >>
> > >> Update the hotplug to be able to handle processing the tlsAlias whether
> > >> it's to add the TLS object when hotplugging a disk or to remove the TLS
> > >> object when hot unplugging a disk.  The hot plug/unplug code is largely
> > >> generic, but the addition code does make the VXHS specific checks only
> > >> because it needs to grab the correct config directory and generate the
> > >> object as the command line would do.
> > >>
> > >> Signed-off-by: Ashish Mittal <Ashish.Mittal at veritas.com>
> > >> Signed-off-by: John Ferlan <jferlan at redhat.com>
> > >> ---
> > >>  src/qemu/qemu_block.c                              |  8 +++
> > >>  src/qemu/qemu_command.c                            | 33 +++++++++
> > >>  src/qemu/qemu_hotplug.c                            | 79 ++++++++++++++++++++++
> > >>  ...-disk-drive-network-tlsx509-multidisk-vxhs.args | 43 ++++++++++++
> > >>  ...v-disk-drive-network-tlsx509-multidisk-vxhs.xml | 50 ++++++++++++++
> > >>  ...muxml2argv-disk-drive-network-tlsx509-vxhs.args | 30 ++++++++
> > >>  tests/qemuxml2argvtest.c                           |  7 ++
> > >>  7 files changed, 250 insertions(+)
> > >>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-multidisk-vxhs.args
> > >>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-multidisk-vxhs.xml
> > >>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-vxhs.args
> 
> [...]
> 
> > >> diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
> > >> index 7dd6e5fd9..7751a608d 100644
> > >> --- a/src/qemu/qemu_hotplug.c
> > >> +++ b/src/qemu/qemu_hotplug.c
> > >> @@ -156,6 +156,52 @@ qemuDomainPrepareDisk(virQEMUDriverPtr driver,
> > >>  
> > >>  
> > >>  static int
> > >> +qemuDomainAddDiskSrcTLSObject(virQEMUDriverPtr driver,
> > >> +                              virDomainObjPtr vm,
> > >> +                              virStorageSourcePtr src,
> > >> +                              const char *srcalias)
> > >> +{
> > >> +    int ret = -1;
> > >> +    qemuDomainObjPrivatePtr priv = vm->privateData;
> > >> +    virJSONValuePtr tlsProps = NULL;
> > >> +
> > >> +    /* NB: Initial implementation doesn't require/use a secret to decrypt
> > >> +     * a server certificate, so there's no need to manage a tlsSecAlias
> > > 
> > > client certificate
> > > 
> > 
> > No it's the server certificate (server-key.pem) that needs the secret in
> > order to be decrypted.
> 
> I think both can be encrypted. What I wanted to point out is that it
> does not make sense to refer to the server certificate in terms of disks
> since they are clients only.

I don't think so - AFAIK, the 'password' provided to gnutls in
gnutls_certificate_set_x509_key_file2 is only used for the 'key',
not the 'cert' data.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|