qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Verita


From: Ketan Nilangekar
Subject: Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support
Date: Thu, 2 Feb 2017 20:57:11 +0000
User-agent: Microsoft-MacOutlook/f.1c.1.161117


On 2/2/17, 2:15 AM, "Daniel P. Berrange" <address@hidden> wrote:

    On Thu, Feb 02, 2017 at 10:07:28AM +0000, Stefan Hajnoczi wrote:
    > On Wed, Feb 01, 2017 at 11:59:53PM +0000, Ketan Nilangekar wrote:
    > > Patch for secure implementation in libqnio is available for review here:
    > > 
    > > https://github.com/VeritasHyperScale/libqnio/pull/12
    > > 
    > > libqnio client initialization now has an option to use X.509 
certificates to authenticate itself to the vxhs server.  
    > > Also each client IO request now includes an instance id that is used by 
the vxhs server to authorize the request.
    > > A test client has also been added.
    > > Libqnio.so so is renamed to libvxhs.so. We will rename the repository 
once the latest patches are merged.
    > > QEMU patch to use the new secure interface will follow shortly.
    > 
    > I have left comments on specific lines of code on GitHub.
    > 
    > The server should do something based on the client X.509 certificate.
    > Is the code actually verifying certificates on the client side?
    > 
    > Right now the code is just going through the motions of SSL but not
    > protecting against man-in-the-middle attacks.
    > 
    > I noticed that the code uses OpenSSL.  QEMU uses GnuTLS instead of
    > OpenSSL.  In practice it's hard to avoid duplication of SSL libraries:
    > GlusterFS and Ceph use OpenSSL and NSS.  That means QEMU KVM may drag in
    > GnuTLS, OpenSSL, and NSS!  But from a QEMU point of view it would be
    > nicest to use GnuTLS to keep extra library dependencies minimal.
    
    These points are all reasons why libqnio should not do anything TLS
    related at all. It should delegate all actual I/O to QEMU, so that we
    can use our existing QIO logic for TLS that is tried & tested, as well
    as integrating with existing QEMU infrastructure. ie, ability to use
    object_add QMP command to register TLS certificates with QEMU, instead
    of hardcoding their location on disk in libqnio
    
[Ketan]
Does the QIO interface allow for readv/writev over network for unsecure sockets?

    Regards,
    Daniel
    -- 
    |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ 
:|
    |: http://libvirt.org              -o-             http://virt-manager.org 
:|
    |: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ 
:|
    


reply via email to

[Prev in Thread] Current Thread [Next in Thread]