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] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 20 Mar 2023 18:50:05 +0000
From:   "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
To:     Borislav Petkov <bp@...en8.de>
CC:     "hpa@...or.com" <hpa@...or.com>, KY Srinivasan <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        "wei.liu@...nel.org" <wei.liu@...nel.org>,
        Dexuan Cui <decui@...rosoft.com>,
        "luto@...nel.org" <luto@...nel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "lpieralisi@...nel.org" <lpieralisi@...nel.org>,
        "robh@...nel.org" <robh@...nel.org>, "kw@...ux.com" <kw@...ux.com>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
        "arnd@...db.de" <arnd@...db.de>, "hch@....de" <hch@....de>,
        "m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
        "robin.murphy@....com" <robin.murphy@....com>,
        "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "brijesh.singh@....com" <brijesh.singh@....com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        Tianyu Lan <Tianyu.Lan@...rosoft.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "sathyanarayanan.kuppuswamy@...ux.intel.com" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "ak@...ux.intel.com" <ak@...ux.intel.com>,
        "isaku.yamahata@...el.com" <isaku.yamahata@...el.com>,
        "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        "jane.chu@...cle.com" <jane.chu@...cle.com>,
        "seanjc@...gle.com" <seanjc@...gle.com>,
        "tony.luck@...el.com" <tony.luck@...el.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>
Subject: RE: [PATCH v6 06/13] x86/hyperv: Change vTOM handling to use standard
 coco mechanisms

From: Borislav Petkov <bp@...en8.de> Sent: Monday, March 20, 2023 11:17 AM
> 
> On Mon, Mar 20, 2023 at 01:30:54PM +0000, Michael Kelley (LINUX) wrote:
> > In a vTOM VM, CPUID leaf 0x8000001f is filtered so it does *not* return
> > Bit 1 (SEV) as set.  Consequently, sme_enable() does not read MSR_AMD64_SEV
> > and does not populate sev_status.
> 
> So how much of the hardware side of vTOM are you actually using besides
> the actual encryption?

vTOM mode in Linux is just turning on/off the vTOM bit in the PTE
to create unencrypted or encrypted mappings, with encrypted being the
default.  There's no other hardware dependency except CPUID leaf
0x8000001f reporting that SEV is not enabled, and the GHCB protocol
(if you want to call that "hardware") as mentioned below.

> 
> Virtual TOM MSR (C001_0135)? Anything else?
> 
> AFAICT, you're passing the vTOM value from CPUID from the hypervisor so
> I'm guessing that happens underneath in the hypervisor?

Correct.  Linux in vTOM mode is not reading MSR 0xC0010135.  The
PTE bit position of the vTOM bit is coming from Hyper-V (or the paravisor)
via a synthetic MSR.  Presumably Hyper-V or the paravisor is reading
the vTOM MSR, but I haven't reviewed that code.

> 
> I'd like to make sure there are no more "surprises" down the road...
> 

The only other vTOM changes are for software protocols for communication
between the guest and Hyper-V (or the paravisor).  Some hypercalls and
synthetic MSR accesses need to bypass the paravisor and are handled
with the GHCB protocol.  The Hyper-V and VMbus specific code in Linux
handles those idiosyncrasies.  That code went into the 5.15 kernel and
isn't modified by this patch set.

The vTOM case is down to the bare minimum in the use of the hardware
functionality, so it's unlikely anything else would turn up as being different.

Michael

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ