[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1535649960.26689.15.camel@intel.com>
Date: Thu, 30 Aug 2018 10:26:00 -0700
From: Yu-cheng Yu <yu-cheng.yu@...el.com>
To: Dave Hansen <dave.hansen@...ux.intel.com>,
Jann Horn <jannh@...gle.com>
Cc: the arch/x86 maintainers <x86@...nel.org>,
"H . Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
kernel list <linux-kernel@...r.kernel.org>,
linux-doc@...r.kernel.org, Linux-MM <linux-mm@...ck.org>,
linux-arch <linux-arch@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>,
Andy Lutomirski <luto@...capital.net>,
Balbir Singh <bsingharora@...il.com>,
Cyrill Gorcunov <gorcunov@...il.com>,
Florian Weimer <fweimer@...hat.com>, hjl.tools@...il.com,
Jonathan Corbet <corbet@....net>, keescook@...omiun.org,
Mike Kravetz <mike.kravetz@...cle.com>,
Nadav Amit <nadav.amit@...il.com>,
Oleg Nesterov <oleg@...hat.com>, Pavel Machek <pavel@....cz>,
Peter Zijlstra <peterz@...radead.org>,
ravi.v.shankar@...el.com, vedvyas.shanbhogue@...el.com
Subject: Re: [RFC PATCH v3 12/24] x86/mm: Modify ptep_set_wrprotect and
pmdp_set_wrprotect for _PAGE_DIRTY_SW
On Thu, 2018-08-30 at 10:19 -0700, Dave Hansen wrote:
> On 08/30/2018 09:23 AM, Jann Horn wrote:
> >
> > Three threads (A, B, C) run with the same CR3.
> >
> > 1. a dirty+writable PTE is placed directly in front of B's shadow
> > stack.
> > (this can happen, right? or is there a guard page?)
> > 2. C's TLB caches the dirty+writable PTE.
> > 3. A performs some syscall that triggers ptep_set_wrprotect().
> > 4. A's syscall calls clear_bit().
> > 5. B's TLB caches the transient shadow stack.
> > [now C has write access to B's transiently-extended shadow stack]
> > 6. B recurses into the transiently-extended shadow stack
> > 7. C overwrites the transiently-extended shadow stack area.
> > 8. B returns through the transiently-extended shadow stack, giving
> > the attacker instruction pointer control in B.
> > 9. A's syscall broadcasts a TLB flush.
> Heh, that's a good point. The shadow stack permissions are *not*
> strictly reduced because a page getting marked as shadow-stack has
> *increased* permissions when being used as a shadow stack. Fun.
>
> For general hardening, it seems like we want to ensure that there's
> a
> guard page at the bottom of the shadow stack. Yu-cheng, do we have
> a
> guard page?
We don't have the guard page now, but there is a shadow stack token
there, which cannot be used as a return address.
Yu-cheng
Powered by blists - more mailing lists