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

[Greg Kurz]

On Tue, 09 Apr 2019 18:24:07 +0200
Andrea Bolognani <address@hidden> 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

which was referring to:

https://bugs.launchpad.net/nova/+bug/1337349/comments/6

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

QEMU up to 3.1 used to fill these up with values from directly copied
from the host's device tree. Starting with 4.0, it is up to the caller
to provide values, with no fallback in QEMU.

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

Sure.

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

Oh, I didn't know that, but that's cool. It is likely needed for
what Maxiwell's trying to achieve.

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