linux-kernel - Re: [PATCH v10 07/50] x86/sev: Add RMP entry lookup helpers

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, 18 Dec 2023 21:31:50 -0600
From: Michael Roth <michael.roth@....com>
To: Borislav Petkov <bp@...en8.de>
CC: <kvm@...r.kernel.org>, <linux-coco@...ts.linux.dev>, <linux-mm@...ck.org>,
	<linux-crypto@...r.kernel.org>, <x86@...nel.org>,
	<linux-kernel@...r.kernel.org>, <tglx@...utronix.de>, <mingo@...hat.com>,
	<jroedel@...e.de>, <thomas.lendacky@....com>, <hpa@...or.com>,
	<ardb@...nel.org>, <pbonzini@...hat.com>, <seanjc@...gle.com>,
	<vkuznets@...hat.com>, <jmattson@...gle.com>, <luto@...nel.org>,
	<dave.hansen@...ux.intel.com>, <slp@...hat.com>, <pgonda@...gle.com>,
	<peterz@...radead.org>, <srinivas.pandruvada@...ux.intel.com>,
	<rientjes@...gle.com>, <dovmurik@...ux.ibm.com>, <tobin@....com>,
	<vbabka@...e.cz>, <kirill@...temov.name>, <ak@...ux.intel.com>,
	<tony.luck@...el.com>, <sathyanarayanan.kuppuswamy@...ux.intel.com>,
	<alpergun@...gle.com>, <jarkko@...nel.org>, <ashish.kalra@....com>,
	<nikunj.dadhania@....com>, <pankaj.gupta@....com>, <liam.merwick@...cle.com>,
	<zhi.a.wang@...el.com>, Brijesh Singh <brijesh.singh@....com>
Subject: Re: [PATCH v10 07/50] x86/sev: Add RMP entry lookup helpers

On Tue, Nov 14, 2023 at 03:24:42PM +0100, Borislav Petkov wrote:
> On Mon, Oct 16, 2023 at 08:27:36AM -0500, Michael Roth wrote:
> > From: Brijesh Singh <brijesh.singh@....com>
> > 
> > The snp_lookup_page_in_rmptable() can be used by the host to read the RMP
> 
> $ git grep snp_lookup_page_in_rmptable
> $
> 
> Stale commit message. And not very telling. Please rewrite.
> 
> > entry for a given page. The RMP entry format is documented in AMD PPR, see
> > https://bugzilla.kernel.org/attachment.cgi?id=296015.
> 
> <--- Brijesh's SOB comes first here if he's the primary author.
> 
> > Co-developed-by: Ashish Kalra <ashish.kalra@....com>
> > Signed-off-by: Ashish Kalra <ashish.kalra@....com>
> > Signed-off-by: Brijesh Singh <brijesh.singh@....com>
> > [mdr: separate 'assigned' indicator from return code]
> > Signed-off-by: Michael Roth <michael.roth@....com>
> > ---
> >  arch/x86/include/asm/sev-common.h |  4 +++
> >  arch/x86/include/asm/sev-host.h   | 22 +++++++++++++
> >  arch/x86/virt/svm/sev.c           | 53 +++++++++++++++++++++++++++++++
> >  3 files changed, 79 insertions(+)
> >  create mode 100644 arch/x86/include/asm/sev-host.h
> > 
> > diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev-common.h
> > index b463fcbd4b90..1e6fb93d8ab0 100644
> > --- a/arch/x86/include/asm/sev-common.h
> > +++ b/arch/x86/include/asm/sev-common.h
> > @@ -173,4 +173,8 @@ struct snp_psc_desc {
> >  #define GHCB_ERR_INVALID_INPUT		5
> >  #define GHCB_ERR_INVALID_EVENT		6
> >  
> > +/* RMP page size */
> > +#define RMP_PG_SIZE_4K			0
> 
> RMP_PG_LEVEL_4K just like the generic ones.

I've moved this to sev.h, but it RMP_PG_SIZE_4K is already defined there
and used by a bunch of guest code so it's a bit out-of-place to update
those as part of this patchset. I can send a follow-up series to clean up
some of the naming and get rid of sev-common.h

> 
> > +#define RMP_TO_X86_PG_LEVEL(level)	(((level) == RMP_PG_SIZE_4K) ? PG_LEVEL_4K : PG_LEVEL_2M)
> 
> What else is there besides X86 PG level?
> 
> IOW, RMP_TO_PG_LEVEL simply.

Make sense.

> 
> > +
> >  #endif
> > diff --git a/arch/x86/include/asm/sev-host.h b/arch/x86/include/asm/sev-host.h
> 
> Nah, we don't need a third sev header:
> 
> arch/x86/include/asm/sev-common.h
> arch/x86/include/asm/sev.h
> arch/x86/include/asm/sev-host.h
> 
> Put it in sev.h pls.

Done.

> 
> sev-common.h should be merged into sev.h too unless there's a compelling
> reason not to which I don't see atm.

Doesn't seem like it would be an issue, maybe some fallout from any
files that previously only included sev-common.h and now need to pull in
guest struct definitions as well, but those definitions don't have a lot
of external dependencies so don't anticipate any header include
hellishness. I'll send that as a separate follow-up, along with some of
the renames you suggested above since they'll touch guest code and
create unecessary churn for SNP host support.

Thanks,

Mike

> > -- 
> 
> Thx.
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette