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

[Andrea Bolognani]

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.

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.

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

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
-- 
Andrea Bolognani / Red Hat / Virtualization