linux-kernel - [PATCH v2] platform/x86: don't unconditionally attach Intel PMC when virtualized

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-next>] [day] [month] [year] [list]

Message-Id: <20221110133335.78442-1-roger.pau@citrix.com>
Date:   Thu, 10 Nov 2022 14:33:35 +0100
From:   Roger Pau Monne <roger.pau@...rix.com>
To:     linux-kernel@...r.kernel.org
Cc:     Roger Pau Monne <roger.pau@...rix.com>,
        "David E . Box" <david.e.box@...ux.intel.com>,
        Rajneesh Bhardwaj <irenic.rajneesh@...il.com>,
        David E Box <david.e.box@...el.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Mark Gross <markgross@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        Juergen Gross <jgross@...e.com>,
        platform-driver-x86@...r.kernel.org, xen-devel@...ts.xenproject.org
Subject: [PATCH v2] platform/x86: don't unconditionally attach Intel PMC when virtualized

The current logic in the Intel PMC driver will forcefully attach it
when detecting any CPU on the intel_pmc_core_platform_ids array,
even if the matching ACPI device is not present.

There's no checking in pmc_core_probe() to assert that the PMC device
is present, and hence on virtualized environments the PMC device
probes successfully, even if the underlying registers are not present.
Previous to 21ae43570940 the driver would check for the presence of a
specific PCI device, and that prevented the driver from attaching when
running virtualized.

Fix by only forcefully attaching the PMC device when not running
virtualized.  Note that virtualized platforms can still get the device
to load if the appropriate ACPI device is present on the tables
provided to the VM.

Make an exception for the Xen initial domain, which does have full
hardware access, and hence can attach to the PMC if present.

Fixes: 21ae43570940 ('platform/x86: intel_pmc_core: Substitute PCI with CPUID enumeration')
Signed-off-by: Roger Pau Monné <roger.pau@...rix.com>
Acked-by: David E. Box <david.e.box@...ux.intel.com>
Cc: Rajneesh Bhardwaj <irenic.rajneesh@...il.com>
Cc: David E Box <david.e.box@...el.com>
Cc: Hans de Goede <hdegoede@...hat.com>
Cc: Mark Gross <markgross@...nel.org>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
Cc: Juergen Gross <jgross@...e.com>
Cc: platform-driver-x86@...r.kernel.org
Cc: xen-devel@...ts.xenproject.org
---
Changes since v1:
 - Use cpu_feature_enabled() instead of boot_cpu_has().
---
 drivers/platform/x86/intel/pmc/pltdrv.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/platform/x86/intel/pmc/pltdrv.c b/drivers/platform/x86/intel/pmc/pltdrv.c
index 15ca8afdd973..4f9fe8a21d8f 100644
--- a/drivers/platform/x86/intel/pmc/pltdrv.c
+++ b/drivers/platform/x86/intel/pmc/pltdrv.c
@@ -18,6 +18,8 @@
 #include <asm/cpu_device_id.h>
 #include <asm/intel-family.h>
 
+#include <xen/xen.h>
+
 static void intel_pmc_core_release(struct device *dev)
 {
 	kfree(dev);
@@ -53,6 +55,14 @@ static int __init pmc_core_platform_init(void)
 	if (acpi_dev_present("INT33A1", NULL, -1))
 		return -ENODEV;
 
+	/*
+	 * Skip forcefully attaching the device for VMs. Make an exception for
+	 * Xen dom0, which does have full hardware access.
+	 */
+	if (cpu_feature_enabled(X86_FEATURE_HYPERVISOR) &&
+	    !xen_initial_domain())
+		return -ENODEV;
+
 	if (!x86_match_cpu(intel_pmc_core_platform_ids))
 		return -ENODEV;
 
-- 
2.37.3