[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new bloc
From: |
Daniel P. Berrange |
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 11:33:53 +0000 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
On Tue, Feb 21, 2017 at 10:59:18AM +0000, Stefan Hajnoczi wrote:
> On Mon, Feb 20, 2017 at 03:34:57AM -0800, ashish mittal wrote:
> > On Mon, Feb 20, 2017 at 3:02 AM, Stefan Hajnoczi <address@hidden> wrote:
> > > On Sat, Feb 18, 2017 at 12:30:31AM +0000, Ketan Nilangekar wrote:
> > >> On 2/17/17, 1:42 PM, "Jeff Cody" <address@hidden> 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?
Any use of the VM UUID as a means to control authorization on the
server side is a security flaw, as this is a public value which
cannot be trusted on its own.
There needs to be some kind of authentication step to verify the
reported identity, eg a password associated with the VM UUID that
is validated before trusting the VM UUID.
Alternatively there needs to be a completely separate UUID, unrelated
to the VM UUID, which is treated as a private value (eg uses the
'-object secret' framework in QEMU)
> 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).
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/ :|
- Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs", (continued)
Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs", ashish mittal, 2017/02/16
- Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs", Jeff Cody, 2017/02/17
- Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs", Ketan Nilangekar, 2017/02/17
- Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs", Daniel P. Berrange, 2017/02/20
- Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs", Stefan Hajnoczi, 2017/02/20
- Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs", ashish mittal, 2017/02/20
- Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs", Stefan Hajnoczi, 2017/02/21
- Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs",
Daniel P. Berrange <=
- Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs", Stefan Hajnoczi, 2017/02/22
- Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs", Daniel P. Berrange, 2017/02/22
- Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs", Jeff Cody, 2017/02/22
- Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs", ashish mittal, 2017/02/23
- Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs", Daniel P. Berrange, 2017/02/24
- Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs", ashish mittal, 2017/02/24
- Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs", Daniel P. Berrange, 2017/02/27
- Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs", ashish mittal, 2017/02/28
Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs", Ketan Nilangekar, 2017/02/21
Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs", Daniel P. Berrange, 2017/02/21