| 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
| ||
|
Message-ID:
<SN6PR02MB41576A5C3C0F5911A308E804D4BC2@SN6PR02MB4157.namprd02.prod.outlook.com>
Date: Thu, 17 Apr 2025 15:27:46 +0000
From: Michael Kelley <mhklinux@...look.com>
To: Roman Kisel <romank@...ux.microsoft.com>, "arnd@...db.de" <arnd@...db.de>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>, "bp@...en8.de" <bp@...en8.de>,
"catalin.marinas@....com" <catalin.marinas@....com>, "conor+dt@...nel.org"
<conor+dt@...nel.org>, "dan.carpenter@...aro.org" <dan.carpenter@...aro.org>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"decui@...rosoft.com" <decui@...rosoft.com>, "haiyangz@...rosoft.com"
<haiyangz@...rosoft.com>, "hpa@...or.com" <hpa@...or.com>,
"joey.gouly@....com" <joey.gouly@....com>, "krzk+dt@...nel.org"
<krzk+dt@...nel.org>, "kw@...ux.com" <kw@...ux.com>, "kys@...rosoft.com"
<kys@...rosoft.com>, "lenb@...nel.org" <lenb@...nel.org>,
"lpieralisi@...nel.org" <lpieralisi@...nel.org>,
"manivannan.sadhasivam@...aro.org" <manivannan.sadhasivam@...aro.org>,
"mark.rutland@....com" <mark.rutland@....com>, "maz@...nel.org"
<maz@...nel.org>, "mingo@...hat.com" <mingo@...hat.com>,
"oliver.upton@...ux.dev" <oliver.upton@...ux.dev>, "rafael@...nel.org"
<rafael@...nel.org>, "robh@...nel.org" <robh@...nel.org>,
"rafael.j.wysocki@...el.com" <rafael.j.wysocki@...el.com>,
"ssengar@...ux.microsoft.com" <ssengar@...ux.microsoft.com>,
"sudeep.holla@....com" <sudeep.holla@....com>, "suzuki.poulose@....com"
<suzuki.poulose@....com>, "tglx@...utronix.de" <tglx@...utronix.de>,
"wei.liu@...nel.org" <wei.liu@...nel.org>, "will@...nel.org"
<will@...nel.org>, "yuzenghui@...wei.com" <yuzenghui@...wei.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-hyperv@...r.kernel.org"
<linux-hyperv@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "linux-pci@...r.kernel.org"
<linux-pci@...r.kernel.org>, "x86@...nel.org" <x86@...nel.org>
CC: "apais@...rosoft.com" <apais@...rosoft.com>, "benhill@...rosoft.com"
<benhill@...rosoft.com>, "bperkins@...rosoft.com" <bperkins@...rosoft.com>,
"sunilmut@...rosoft.com" <sunilmut@...rosoft.com>
Subject: RE: [PATCH hyperv-next v8 02/11] arm64: hyperv: Use SMCCC to detect
hypervisor presence
From: Roman Kisel <romank@...ux.microsoft.com> Sent: Monday, April 14, 2025 3:47 PM
>
> The arm64 Hyper-V startup path relies on ACPI to detect
> running under a Hyper-V compatible hypervisor. That
> doesn't work on non-ACPI systems.
>
> Hoist the ACPI detection logic into a separate function. Then
> use the vendor-specific hypervisor service call (implemented
> recently in Hyper-V) via SMCCC in the non-ACPI case.
>
> Signed-off-by: Roman Kisel <romank@...ux.microsoft.com>
> ---
> arch/arm64/hyperv/mshyperv.c | 50 ++++++++++++++++++++++++++++++++----
> 1 file changed, 45 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
> index 4e27cc29c79e..21458b6338aa 100644
> --- a/arch/arm64/hyperv/mshyperv.c
> +++ b/arch/arm64/hyperv/mshyperv.c
> @@ -28,6 +28,48 @@ int hv_get_hypervisor_version(union
> hv_hypervisor_version_info *info)
> }
> EXPORT_SYMBOL_GPL(hv_get_hypervisor_version);
>
> +#ifdef CONFIG_ACPI
> +
> +static bool __init hyperv_detect_via_acpi(void)
> +{
> + if (acpi_disabled)
> + return false;
> + /*
> + * Hypervisor ID is only available in ACPI v6+, and the
> + * structure layout was extended in v6 to accommodate that
> + * new field.
> + *
> + * At the very minimum, this check makes sure not to read
> + * past the FADT structure.
> + *
> + * It is also needed to catch running in some unknown
> + * non-Hyper-V environment that has ACPI 5.x or less.
> + * In such a case, it can't be Hyper-V.
> + */
> + if (acpi_gbl_FADT.header.revision < 6)
> + return false;
> + return strncmp((char *)&acpi_gbl_FADT.hypervisor_id, "MsHyperV", 8) == 0;
> +}
> +
> +#else
> +
> +static bool __init hyperv_detect_via_acpi(void)
> +{
> + return false;
> +}
> +
> +#endif
> +
> +static bool __init hyperv_detect_via_smccc(void)
> +{
> + uuid_t hyperv_uuid = UUID_INIT(
> + 0x58ba324d, 0x6447, 0x24cd,
> + 0x75, 0x6c, 0xef, 0x8e,
> + 0x24, 0x70, 0x59, 0x16);
I had previously given my Reviewed-by: on v5 of this patch. But
looking at it again, it would be nice if this UUID were defined in
include/linux/arm-smccc.h alongside the definition of
ARM_SMCCC_VENDOR_HYP_UID_KVM. The UUID values are
are independent of each other, but it's a bit asymmetric to have
the KVM UUID defined centrally while the Hyper-V UUID is
buried in Hyper-V specific code. But I'm OK with the current code
if there's nothing else to respin for.
> +
> + return arm_smccc_hypervisor_has_uuid(&hyperv_uuid);
> +}
> +
> static int __init hyperv_init(void)
> {
> struct hv_get_vp_registers_output result;
> @@ -36,13 +78,11 @@ static int __init hyperv_init(void)
>
> /*
> * Allow for a kernel built with CONFIG_HYPERV to be running in
> - * a non-Hyper-V environment, including on DT instead of ACPI.
> + * a non-Hyper-V environment.
> + *
> * In such cases, do nothing and return success.
> */
> - if (acpi_disabled)
> - return 0;
> -
> - if (strncmp((char *)&acpi_gbl_FADT.hypervisor_id, "MsHyperV", 8))
> + if (!hyperv_detect_via_acpi() && !hyperv_detect_via_smccc())
> return 0;
>
> /* Setup the guest ID */
> --
> 2.43.0
>
My UUID comment notwithstanding,
Reviewed-by: Michael Kelley <mhklinux@...look.com>
Powered by blists - more mailing lists