lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ