linux-kernel - Re: [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <86muj36k0v.wl-marc.zyngier@arm.com>
Date:   Fri, 31 May 2019 10:38:40 +0100
From:   Marc Zyngier <marc.zyngier@....com>
To:     "Raslan, KarimAllah" <karahmed@...zon.de>
Cc:     "Sironi, Filippo" <sironi@...zon.de>,
        "Graf, Alexander" <graf@...zon.com>,
        "boris.ostrovsky@...cle.com" <boris.ostrovsky@...cle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "cohuck@...hat.com" <cohuck@...hat.com>,
        "konrad.wilk@...cle.com" <konrad.wilk@...cle.com>,
        "borntraeger@...ibm.com" <borntraeger@...ibm.com>,
        "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
        Christoffer Dall <Christoffer.Dall@....com>
Subject: Re: [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries

On Fri, 31 May 2019 10:12:03 +0100,
"Raslan, KarimAllah" <karahmed@...zon.de> wrote:
> 
> On Fri, 2019-05-31 at 11:06 +0200, Alexander Graf wrote:
> > On 17.05.19 17:41, Sironi, Filippo wrote:
> > > 
> > > > 
> > > > On 16. May 2019, at 15:50, Graf, Alexander <graf@...zon.com> wrote:
> > > > 
> > > > On 14.05.19 08:16, Filippo Sironi wrote:
> > > > > 
> > > > > Start populating /sys/hypervisor with KVM entries when we're running on
> > > > > KVM. This is to replicate functionality that's available when we're
> > > > > running on Xen.
> > > > > 
> > > > > Start with /sys/hypervisor/uuid, which users prefer over
> > > > > /sys/devices/virtual/dmi/id/product_uuid as a way to recognize a virtual
> > > > > machine, since it's also available when running on Xen HVM and on Xen PV
> > > > > and, on top of that doesn't require root privileges by default.
> > > > > Let's create arch-specific hooks so that different architectures can
> > > > > provide different implementations.
> > > > > 
> > > > > Signed-off-by: Filippo Sironi <sironi@...zon.de>
> > > > I think this needs something akin to
> > > > 
> > > >   https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-hypervisor-xen
> > > > 
> > > > to document which files are available.
> > > > 
> > > > > 
> > > > > ---
> > > > > v2:
> > > > > * move the retrieval of the VM UUID out of uuid_show and into
> > > > >   kvm_para_get_uuid, which is a weak function that can be overwritten
> > > > > 
> > > > > drivers/Kconfig              |  2 ++
> > > > > drivers/Makefile             |  2 ++
> > > > > drivers/kvm/Kconfig          | 14 ++++++++++++++
> > > > > drivers/kvm/Makefile         |  1 +
> > > > > drivers/kvm/sys-hypervisor.c | 30 ++++++++++++++++++++++++++++++
> > > > > 5 files changed, 49 insertions(+)
> > > > > create mode 100644 drivers/kvm/Kconfig
> > > > > create mode 100644 drivers/kvm/Makefile
> > > > > create mode 100644 drivers/kvm/sys-hypervisor.c
> > > > > 
> > > > [...]
> > > > 
> > > > > 
> > > > > +
> > > > > +__weak const char *kvm_para_get_uuid(void)
> > > > > +{
> > > > > +	return NULL;
> > > > > +}
> > > > > +
> > > > > +static ssize_t uuid_show(struct kobject *obj,
> > > > > +			 struct kobj_attribute *attr,
> > > > > +			 char *buf)
> > > > > +{
> > > > > +	const char *uuid = kvm_para_get_uuid();
> > > > > +	return sprintf(buf, "%s\n", uuid);
> > > > The usual return value for the Xen /sys/hypervisor interface is
> > > > "<denied>". Wouldn't it make sense to follow that pattern for the KVM
> > > > one too? Currently, if we can not determine the UUID this will just
> > > > return (null).
> > > > 
> > > > Otherwise, looks good to me. Are you aware of any other files we should
> > > > provide? Also, is there any reason not to implement ARM as well while at it?
> > > > 
> > > > Alex
> > > This originated from a customer request that was using /sys/hypervisor/uuid.
> > > My guess is that we would want to expose "type" and "version" moving
> > > forward and that's when we hypervisor hooks will be useful on top
> > > of arch hooks.
> > > 
> > > On a different note, any idea how to check whether the OS is running
> > > virtualized on KVM on ARM and ARM64?  kvm_para_available() isn't an
> > 
> > 
> > Yeah, ARM doesn't have any KVM PV FWIW. I also can't find any explicit 
> > hint passed into guests that we are indeed running in KVM. The closest 
> > thing I can see is the SMBIOS product identifier in QEMU which gets 
> > patched to "KVM Virtual Machine". Maybe we'll have to do with that for 
> > the sake of backwards compatibility ...
> 
> How about "psci_ops.conduit" (PSCI_CONDUIT_HVC vs PSCI_CONDUIT_SMC)?

[changing Christoffer address for one that actually]

That's not enough. HVC only tells you about the fact that you are
running under a hypervisor without telling you which one, and doesn't
cater for nested virt. It doesn't tell you anything about a hypervisor
that doesn't use HVC at all (it could only advertise SMC, for example).

If you want to identify the hypervisor, don't guess. Use the SMCCC
discovery mechanism, and make KVM identify itself as the hypervisor. I
have some code for that stashed at [1] as part of an unrelated series,
which I may post at some point.

Thanks,

	M.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/pvcy

-- 
Jazz is not dead, it just smell funny.