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

[Vitaly Kuznetsov <vkuznets@redhat.com>]

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.

-- 
Vitaly