RE: [EXTERNAL] RE: [PATCH v2 2/2] x86/hyperv: VTL support for Hyper-V

[KY Srinivasan <kys@microsoft.com>]

> -----Original Message-----
> From: Vitaly Kuznetsov <vkuznets@redhat.com>
> Sent: Tuesday, March 21, 2023 7:54 AM
> To: KY Srinivasan <kys@microsoft.com>; Saurabh Singh Sengar
> <ssengar@linux.microsoft.com>
> Cc: tglx@linutronix.de; mingo@redhat.com; bp@alien8.de;
> dave.hansen@linux.intel.com; x86@kernel.org; hpa@zytor.com; Haiyang Zhang
> <haiyangz@microsoft.com>; wei.liu@kernel.org; Dexuan Cui
> <decui@microsoft.com>; arnd@arndb.de; Tianyu Lan
> <Tianyu.Lan@microsoft.com>; Michael Kelley (LINUX)
> <mikelley@microsoft.com>; linux-kernel@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-arch@vger.kernel.org
> Subject: [EXTERNAL] RE: [PATCH v2 2/2] x86/hyperv: VTL support for Hyper-V
> 
> KY Srinivasan <kys@microsoft.com> writes:
> 
> >> -----Original Message-----
> >> From: Saurabh Singh Sengar <ssengar@linux.microsoft.com>
> >> Sent: Monday, March 13, 2023 10:02 AM
> >> To: Vitaly Kuznetsov <vkuznets@redhat.com>
> >> Cc: tglx@linutronix.de; mingo@redhat.com; bp@alien8.de;
> >> dave.hansen@linux.intel.com; x86@kernel.org; hpa@zytor.com; KY
> >> Srinivasan <kys@microsoft.com>; Haiyang Zhang
> >> <haiyangz@microsoft.com>; wei.liu@kernel.org; Dexuan Cui
> >> <decui@microsoft.com>; arnd@arndb.de; Tianyu Lan
> >> <Tianyu.Lan@microsoft.com>; Michael Kelley (LINUX)
> >> <mikelley@microsoft.com>; linux-kernel@vger.kernel.org; linux-
> >> hyperv@vger.kernel.org; linux-arch@vger.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@linux.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