qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Greg Kurz <groug@kaod.org>
Cc: Andrea Bolognani <abologna@redhat.com>,
	qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
	"Maxiwell S. Garcia" <maxiwell@linux.ibm.com>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v7 0/2] spapr-rtas: add ibm, get-vpd RTAS interface
Date: Fri, 12 Apr 2019 16:07:07 +0100	[thread overview]
Message-ID: <20190412150707.GD25308@redhat.com> (raw)
In-Reply-To: <20190412165701.44079175@bahia.lan>

On Fri, Apr 12, 2019 at 04:57:01PM +0200, Greg Kurz wrote:
> On Tue, 09 Apr 2019 18:24:07 +0200
> Andrea Bolognani <abologna@redhat.com> wrote:
> 
> > Apologies for taking this long to respond.
> > 
> 
> No problem :)
> 
> > On Mon, 2019-04-08 at 14:27 +1000, David Gibson wrote:
> > > On Tue, Apr 02, 2019 at 12:28:07PM +0200, Greg Kurz wrote:  
> > > > The recent fixes around "host-serial" and "host-model" simply moved
> > > > the decision to expose host data to the upper layer, ie. libvirt
> > > > which should be involved in this discussion.  
> > > 
> > > Right, that's deliberate.  Note that roughly-equivalent information on
> > > x86 is currently supplied via the SMBIOS.  OpenStack Nova sets that,
> > > rather than qemu, and I'd like to move towards a common configuration
> > > model with x86, though it's a fairly long path to there.
> > > 
> > > OpenStack had an equivalent security problem to our one, which it
> > > addressed by taking the host serial from /etc/machine-id if present
> > > rather than the real host info.  
> > 
> > IIUC the situation is a bit different between x86 and ppc64, because
> > while for the latter SPAPR defines a way for the guest to access
> > information about the host it's running on, that's not the case for
> > the former, at least to the best of my knowledge.
> > 
> > What OpenStack is doing is reading the machine-id (if explicitly
> > configured to do so: the default is to use the guest's own UUID[1])
> > and exposing that as the *guest* serial, not as the *host* serial.
> > 
> 
> Hmm... are you sure ? Daniel seems to be saying the opposite here:
> 
> https://bugs.launchpad.net/nova/+bug/1337349/comments/9

Note my comment is from 2014, where as Andrea is describing OpenStack's
impl in 2019 :-)

Originally Nova would populate guest SMBIOS with a UUID taken
from Host SMBIOS

My fix for the security problem made it use host /etc/machine-id
instead of Host SMBIOS when /etc/machine-id is available.

In Nova 2018, Nova was changed to use the guest instance UUID
instead of /etc/machine-id by default.

Anyway the key factor is to *never* expose and UUID you get
from the host hardware as vendors frequently treat these as
semi-secret keys.

If you need a UUID, it has to be software generated from
somewhere and not otherwise need to be kept private.

As long as QEMU lets this be configurable, libvirt can plumb
it into its sysinfo XML and thus we can ultimately delegate
the decision to the mgmt app like OpenStack.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

WARNING: multiple messages have this Message-ID (diff)
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Greg Kurz <groug@kaod.org>
Cc: David Gibson <david@gibson.dropbear.id.au>,
	qemu-ppc@nongnu.org, Andrea Bolognani <abologna@redhat.com>,
	"Maxiwell S. Garcia" <maxiwell@linux.ibm.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v7 0/2] spapr-rtas: add ibm, get-vpd RTAS interface
Date: Fri, 12 Apr 2019 16:07:07 +0100	[thread overview]
Message-ID: <20190412150707.GD25308@redhat.com> (raw)
Message-ID: <20190412150707.OSDvPCB1slgro_Er4kLx4QfjRxHJ0mhGSZ1KqJSCgvA@z> (raw)
In-Reply-To: <20190412165701.44079175@bahia.lan>

On Fri, Apr 12, 2019 at 04:57:01PM +0200, Greg Kurz wrote:
> On Tue, 09 Apr 2019 18:24:07 +0200
> Andrea Bolognani <abologna@redhat.com> wrote:
> 
> > Apologies for taking this long to respond.
> > 
> 
> No problem :)
> 
> > On Mon, 2019-04-08 at 14:27 +1000, David Gibson wrote:
> > > On Tue, Apr 02, 2019 at 12:28:07PM +0200, Greg Kurz wrote:  
> > > > The recent fixes around "host-serial" and "host-model" simply moved
> > > > the decision to expose host data to the upper layer, ie. libvirt
> > > > which should be involved in this discussion.  
> > > 
> > > Right, that's deliberate.  Note that roughly-equivalent information on
> > > x86 is currently supplied via the SMBIOS.  OpenStack Nova sets that,
> > > rather than qemu, and I'd like to move towards a common configuration
> > > model with x86, though it's a fairly long path to there.
> > > 
> > > OpenStack had an equivalent security problem to our one, which it
> > > addressed by taking the host serial from /etc/machine-id if present
> > > rather than the real host info.  
> > 
> > IIUC the situation is a bit different between x86 and ppc64, because
> > while for the latter SPAPR defines a way for the guest to access
> > information about the host it's running on, that's not the case for
> > the former, at least to the best of my knowledge.
> > 
> > What OpenStack is doing is reading the machine-id (if explicitly
> > configured to do so: the default is to use the guest's own UUID[1])
> > and exposing that as the *guest* serial, not as the *host* serial.
> > 
> 
> Hmm... are you sure ? Daniel seems to be saying the opposite here:
> 
> https://bugs.launchpad.net/nova/+bug/1337349/comments/9

Note my comment is from 2014, where as Andrea is describing OpenStack's
impl in 2019 :-)

Originally Nova would populate guest SMBIOS with a UUID taken
from Host SMBIOS

My fix for the security problem made it use host /etc/machine-id
instead of Host SMBIOS when /etc/machine-id is available.

In Nova 2018, Nova was changed to use the guest instance UUID
instead of /etc/machine-id by default.

Anyway the key factor is to *never* expose and UUID you get
from the host hardware as vendors frequently treat these as
semi-secret keys.

If you need a UUID, it has to be software generated from
somewhere and not otherwise need to be kept private.

As long as QEMU lets this be configurable, libvirt can plumb
it into its sysinfo XML and thus we can ultimately delegate
the decision to the mgmt app like OpenStack.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


  parent reply	other threads:[~2019-04-12 15:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190327204102.20925-1-maxiwell@linux.ibm.com>
     [not found] ` <20190328142151.7b0e00dd@bahia.lab.toulouse-stg.fr.ibm.com>
     [not found]   ` <20190328183923.lcd3p6fpy4qvvxoo@maxibm>
     [not found]     ` <20190329132951.451d4ef0@bahia.lan>
2019-04-01 15:01       ` [Qemu-devel] [Qemu-ppc] [PATCH v7 0/2] spapr-rtas: add ibm, get-vpd RTAS interface Maxiwell S. Garcia
2019-04-02 10:28         ` Greg Kurz
2019-04-03 21:07           ` Daniel Henrique Barboza
2019-04-04  8:45             ` Greg Kurz
2019-04-08  4:27           ` David Gibson
2019-04-08  4:27             ` David Gibson
2019-04-09 16:24             ` Andrea Bolognani
2019-04-09 16:24               ` Andrea Bolognani
2019-04-12 14:57               ` Greg Kurz
2019-04-12 14:57                 ` Greg Kurz
2019-04-12 15:07                 ` Daniel P. Berrangé [this message]
2019-04-12 15:07                   ` Daniel P. Berrangé
2019-07-03  6:53               ` David Gibson
2019-04-08  4:21       ` David Gibson
2019-04-08  4:21         ` David Gibson
2019-04-08 16:31         ` Greg Kurz
2019-04-08 16:31           ` Greg Kurz
2019-04-08 22:34           ` Michael Roth
2019-04-08 22:34             ` Michael Roth
2019-07-03  6:49             ` David Gibson
2019-07-03  6:39           ` David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190412150707.GD25308@redhat.com \
    --to=berrange@redhat.com \
    --cc=abologna@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=groug@kaod.org \
    --cc=maxiwell@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).