| 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
| ||
|
Message-ID: <f34a1122386197a39dffdc176fcd2c1fa4243e58.camel@intel.com>
Date: Tue, 7 Mar 2023 01:47:20 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Lutomirski, Andy" <luto@...nel.org>, "bp@...en8.de" <bp@...en8.de>
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>,
"keescook@...omium.org" <keescook@...omium.org>,
"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>,
"pavel@....cz" <pavel@....cz>, "oleg@...hat.com" <oleg@...hat.com>,
"hjl.tools@...il.com" <hjl.tools@...il.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"Yang, Weijiang" <weijiang.yang@...el.com>,
"jamorris@...ux.microsoft.com" <jamorris@...ux.microsoft.com>,
"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>,
"debug@...osinc.com" <debug@...osinc.com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
"rppt@...nel.org" <rppt@...nel.org>,
"john.allen@....com" <john.allen@....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>
Subject: Re: [PATCH v7 24/41] mm: Don't allow write GUPs to shadow stack
memory
On Mon, 2023-03-06 at 10:57 -0800, Andy Lutomirski wrote:
> On Mon, Mar 6, 2023, at 10:33 AM, Edgecombe, Rick P wrote:
> > On Mon, 2023-03-06 at 10:15 -0800, Andy Lutomirski wrote:
> > > On Mon, Mar 6, 2023 at 5:10 AM Borislav Petkov <bp@...en8.de>
> > > wrote:
> > > >
> > > > On Mon, Feb 27, 2023 at 02:29:40PM -0800, Rick Edgecombe wrote:
> > > > > The x86 Control-flow Enforcement Technology (CET) feature
> > > > > includes a new
> > > > > type of memory called shadow stack. This shadow stack memory
> > > > > has
> > > > > some
> > > > > unusual properties, which requires some core mm changes to
> > > > > function
> > > > > properly.
> > > > >
> > > > > Shadow stack memory is writable only in very specific,
> > > > > controlled
> > > > > ways.
> > > > > However, since it is writable, the kernel treats it as such.
> > > > > As a
> > > > > result
> > > >
> > > >
> > > >
> > > > ^
> > > >
> > > >
> > > > ,
> > > >
> > > > > there remain many ways for userspace to trigger the kernel to
> > > > > write to
> > > > > shadow stack's via get_user_pages(, FOLL_WRITE) operations.
> > > > > To
> > > > > make this a
> > >
> > > Is there an alternate mechanism, or do we still want to allow
> > > FOLL_FORCE so that debuggers can write it?
> >
> > Yes, GDB shadow stack support uses it via both ptrace poke and
> > /proc/pid/mem apparently. So some ability to write through is
> > needed
> > for debuggers. But not CRIU actually. It uses WRSS.
> >
> > There was also some discussion[0] previously about how apps might
> > prefer to block /proc/self/mem for general security reasons.
> > Blocking
> > shadow stack writes while you allow text writes is probably not
> > that
> > impactful security-wise. So I thought it would be better to leave
> > the
> > logic simpler. Then when /proc/self/mem could be locked down per
> > the
> > discussion, shadow stack can be locked down the same way.
>
> Ah, I am guilty of reading your changelog but not the code.
>
> You said:
>
> Shadow stack memory is writable only in very specific, controlled
> ways.
> However, since it is writable, the kernel treats it as such. As a
> result
> there remain many ways for userspace to trigger the kernel to write
> to
> shadow stack's via get_user_pages(, FOLL_WRITE) operations. To make
> this a
> little less exposed, block writable GUPs for shadow stack VMAs.
>
> I read that as *denying* FOLL_FORCE. Maybe clarify the changelog?
I think maybe some helpful text missed the quote in Boris comment about
other issues: "Still allow FOLL_FORCE to write through shadow stack
protections, as it does for read-only protections."
But, yea, the tenses are hard to parse. Maybe something like this:
The x86 Control-flow Enforcement Technology (CET) feature includes a
new type of memory called shadow stack. This shadow stack memory has
some unusual properties, which requires some core mm changes to
function properly.
In userspace, shadow stack memory is writable only in very specific,
controlled ways. However, since userspace can, even in the limited
ways, modify shadow stack contents, the kernel treats it as writable
memory. As a result, without additional work there would remain many
ways for userspace to trigger the kernel to write arbitrary data to
shadow stacks via get_user_pages(, FOLL_WRITE) based operations. To
help userspace protect their shadow stacks, make this a little less
exposed by blocking writable get_user_pages() operations for shadow
stack VMAs.
Still allow FOLL_FORCE to write through shadow stack protections, as it
does for read-only protections. This is required for debugging use
cases.
Powered by blists - more mailing lists