Re: [Qemu-devel] [Qemu-ppc] [PATCH v7 0/2] spapr-rtas: add ibm, get-vpd RTAS interface

[David Gibson <david@gibson.dropbear.id.au>]

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

On Tue, Apr 09, 2019 at 06:24:07PM +0200, Andrea Bolognani wrote:
> Apologies for taking this long to respond.
> 
> 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.

Well, guests are getting this information in smbios somehow.  I don't
know what specifies that what bit of info in the smbios is host info,
but I guess it must at least be a de facto convention?

> 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.

Uh.. I'm not sure about that.  I think the default is just to pass
nothing here.  The confusion is increased because this host info was
always handled at the above-libvirt (openstack) level on x86, using
explicit smbios configuration options down to libvirt and qemu.

On power we handled it in qemu, because that seemed the obvious way,
but it makes recombining them a pain.

> >From libvirt's point of view, the entire mechanism is entirely
> optional, so unless the management layer explicitly asks it to set
> a certain value for the serial, libvirt will simply pass no
> information down to QEMU.
> 
> The relevant XML elements[2] are clearly modeled after x86, so I
> wonder if Nova is setting them also on ppc64 and if so, what the
> guest will ultimately see...
> 
> > > Cc'ing Andrea for expertise. Problem exposed below.
> > > 
> > > The pseries machine used to expose the content of the host's
> > > /proc/device-tree/system-id and /proc/device-tree/model in the guest
> > > DT. This led to a CVE and QEMU doesn't do that anymore for new machine
> > > types. Instead, two new properties where added to the pseries machine:
> > > 
> > > pseries-4.0.host-serial=string (Host serial number to advertise in guest device tree)
> > > pseries-4.0.host-model=string (Host model to advertise in guest device tree)
> > > 
> > > It is up to the caller to pass something... which may be anything,
> > > including something like $(cat /proc/device-tree/system-id) or
> > > randomly generated.
> 
> What happens if the caller doesn't provide any value? Will QEMU come
> up with something itself?

Currently, no, it will just omit the properties.

> Adding a few extra knobs in the vein as the existing ones sounds like
> a fairly reasonable idea. It will still be up to the management layer
> to actually provide the values.
> 
> > > Is there a chance libvirt can be taught to pass a different string
> > > to the target QEMU in case of migration ?
> 
> libvirt already supports providing a different XML to the target
> host, so changing a couple values should be no big deal.
> 
> 
> As a final note, unless I've gotten it wrong and x86 actually *does*
> provide a way for the guest to figure out its host's serial, then any
> software relying on the attributes defined by SPAPR is ultimately not
> portable to non-ppc64 hardware and should probably be rearchitected
> to go through the management layer, as Daniel was also suggesting
> earlier in the thread.
> 
> 
> [1] https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L364-L372
> [2] https://libvirt.org/formatdomain.html#elementsSysinfo

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

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