Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support

[Ketan Nilangekar]

On 2/2/17, 12:57 PM, "Ketan Nilangekar" <address@hidden> wrote:

    
    
    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?
    
[Ketan]
I checked the qio implementation and it seems that there is a pseudo 
implementation of readv/writev which iterates over the individual iovecs to 
make send/recv syscalls. This can’t be too good for performance.
Are you suggesting we use the qio interface for secure communication only and 
leave the unsecure communication to libqnio?

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/ :|