This series adds support for the -machine,host-model= QEMU option for
for pseries guests.

Pseries guests used to have a node (/proc/device-tree/host-model) in
device-tree that exposed the host's model string so that guest
userspace tools could determine the host machine they were running on.

QEMU used to provide the node by default, but this has been disabled
due to security concerns. There is now a machine option (host-model)
that allows the user to set an arbitrary string to be used as the host
model.

Userspace tools will then be broken unless the user explicitly edits
the domain XML with the desired host model to be exposed to the
guest. However, having an arbitrary string in the domain XML that
needs to be the same for every guest in that machine but different
across host machines would generate issues with XML portability and
more importantly, migration.

So this series implements a generic way for an administrator to enable
the old behavior for a specific guest without allowing arbitrary
strings.

Implementation note:

The 'host-serial' property, which reads /proc/device-tree/system-id in
the host and was also addressed by the QEMU change could be
implemented similarly in the future.

However I see that we're currently populating smbios structures
(virSysinfoDef) with info gathered from /proc/cpuinfo for
architectures that do not use smbios and I think that should be
addressed first.

My idea is to perhaps create new sysinfo types like the existing
'smbios', such as 'cpuinfo' and 'device-tree'.

So to keep the two discussions separated I took advantage of the fact
that the host model happens to also be present at /proc/cpuinfo and
used the smbios structures for now.


Fabiano Rosas (2):
  qemu: Add capability for pseries machine 'host-model' parameter
  qemu: Add support for pseries 'host-model' machine parameter

 docs/formatdomain.html.in                     |  9 ++++++
 docs/schemas/domaincommon.rng                 |  5 ++++
 src/conf/domain_conf.c                        |  4 +++
 src/conf/domain_conf.h                        |  1 +
 src/qemu/qemu_capabilities.c                  |  2 ++
 src/qemu/qemu_capabilities.h                  |  1 +
 src/qemu/qemu_command.c                       | 25 ++++++++++++++--
 src/qemu/qemu_domain.c                        |  1 +
 .../qemucapabilitiesdata/caps_4.0.0.ppc64.xml |  1 +
 tests/qemuxml2argvdata/pseries-features.args  |  3 +-
 tests/qemuxml2argvdata/pseries-features.xml   |  1 +
 tests/qemuxml2argvtest.c                      | 30 ++++++++++++++++++-
 tests/qemuxml2xmloutdata/pseries-features.xml |  1 +
 13 files changed, 79 insertions(+), 5 deletions(-)

--
2.20.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, Oct 08, 2019 at 01:46:55PM -0300, Fabiano Rosas wrote:
> This series adds support for the -machine,host-model= QEMU option for
> for pseries guests.
> 
> Pseries guests used to have a node (/proc/device-tree/host-model) in
> device-tree that exposed the host's model string so that guest
> userspace tools could determine the host machine they were running on.
> 
> QEMU used to provide the node by default, but this has been disabled
> due to security concerns. There is now a machine option (host-model)
> that allows the user to set an arbitrary string to be used as the host
> model.
> 
> Userspace tools will then be broken unless the user explicitly edits
> the domain XML with the desired host model to be exposed to the
> guest. However, having an arbitrary string in the domain XML that
> needs to be the same for every guest in that machine but different
> across host machines would generate issues with XML portability and
> more importantly, migration.

What userspace tool is broken, and in what way ?

Re-introducing the host passthrough to satisfy a broken tool is not
very attractive because it reintroduces the security flaw that the
QEMU change was fixing.

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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Daniel P. Berrangé <berrange@redhat.com> writes:

> What userspace tool is broken, and in what way ?

The major use case, as far as I know, is from software license
managers which use this to determine how much to charge for
software. I would have to ask around to know exactly which ones and
how they operate.

> Re-introducing the host passthrough to satisfy a broken tool is not
> very attractive because it reintroduces the security flaw that the
> QEMU change was fixing.

Sure, this is reasonable. I'm just trying to make it less painful for
those that depend on the old behavior for some reason. =)

Determined folks will probably just use <qemu:commandline> anyway.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Wed, Oct 09, 2019 at 02:29:37PM -0300, Fabiano Rosas wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > What userspace tool is broken, and in what way ?
> 
> The major use case, as far as I know, is from software license
> managers which use this to determine how much to charge for
> software. I would have to ask around to know exactly which ones and
> how they operate.

Mostly such code should not need to know the real host model / serial
information. It should be sufficient to pass through fake data, as
long it is consistently fake for all VMs on the same host.

Still license managers like this are doomed in a virtualized world
as it is trivial to fake the information they're relying on.

> > Re-introducing the host passthrough to satisfy a broken tool is not
> > very attractive because it reintroduces the security flaw that the
> > QEMU change was fixing.
> 
> Sure, this is reasonable. I'm just trying to make it less painful for
> those that depend on the old behavior for some reason. =)
> 
> Determined folks will probably just use <qemu:commandline> anyway.

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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list