linux-kernel - Re: [PATCH hyperv-next v5 06/11] arm64, x86: hyperv: Report the VTL the system boots in

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]

Message-ID: <Z88Y-R7BnXa4Xi3I@liuwe-devbox-ubuntu-v2.lamzopl0uupeniq2etz1fddiyg.xx.internal.cloudapp.net>
Date: Mon, 10 Mar 2025 16:53:13 +0000
From: Wei Liu <wei.liu@...nel.org>
To: Roman Kisel <romank@...ux.microsoft.com>
Cc: Wei Liu <wei.liu@...nel.org>, arnd@...db.de, bhelgaas@...gle.com,
	bp@...en8.de, catalin.marinas@....com, conor+dt@...nel.org,
	dave.hansen@...ux.intel.com, decui@...rosoft.com,
	haiyangz@...rosoft.com, hpa@...or.com, joey.gouly@....com,
	krzk+dt@...nel.org, kw@...ux.com, kys@...rosoft.com,
	lenb@...nel.org, lpieralisi@...nel.org,
	manivannan.sadhasivam@...aro.org, mark.rutland@....com,
	maz@...nel.org, mingo@...hat.com, oliver.upton@...ux.dev,
	rafael@...nel.org, robh@...nel.org, ssengar@...ux.microsoft.com,
	sudeep.holla@....com, suzuki.poulose@....com, tglx@...utronix.de,
	will@...nel.org, yuzenghui@...wei.com, devicetree@...r.kernel.org,
	kvmarm@...ts.linux.dev, linux-acpi@...r.kernel.org,
	linux-arch@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org, x86@...nel.org, apais@...rosoft.com,
	benhill@...rosoft.com, bperkins@...rosoft.com,
	sunilmut@...rosoft.com
Subject: Re: [PATCH hyperv-next v5 06/11] arm64, x86: hyperv: Report the VTL
 the system boots in

On Mon, Mar 10, 2025 at 09:42:15AM -0700, Roman Kisel wrote:
> 
> 
> On 3/9/2025 5:31 PM, Wei Liu wrote:
> > On Fri, Mar 07, 2025 at 02:02:58PM -0800, Roman Kisel wrote:
> > > The hyperv guest code might run in various Virtual Trust Levels.
> > > 
> > > Report the level when the kernel boots in the non-default (0)
> > > one.
> > > 
> > > Signed-off-by: Roman Kisel <romank@...ux.microsoft.com>
> > > ---
> > >   arch/arm64/hyperv/mshyperv.c | 2 ++
> > >   arch/x86/hyperv/hv_vtl.c     | 2 +-
> > >   2 files changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
> > > index a7db03f5413d..3bc16dbee758 100644
> > > --- a/arch/arm64/hyperv/mshyperv.c
> > > +++ b/arch/arm64/hyperv/mshyperv.c
> > > @@ -108,6 +108,8 @@ static int __init hyperv_init(void)
> > >   	if (ms_hyperv.priv_high & HV_ACCESS_PARTITION_ID)
> > >   		hv_get_partition_id();
> > >   	ms_hyperv.vtl = get_vtl();
> > > +	if (ms_hyperv.vtl > 0) /* non default VTL */
> > 
> > "non-default".
> > 
> 
> Thanks, will fix that!
> 
> > > +		pr_info("Linux runs in Hyper-V Virtual Trust Level %d\n", ms_hyperv.vtl);
> > >   	ms_hyperv_late_init();
> > > diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
> > > index 4e1b1e3b5658..c21bee7e8ff3 100644
> > > --- a/arch/x86/hyperv/hv_vtl.c
> > > +++ b/arch/x86/hyperv/hv_vtl.c
> > > @@ -24,7 +24,7 @@ static bool __init hv_vtl_msi_ext_dest_id(void)
> > >   void __init hv_vtl_init_platform(void)
> > >   {
> > > -	pr_info("Linux runs in Hyper-V Virtual Trust Level\n");
> > > +	pr_info("Linux runs in Hyper-V Virtual Trust Level %d\n", ms_hyperv.vtl);
> > 
> > Where isn't there a check for ms_hyperv.vtl > 0 here?
> > 
> 
> On x86, there is
> 
> #ifdef CONFIG_HYPERV_VTL_MODE
> void __init hv_vtl_init_platform(void);
> int __init hv_vtl_early_init(void);
> #else
> static inline void __init hv_vtl_init_platform(void) {}
> static inline int __init hv_vtl_early_init(void) { return 0; }
> #endif
> 
> > Please be consistent across different architectures.
> > 
> 
> In the earlier versions of the patch series, I had that piece
> from the above mirrored in the arm64, and there was advice on
> removing the function as it contained just one statement.
> I'll revisit the approach, thanks for your help!

As long as the output is consistent across different architectures, I'm
good.

Wei.

> 
> > >   	x86_platform.realmode_reserve = x86_init_noop;
> > >   	x86_platform.realmode_init = x86_init_noop;
> > > -- 
> > > 2.43.0
> > > 
> > > 
> 
> -- 
> Thank you,
> Roman
>