linux-kernel - RE: [RFC PATCH v1 2/6] x86/sev: Add support for NestedVirtSnpMsr

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: <BYAPR21MB1688EC3B7167A0C2E821D435D7D39@BYAPR21MB1688.namprd21.prod.outlook.com>
Date:   Mon, 30 Jan 2023 15:39:19 +0000
From:   "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
To:     Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Wei Liu <wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>,
        Tianyu Lan <Tianyu.Lan@...rosoft.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        Brijesh Singh <brijesh.singh@....com>,
        Michael Roth <michael.roth@....com>,
        Ashish Kalra <ashish.kalra@....com>,
        Tom Lendacky <thomas.lendacky@....com>
Subject: RE: [RFC PATCH v1 2/6] x86/sev: Add support for NestedVirtSnpMsr

From: Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com> Sent: Monday, January 30, 2023 7:26 AM
> 
> On Sat, Jan 28, 2023 at 07:48:27PM +0000, Michael Kelley (LINUX) wrote:
> > From: Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com> Sent: Monday, January
> 23, 2023 8:51 AM
> > >
> > > The rmpupdate and psmash instructions, which are used in AMD's SEV-SNP
> > > to update the RMP (Reverse Map) table, can't be trapped. For nested
> > > scenarios, AMD defined MSR versions of these instructions which can be
> >
> > s/can be/must be/  ??
> >
> 
> yes indeed
> 
> > > emulated by the top-level hypervisor. One instance where these MSRs are
> >
> > And by "top-level", I think you are referring the hypervisor running at L1, right?
> > Using the L0/L1/L2 terminology would probably help make the description
> > more precise.
> 
> These instructions are called by the L1 hypervisor and are emulated by the L0
> hypervisor which controls the actual rmp table. I'll rephrase the commit
> message to make that clearer.
> 

[snip]

> > > +
> > > +static u64 virt_psmash(u64 paddr)
> > > +{
> > > +	int ret;
> > > +
> > > +	asm volatile(
> > > +		"wrmsr\n\t"
> > > +		: "=a"(ret)
> > > +		: "a"(paddr), "c"(MSR_AMD64_VIRT_PSMASH)
> > > +		: "memory", "cc"
> > > +	);
> > > +	return ret;
> > > +}
> >
> > From checking the AMD spec, I can see that the above use
> > of wrmsr is non-conventional.  Could you capture the basics
> > of the usage paradigm in a comment?  I.e., the expected
> > inputs and outputs, and the core assumption that the
> > MSR isn't implemented in hardware, but must trap
> > to the hypervisor.
> 
> ok, how does this sound:
> 
> /*
>  * This version of rmpupdate is not implemented in hardware but always
>  * traps to L0 hypervisor. It doesn't follow usual wrmsr conventions.
>  * Inputs:
>  *   rax: 4KB aligned GPA
>  *   rdx: bytes 7:0 of new rmp entry
>  *   r8:  bytes 15:8 of new rmp entry
>  * Outputs:
>  *   rax: rmpupdate return code
>  */
> 
> and similar for psmash.
> 

Yes, that works for me.

Michael