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

From: Ketan Nilangekar <Ketan.Nilangekar@veritas.com>
To: "Daniel P. Berrange" <berrange@redhat.com>,
	Stefan Hajnoczi <stefanha@gmail.com>
Cc: Buddhi Madhav <Buddhi.Madhav@veritas.com>,
	ashish mittal <ashmit602@gmail.com>,
	Paolo Bonzini <pbonzini@redhat.com>, Jeff Cody <jcody@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>, Kevin Wolf <kwolf@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Fam Zheng <famz@redhat.com>,
	Ashish Mittal <Ashish.Mittal@veritas.com>,
	Abhijit Dey <Abhijit.Dey@veritas.com>,
	"Venkatesha M.G." <Venkatesha.Mg@veritas.com>,
	Nitin Jerath <Nitin.Jerath@veritas.com>,
	Gaurav Bhandarkar <Gaurav.Bhandarkar@veritas.com>,
	Abhishek Kane <Abhishek.Kane@veritas.com>,
	Ketan Mahajan <Ketan.Mahajan@veritas.com>,
	Niranjan Pendharkar <Niranjan.Pendharkar@veritas.com>,
	Nirendra Awasthi <Nirendra.Awasthi@veritas.com>,
	Rakesh Ranjan <Rakesh.Ranjan@veritas.com>
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	[thread overview]
Message-ID: <49FDD34F-2649-4437-AC4F-4C1C91FEA15C@veritas.com> (raw)
In-Reply-To: <20170202101537.GE2915@redhat.com>

On 2/2/17, 2:15 AM, "Daniel P. Berrange" <berrange@redhat.com> 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/ :|