[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <DS7PR21MB312782CFB728409A243EA8DFA0819@DS7PR21MB3127.namprd21.prod.outlook.com>
Date: Tue, 21 Mar 2023 18:01:25 +0000
From: KY Srinivasan <kys@...rosoft.com>
To: Vitaly Kuznetsov <vkuznets@...hat.com>,
Saurabh Singh Sengar <ssengar@...ux.microsoft.com>
CC: "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>,
Haiyang Zhang <haiyangz@...rosoft.com>,
"wei.liu@...nel.org" <wei.liu@...nel.org>,
Dexuan Cui <decui@...rosoft.com>,
"arnd@...db.de" <arnd@...db.de>,
Tianyu Lan <Tianyu.Lan@...rosoft.com>,
"Michael Kelley (LINUX)" <mikelley@...rosoft.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>
Subject: RE: [EXTERNAL] RE: [PATCH v2 2/2] x86/hyperv: VTL support for Hyper-V
> -----Original Message-----
> From: Vitaly Kuznetsov <vkuznets@...hat.com>
> Sent: Tuesday, March 21, 2023 7:54 AM
> To: KY Srinivasan <kys@...rosoft.com>; Saurabh Singh Sengar
> <ssengar@...ux.microsoft.com>
> Cc: tglx@...utronix.de; mingo@...hat.com; bp@...en8.de;
> dave.hansen@...ux.intel.com; x86@...nel.org; hpa@...or.com; Haiyang Zhang
> <haiyangz@...rosoft.com>; wei.liu@...nel.org; Dexuan Cui
> <decui@...rosoft.com>; arnd@...db.de; Tianyu Lan
> <Tianyu.Lan@...rosoft.com>; Michael Kelley (LINUX)
> <mikelley@...rosoft.com>; linux-kernel@...r.kernel.org; linux-
> hyperv@...r.kernel.org; linux-arch@...r.kernel.org
> Subject: [EXTERNAL] RE: [PATCH v2 2/2] x86/hyperv: VTL support for Hyper-V
>
> KY Srinivasan <kys@...rosoft.com> writes:
>
> >> -----Original Message-----
> >> From: Saurabh Singh Sengar <ssengar@...ux.microsoft.com>
> >> Sent: Monday, March 13, 2023 10:02 AM
> >> To: Vitaly Kuznetsov <vkuznets@...hat.com>
> >> Cc: tglx@...utronix.de; mingo@...hat.com; bp@...en8.de;
> >> dave.hansen@...ux.intel.com; x86@...nel.org; hpa@...or.com; KY
> >> Srinivasan <kys@...rosoft.com>; Haiyang Zhang
> >> <haiyangz@...rosoft.com>; wei.liu@...nel.org; Dexuan Cui
> >> <decui@...rosoft.com>; arnd@...db.de; Tianyu Lan
> >> <Tianyu.Lan@...rosoft.com>; Michael Kelley (LINUX)
> >> <mikelley@...rosoft.com>; linux-kernel@...r.kernel.org; linux-
> >> hyperv@...r.kernel.org; linux-arch@...r.kernel.org
> >> Subject: Re: [PATCH v2 2/2] x86/hyperv: VTL support for Hyper-V
> >>
> >> On Mon, Mar 13, 2023 at 03:45:02PM +0100, Vitaly Kuznetsov wrote:
> >> > Saurabh Sengar <ssengar@...ux.microsoft.com> writes:
> >> >
>
> ...
>
> >> > > +config HYPERV_VTL
> >> > > + bool "Enable VTL"
> >> > > + depends on X86_64 && HYPERV
> >> > > + default n
> >> > > + help
> >> > > + Virtual Secure Mode (VSM) is a set of hypervisor capabilities and
> >> > > + enlightenments offered to host and guest partitions which enables
> >> > > + the creation and management of new security boundaries within
> >> > > + operating system software.
> >> > > +
> >> > > + VSM achieves and maintains isolation through Virtual Trust Levels
> >> > > + (VTLs). Virtual Trust Levels are hierarchical, with higher levels
> >> > > + being more privileged than lower levels. VTL0 is the least privileged
> >> > > + level, and currently only other level supported is VTL2.
> >> > > +
> >> > > + Select this option to build a Linux kernel to run at a VTL other than
> >> > > + the normal VTL 0, which currently is only VTL 2. This option
> >> > > + initializes the x86 platform for VTL 2, and adds the ability to boot
> >> > > + secondary CPUs directly into 64-bit context as required for VTLs other
> >> > > + than 0. A kernel built with this option must run at VTL 2, and will
> >> > > + not run as a normal guest.
> >> >
> >> > This is quite unfortunate, is there a way to detect which VTL the
> >> > guest is running at and change the behavior dynamically?
> >>
> >> Only way to detect VTL is via hypercall. However hypercalls are not
> >> available this early in boot sequence.
> >
> > Vitaly, we looked at all the options and we felt this detection did
> > not have to be dynamic and could well be a compile time option. Think
> > of this kernel as a Linux based Trusted Execution Environment that only runs
> in the Virtual Trust Level surfaced by Hyper-V with limited hardware exposed to
> this environment.
>
> I understand kernels placed in other VTLs serve very specific purposes so likely
> there is no need to run standard kernels shipped with various Linux
> distributions there in production. It may still come handy to have such option if
> only for debugging/testing purposes. The way it is designed now,
> CONFIG_HYPERV_VTL will always end up disabled in anything but your custom
> builds for VTLs (as such builds won't boot anywhere else).
>
> Doing a hypercall in early boot may not be trivial now but should be possible. It
> would be even better if current VTL would be exposed somewhere in CPUID by
> the hypervisor.
>
> Just a suggestion.
Thanks Vitaly and I hear your concern. The VTL environment is so different and so constrained,
that paying the cost of a run-time detection we felt did not buy us anything. We did discuss the CPUID option as the most
efficient form of run-time detection and the hypervisor team had some issues with this option and so we went with the
compile time option.
Regards,
K. Y
Powered by blists - more mailing lists