linux-kernel - RE: [PATCH v2 4/8] x86/sev: Enable PVALIDATE for PFNs without a valid virtual address

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: <SN6PR02MB4157A935C8B8F9DBB30F9512D4BCA@SN6PR02MB4157.namprd02.prod.outlook.com>
Date:   Tue, 28 Nov 2023 18:08:08 +0000
From:   Michael Kelley <mhklinux@...look.com>
To:     "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "ardb@...nel.org" <ardb@...nel.org>,
        "hch@...radead.org" <hch@...radead.org>,
        "Lutomirski, Andy" <luto@...nel.org>,
        "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "haiyangz@...rosoft.com" <haiyangz@...rosoft.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "seanjc@...gle.com" <seanjc@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kys@...rosoft.com" <kys@...rosoft.com>,
        "Cui, Dexuan" <decui@...rosoft.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "urezki@...il.com" <urezki@...il.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "wei.liu@...nel.org" <wei.liu@...nel.org>,
        "bp@...en8.de" <bp@...en8.de>, "Rodel, Jorg" <jroedel@...e.de>,
        "sathyanarayanan.kuppuswamy@...ux.intel.com" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "lstoakes@...il.com" <lstoakes@...il.com>,
        "x86@...nel.org" <x86@...nel.org>
Subject: RE: [PATCH v2 4/8] x86/sev: Enable PVALIDATE for PFNs without a valid
 virtual address

From: Edgecombe, Rick P <rick.p.edgecombe@...el.com> Sent: Monday, November 27, 2023 1:39 PM
> 
> On Tue, 2023-11-21 at 13:20 -0800, mhkelley58@...il.com wrote:
> > +static int pvalidate_pfn(unsigned long vaddr, unsigned int size,
> > +                        unsigned long pfn, bool validate, int *rc2)
> > +{
> > +       int rc;
> > +       struct page *page = pfn_to_page(pfn);
> > +
> > +       *rc2 = vmap_pages_range(vaddr, vaddr + PAGE_SIZE,
> > +                       PAGE_KERNEL, &page, PAGE_SHIFT);
> 
> Can't this fail and then the pvalidate below would encounter trouble?

Yes.  My intent was to just let the PVALIDATE fail because of operating
on a vaddr that's invalid.  But that would be worth a comment.

> 
> Sort of separately, if those vmalloc objections can't be worked
> through, did you consider doing something like text_poke() does (create
> the temporary mapping in a temporary MM) for pvalidate purposes? I
> don't know enough about what kind of special exceptions might popup
> during that operation though, might be playing with fire...

Interesting idea.  But from a quick glance at the text_poke() code,
such an approach seems somewhat complex, and I suspect it will have 
the same perf issues (or worse) as creating a new vmalloc area for
each PVALIDATE invocation.

At this point, the complexity of creating the temp mapping for
PVALIDATE is seeming excessive.  On balance it seems simpler to
revert to an approach where the use of set_memory_np() and
set_memory_p() is conditional.  It would be necessary when #VC
and #VE exceptions are directed to a paravisor.  (This assumes the
paravisor interface in the hypervisor callbacks does the natural thing
of working with physical addresses, so there's no need for a temp
mapping.)

Optionally, the set_memory_np()/set_memory_p() approach could
be used in other cases where the hypervisor callbacks work with
physical addresses.  But it can't be used with cases where the hypervisor
callbacks need valid virtual addresses.

So on net, set_memory_np()/set_memory_p() would be used in
the Hyper-V cases of TDX and SEV-SNP with a paravisor.   It could
optionally be used with TDX with no paravisor, but my sense is
that Kirill wants to keep TDX "as is" and let the exception handlers
do the load_unaligned_zeropad() fixup.

It could not be used with SEV-SNP with no paravisor.   Additional fixes
may be needed on the SEV-SNP side to properly fixup
load_unaligned_zeropad() accesses to a page that's in transition
between encrypted and decrypted.

I'll work on a patch series that takes the conditional approach.

Michael

> 
> > +       rc = pvalidate(vaddr, size, validate);
> > +       vunmap_range(vaddr, vaddr + PAGE_SIZE);
> > +
> > +       return rc;
> > +}