netdev - RE: [PATCH v6 06/13] x86/hyperv: Change vTOM handling to use standard coco mechanisms

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]

Message-ID: <BYAPR21MB1688DF161ACE142DEA721DA1D7809@BYAPR21MB1688.namprd21.prod.outlook.com>
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