linux-kernel - Re: [PATCH v6 20/41] x86/mm: Teach pte

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: <5d0929e10d5333d611a8509c8e04cf8f55fd14b8.camel@intel.com>
Date:   Mon, 20 Feb 2023 22:52:23 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "keescook@...omium.org" <keescook@...omium.org>
CC:     "david@...hat.com" <david@...hat.com>,
        "bsingharora@...il.com" <bsingharora@...il.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "Syromiatnikov, Eugene" <esyr@...hat.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "Eranian, Stephane" <eranian@...gle.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "fweimer@...hat.com" <fweimer@...hat.com>,
        "nadav.amit@...il.com" <nadav.amit@...il.com>,
        "jannh@...gle.com" <jannh@...gle.com>,
        "dethoma@...rosoft.com" <dethoma@...rosoft.com>,
        "kcc@...gle.com" <kcc@...gle.com>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        "bp@...en8.de" <bp@...en8.de>, "oleg@...hat.com" <oleg@...hat.com>,
        "hjl.tools@...il.com" <hjl.tools@...il.com>,
        "pavel@....cz" <pavel@....cz>,
        "Lutomirski, Andy" <luto@...nel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "Schimpe, Christina" <christina.schimpe@...el.com>,
        "mike.kravetz@...cle.com" <mike.kravetz@...cle.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "Yang, Weijiang" <weijiang.yang@...el.com>,
        "debug@...osinc.com" <debug@...osinc.com>,
        "jamorris@...ux.microsoft.com" <jamorris@...ux.microsoft.com>,
        "john.allen@....com" <john.allen@....com>,
        "rppt@...nel.org" <rppt@...nel.org>,
        "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "corbet@....net" <corbet@....net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        "gorcunov@...il.com" <gorcunov@...il.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [PATCH v6 20/41] x86/mm: Teach pte_mkwrite() about stack memory

On Sun, 2023-02-19 at 12:41 -0800, Kees Cook wrote:
> On Sat, Feb 18, 2023 at 01:14:12PM -0800, Rick Edgecombe wrote:
> > If a VMA has the VM_SHADOW_STACK flag, it is shadow stack memory.
> > So
> > when it is made writable with pte_mkwrite(), it should create
> > shadow
> > stack memory, not conventionally writable memory. Now that
> > pte_mkwrite()
> > takes a VMA, and places where shadow stack memory might be created
> > pass
> > one, pte_mkwrite() can know when it should do this.
> > 
> > So make pte_mkwrite() create shadow stack memory when the VMA has
> > the
> > VM_SHADOW_STACK flag. Do the same thing for pmd_mkwrite().
> > 
> > This requires referencing VM_SHADOW_STACK in these functions, which
> > are
> > currently defined in pgtable.h, however mm.h (where VM_SHADOW_STACK
> > is
> > located) can't be pulled in without causing problems for files that
> > reference pgtable.h. So also move pte/pmd_mkwrite() into pgtable.c,
> > where
> > they can safely reference VM_SHADOW_STACK.
> > 
> > Tested-by: Pengfei Xu <pengfei.xu@...el.com>
> > Signed-off-by: Rick Edgecombe <rick.p.edgecombe@...el.com>
> 
> Is there any realistic performance impact from making these not
> inline
> now?

Hmm, I can't say definitively. I would think in write protecting
operations, the big cost would not be the PTE setters. For mapping
things read-only from the beginning (user text, etc), I'm not sure. I
guess it gives the compiler less flexibility, but also gives it the
option to have one copy and so less text size overall for the kernel.

Are there any specific microbenchmarks we could run?