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:   Tue, 28 Mar 2023 17:12:58 -0500
From:   Michael Roth <michael.roth@....com>
To:     Dave Hansen <dave.hansen@...el.com>
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>, <bp@...en8.de>,
        <vbabka@...e.cz>, <kirill@...temov.name>, <ak@...ux.intel.com>,
        <tony.luck@...el.com>, <marcorr@...gle.com>,
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        <alpergun@...gle.com>, <dgilbert@...hat.com>, <jarkko@...nel.org>,
        <ashish.kalra@....com>, <nikunj.dadhania@....com>,
        Brijesh Singh <brijesh.singh@....com>
Subject: Re: [PATCH RFC v8 15/56] x86/sev: Invalidate pages from the direct
 map when adding them to the RMP table

On Wed, Mar 01, 2023 at 08:15:46AM -0800, Dave Hansen wrote:
> On 2/20/23 10:38, Michael Roth wrote:
> > From: Brijesh Singh <brijesh.singh@....com>
> > 
> > The integrity guarantee of SEV-SNP is enforced through the RMP table.
> > The RMP is used with standard x86 and IOMMU page tables to enforce
> > memory restrictions and page access rights. The RMP check is enforced as
> > soon as SEV-SNP is enabled globally in the system. When hardware
> > encounters an RMP-check failure, it raises a page-fault exception.
> > 
> > The rmp_make_private() and rmp_make_shared() helpers are used to add
> > or remove the pages from the RMP table. Improve the rmp_make_private()
> > to invalidate state so that pages cannot be used in the direct-map after
> > they are added the RMP table, and restored to their default valid
> > permission after the pages are removed from the RMP table.
> 
> This is a purely "what" changelog.  It doesn't explain the "why" at all.
> 
> Could you please elaborate on why this unmapping operation is necessary?
> 

Here's my attempt at an updated changelog that explains why this handling
is needed:

  With SEV-SNP, if a host attempts to write to a page that is owned by a
  guest (according to the SEV-SNP RMP table), the host will get a #PF with
  a bit set to indicate that an RMP violation occurred. This shouldn't
  normally occur, since guest-owned pages are encrypted, so any attempt to
  write to them would just result in garbage being written.
  
  However, if a host writes to a page via a 2M/1G mapping in the host
  process' page table, the above #PF condition will trigger if *any*
  4K sub-pages mapped by that PTE are guest-owned, even if the write
  is only to 4K pages that are owned by the host.
  
  This becomes an issue with the kernel directmap, which provides a
  static/linear mapping of all kernel memory and defaults to using 2M
  pages. In cases where a page from one of these 2M ranges gets assigned
  to a guest, the kernel can inadvertantly trigger #PF by writing to some
  other page in that 2M region via the virtual addresses provided by the
  directmap.
  
  Address this by removing directmap mappings for these PFNs before
  marking them as guest-owned in the RMP table, which will result in the
  original 2M mapping being split and ensure that guest-owned pages can't
  be written to via the kernel directmap.

-Mike

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ