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

[KY Srinivasan]

> -----Original Message-----
> From: Saurabh Singh Sengar <ssengar@xxxxxxxxxxxxxxxxxxx>
> Sent: Monday, March 13, 2023 10:02 AM
> To: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>
> Cc: tglx@xxxxxxxxxxxxx; mingo@xxxxxxxxxx; bp@xxxxxxxxx;
> dave.hansen@xxxxxxxxxxxxxxx; x86@xxxxxxxxxx; hpa@xxxxxxxxx; KY Srinivasan
> <kys@xxxxxxxxxxxxx>; Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>;
> wei.liu@xxxxxxxxxx; Dexuan Cui <decui@xxxxxxxxxxxxx>; arnd@xxxxxxxx;
> Tianyu Lan <Tianyu.Lan@xxxxxxxxxxxxx>; Michael Kelley (LINUX)
> <mikelley@xxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; linux-
> hyperv@xxxxxxxxxxxxxxx; linux-arch@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx> writes:
> >
> > > Virtual Trust Levels (VTL) helps enable Hyper-V Virtual Secure Mode
> > > (VSM) feature. VSM is a set of hypervisor capabilities and
> > > enlightenments offered to host and guest partitions which enable the
> > > creation and management of new security boundaries within operating
> system software.
> > > VSM achieves and maintains isolation through VTLs.
> > >
> > > Add early initialization for Virtual Trust Levels (VTL). This
> > > includes initializing the x86 platform for VTL and enabling boot
> > > support for secondary CPUs to start in targeted VTL context. For
> > > now, only enable the code for targeted VTL level as 2.
> > >
> > > When starting an AP at a VTL other than VTL 0, the AP must start
> > > directly in 64-bit mode, bypassing the usual 16-bit -> 32-bit ->
> > > 64-bit mode transition sequence that occurs after waking up an AP
> > > with SIPI whose vector points to the 16-bit AP startup trampoline code.
> > >
> > > This commit also moves hv_get_nmi_reason function to header file, so
> > > that it can be reused by VTL.
> > >
> > > Signed-off-by: Saurabh Sengar <ssengar@xxxxxxxxxxxxxxxxxxx>
> > > ---
> > >  arch/x86/Kconfig                   |  24 +++
> > >  arch/x86/hyperv/Makefile           |   1 +
> > >  arch/x86/hyperv/hv_vtl.c           | 227 +++++++++++++++++++++++++++++
> > >  arch/x86/include/asm/hyperv-tlfs.h |  75 ++++++++++
> > >  arch/x86/include/asm/mshyperv.h    |  14 ++
> > >  arch/x86/kernel/cpu/mshyperv.c     |   6 +-
> > >  include/asm-generic/hyperv-tlfs.h  |   4 +
> >
> > This patch is quite big, I'd suggest you split it up. E.g. TLFS
> > definitions can easily be a separate patch. Moving hv_get_nmi_reason()
> > can be a separate patch. Secondary CPU bringup can be a separate
> > patch. The new config option to enable the feature (assuming it is
> > really needed) can be the last separate patch.
> 
> Ok will do in next version.
> 
> >
> > >  7 files changed, 346 insertions(+), 5 deletions(-)  create mode
> > > 100644 arch/x86/hyperv/hv_vtl.c
> > >
> > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index
> > > 453f462f6c9c..b9e52ac9c9f9 100644
> > > --- a/arch/x86/Kconfig
> > > +++ b/arch/x86/Kconfig
> > > @@ -782,6 +782,30 @@ menuconfig HYPERVISOR_GUEST
> > >
> > >  if HYPERVISOR_GUEST
> > >
> > > +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.

K. Y