Message-ID: <DS7PR21MB3127E3FBE1ABB368C6CBC097A0B99@DS7PR21MB3127.namprd21.prod.outlook.com>
Date:   Mon, 13 Mar 2023 18:16:27 +0000
From:   KY Srinivasan <kys@...rosoft.com>
To:     Saurabh Singh Sengar <ssengar@...ux.microsoft.com>,
        Vitaly Kuznetsov <vkuznets@...hat.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: [PATCH v2 2/2] x86/hyperv: VTL support for Hyper-V




> -----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:
> >
> > > 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@...ux.microsoft.com>
> > > ---
> > >  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

Powered by blists - more mailing lists