On 16.05.19 07:02, Andrew Cooper wrote: > On 16/05/2019 14:50, Alexander Graf 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@xxxxxxxxx> >> 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>". > This string comes straight from Xen. > > It was an effort to reduce the quantity of interesting fingerprintable > data accessable by default to unprivileged guests. > > See > https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=a2fc8d514df2b38c310d4f4432fe06520b0769ed What a great design :). My point is mostly that we should be as common as possible when it comes to /sys/hypervisor, so that tools don't have to care about the HV they're working against. By being first to implement <denied> you just created precedence, so we can either simulate the same behavor for KVM or be different. And since commonality is good, I'd rather be the same. That said, I couldn't find in the patdch above whether Xen even emits <denied> for the uuid. Does it have that capability? If not, we may as well go with (null). Alex
