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] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Jan 2024 05:10:47 +0000
From: Michael Kelley <mhklinux@...look.com>
To: Saurabh Sengar <ssengar@...ux.microsoft.com>, "kys@...rosoft.com"
	<kys@...rosoft.com>, "haiyangz@...rosoft.com" <haiyangz@...rosoft.com>,
	"wei.liu@...nel.org" <wei.liu@...nel.org>, "decui@...rosoft.com"
	<decui@...rosoft.com>, "tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "x86@...nel.org"
	<x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
	"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: "ssengar@...rosoft.com" <ssengar@...rosoft.com>
Subject: RE: [PATCH] x86/hyperv: Allow 15-bit APIC IDs for VTL platforms

From: Saurabh Sengar <ssengar@...ux.microsoft.com> Sent: Friday, January 5, 2024 2:29 AM
> 
> The current method for signaling the compatibility of a Hyper-V host
> with MSIs featuring 15-bit APIC IDs relies on a synthetic cpuid leaf.
> However, for higher VTLs, this leaf is not reported, due to the absence
> of an IO-APIC.
> 
> As an alternative, assume that when running at a high VTL, the host
> supports 15-bit APIC IDs. This assumption is now deemed safe, as no
> architectural MSIs are employed at higher VTLs.

I'm trying to fully understand this last sentence.  It has the words
"now" and "deemed" as qualifiers.  Can you say anything more about
why "now" (implying it wasn't safe at some point in the past)?
And what are the implications of "deemed"?  Or are both just
wordiness, and it would be just as good to say "This assumption is safe,
as Hyper-V does not employ any architectural MSIs at higher VTLs." ?

The code LGTM.

Michael

> 
> This unblocks startup of VTL2 environments with more than 256 CPUs.
> 
> Signed-off-by: Saurabh Sengar <ssengar@...ux.microsoft.com>
> ---
>  arch/x86/hyperv/hv_vtl.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
> index 539c7b5cfa2b..1c225362f88e 100644
> --- a/arch/x86/hyperv/hv_vtl.c
> +++ b/arch/x86/hyperv/hv_vtl.c
> @@ -16,6 +16,11 @@
>  extern struct boot_params boot_params;
>  static struct real_mode_header hv_vtl_real_mode_header;
> 
> +static bool __init hv_vtl_msi_ext_dest_id(void)
> +{
> +	return true;
> +}
> +
>  void __init hv_vtl_init_platform(void)
>  {
>  	pr_info("Linux runs in Hyper-V Virtual Trust Level\n");
> @@ -39,6 +44,8 @@ void __init hv_vtl_init_platform(void)
>  	x86_platform.legacy.warm_reset = 0;
>  	x86_platform.legacy.reserve_bios_regions = 0;
>  	x86_platform.legacy.devices.pnpbios = 0;
> +
> +	x86_init.hyper.msi_ext_dest_id = hv_vtl_msi_ext_dest_id;
>  }
> 
>  static inline u64 hv_vtl_system_desc_base(struct ldttss_desc *desc)
> --
> 2.25.1
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ