Thread (73 messages) 73 messages, 9 authors, 2018-09-14

Re: [RFC PATCH v3 12/24] x86/mm: Modify ptep_set_wrprotect and pmdp_set_wrprotect for _PAGE_DIRTY_SW

From: Andy Lutomirski <luto@amacapital.net>
Date: 2018-08-31 01:23:21
Also in: linux-api, linux-arch, linux-doc, lkml

On Aug 30, 2018, at 10:59 AM, Jann Horn [off-list ref] wrote:
quoted
On Thu, Aug 30, 2018 at 7:58 PM Yu-cheng Yu [off-list ref] wrote:
quoted
On Thu, 2018-08-30 at 10:33 -0700, Dave Hansen wrote:
quoted
On 08/30/2018 10:26 AM, Yu-cheng Yu wrote:

We don't have the guard page now, but there is a shadow stack
token
there, which cannot be used as a return address.
The overall concern is that we could overflow into a page that we
did
not intend.  Either another actual shadow stack or something that a
page
that the attacker constructed, like the transient scenario Jann
described.
A task could go beyond the bottom of its shadow stack by doing either
'ret' or 'incssp'.  If it is the 'ret' case, the token prevents it.
If it is the 'incssp' case, a guard page cannot prevent it entirely,
right?
I mean the other direction, on "call".
I still think that shadow stacks should work just like mmap and that mmap should learn to add guard pages for all non-MAP_FIXED allocations.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help