linux-kernel - Re: [PATCH v3 15/37] x86/mm: Check Shadow Stack page fault errors

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: <2766aedef0780f03b81ea7dfea42dffb328e21f1.camel@intel.com>
Date:   Tue, 15 Nov 2022 23:13:34 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "peterz@...radead.org" <peterz@...radead.org>
CC:     "bsingharora@...il.com" <bsingharora@...il.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "Syromiatnikov, Eugene" <esyr@...hat.com>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "Yu, Yu-cheng" <yu-cheng.yu@...el.com>,
        "Eranian, Stephane" <eranian@...gle.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...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>,
        "Yang, Weijiang" <weijiang.yang@...el.com>,
        "Lutomirski, Andy" <luto@...nel.org>,
        "jamorris@...ux.microsoft.com" <jamorris@...ux.microsoft.com>,
        "arnd@...db.de" <arnd@...db.de>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "pavel@....cz" <pavel@....cz>,
        "mike.kravetz@...cle.com" <mike.kravetz@...cle.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "rppt@...nel.org" <rppt@...nel.org>,
        "john.allen@....com" <john.allen@....com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.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 v3 15/37] x86/mm: Check Shadow Stack page fault errors

On Tue, 2022-11-15 at 22:07 +0100, Peter Zijlstra wrote:
> On Tue, Nov 15, 2022 at 08:03:06PM +0000, Edgecombe, Rick P wrote:
> 
> > That's right. I think the assumption that needs to be broken in the
> > readers head is that you can satisfy a read fault with read-only
> > PTE.
> > This is kind of baked in all over the place with the zero-pfn, COW,
> > etc. Maybe I should try to start with that.
> 
> Maybe something like:
> 
> CoW -- pte_wrprotect() -- changes a SS page 'Write=0,Dirty=1' to
> 'Write=0,Dirty=0,CoW=1' which is a 'regular' RO page. A SS read from
> RET
> will #PF because it expects a SS page. Make sure to break the CoW so
> it
> can be restored to an SS page, as such force the write path and
> tickle
> pte_mkwrite().

Hmm, TBH I'm not sure it's more clear. I tried to take this and fill it
out more. Does it sound better?


When a page becomes COW it changes from a shadow stack permissioned
page (Write=0,Dirty=1) to (Write=0,Dirty=0,CoW=1), which is simply
read-only to the CPU. When shadow stack is enabled, a RET would
normally pop the shadow stack by reading it with a "shadow stack read"
access. However, in the COW case the shadow stack memory does not have
shadow stack permissions, it is read-only. So it will generate a fault.

For conventionally writable pages, a read can be serviced with a read
only PTE, and COW would not have to happen. But for shadow stack, there
isn't the concept of read-only shadow stack memory. If it is shadow
stack permissioned, it can be modified via CALL and RET instructions.
So COW needs to happen before any memory can be mapped with shadow
stack permissions.

Shadow stack accesses (read or write) need to be serviced with shadow
stack permissioned memory, so in the case of a shadow stack read
access, treat it as a WRITE fault so both COW will happen and the write
fault path will tickle maybe_mkwrite() and map the memory shadow stack.