Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs"

From: Stefan Hajnoczi <stefanha@gmail.com>
To: ashish mittal <ashmit602@gmail.com>
Cc: Ketan Nilangekar <Ketan.Nilangekar@veritas.com>,
	Jeff Cody <jcody@redhat.com>, qemu-devel <qemu-devel@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	Fam Zheng <famz@redhat.com>,
	Ashish Mittal <Ashish.Mittal@veritas.com>,
	John Ferlan <jferlan@redhat.com>,
	Buddhi Madhav <Buddhi.Madhav@veritas.com>,
	Suraj Singh <Suraj.Singh@veritas.com>,
	Nitin Jerath <Nitin.Jerath@veritas.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Abhijit Dey <Abhijit.Dey@veritas.com>,
	"Venkatesha M.G." <Venkatesha.Mg@veritas.com>,
	Rakesh Ranjan <Rakesh.Ranjan@veritas.com>
Subject: Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs"
Date: Tue, 21 Feb 2017 10:59:18 +0000	[thread overview]
Message-ID: <20170221105918.GA22731@stefanha-x1.localdomain> (raw)
In-Reply-To: <CAAo6VWNwHbsQRxU18dNCjWaNfNrZNAV9FfOKW8=JeZCND2vHnQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]

On Mon, Feb 20, 2017 at 03:34:57AM -0800, ashish mittal wrote:
> On Mon, Feb 20, 2017 at 3:02 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > On Sat, Feb 18, 2017 at 12:30:31AM +0000, Ketan Nilangekar wrote:
> >> On 2/17/17, 1:42 PM, "Jeff Cody" <jcody@redhat.com> wrote:
> >>
> >>     On Thu, Feb 16, 2017 at 02:24:19PM -0800, ashish mittal wrote:
> >>     > Hi,
> >>     >
> >>     > I am getting the following error with checkpatch.pl
> >>     >
> >>     > ERROR: externs should be avoided in .c files
> >>     > #78: FILE: block/vxhs.c:28:
> >>     > +QemuUUID qemu_uuid __attribute__ ((weak));
> >>     >
> >>     > Is there any way to get around this, or does it mean that I would have
> >>     > to add a vxhs.h just for this one entry?
> >>     >
> >>
> >>     I remain skeptical on the use of the qemu_uuid as a way to select the TLS
> >>     cert.
> >>
> >> [ketan]
> >> Is there another identity that can be used for uniquely identifying instances?
> >> The requirement was to enforce vdisk access to owner instances.
> >
> > The qemu_uuid weak attribute looks suspect.  What is going to provide a
> > strong qemu_uuid symbol?
> >
> > Why aren't configuration parameters like the UUID coming from the QEMU
> > command-line?
> >
> > Stefan
> 
> UUID will in fact come from the QEMU command line. VxHS is not doing
> anything special here. It will just use the value already available to
> qemu-kvm process.
> 
> QemuUUID qemu_uuid;
> bool qemu_uuid_set;
> 
> Both the above are defined in vl.c. vl.c will provide the strong
> symbol when available. There are certain binaries that do not get
> linked with vl.c (e.g. qemu-img). The weak symbol will come into
> affect for such binaries, and in this case, the default VXHS UUID will
> get picked up. I had, in a previous email, explained how we plan to
> use the default UUID. In the regular case, the VxHS controller will
> not allow access to the default UUID (non qemu-kvm) binaries, but it
> may choose to grant temporary access to specific vdisks for these
> binaries depending on the workflow.

That idea sounds like a security problem.  During this time window
anyone could use the default UUID to access the data?

Just make the UUID (or TLS client certificate file) a command-line
parameter that qemu-system, qemu-img, and other tools accept (e.g.
qemu-img via the --image-opts/--object syntax).

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]