lkml.org 
[lkml]   [2022]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 00/39] Shadowstacks for userspace
    On Thu, Sep 29, 2022 at 03:28:57PM -0700, Rick Edgecombe wrote:
    > This is an overdue followup to the “Shadow stacks for userspace” CET series.
    > Thanks for all the comments on the first version [0]. They drove a decent
    > amount of changes for v2. Since it has been awhile, I’ll try to summarize the
    > areas that got major changes since last time. Smaller changes are listed in
    > each patch.

    Thanks for the write-up!

    > [...]
    > GUP
    > ---
    > Shadow stack memory is generally treated as writable by the kernel, but
    > it behaves differently then other writable memory with respect to GUP.
    > FOLL_WRITE will not GUP shadow stack memory unless FOLL_FORCE is also
    > set. Shadow stack memory is writable from the perspective of being
    > changeable by userspace, but it is also protected memory from
    > userspace’s perspective. So preventing it from being writable via
    > FOLL_WRITE help’s make it harder for userspace to arbitrarily write to
    > it. However, like read-only memory, FOLL_FORCE can still write through
    > it. This means shadow stacks can be written to via things like
    > “/proc/self/mem”. Apps that want extra security will have to prevent
    > access to kernel features that can write with FOLL_FORCE.

    This seems like a problem to me -- the point of SS is that there cannot be
    a way to write to them without specific instruction sequences. The fact
    that /proc/self/mem bypasses memory protections was an old design mistake
    that keeps leading to surprising behaviors. It would be much nicer to
    draw the line somewhere and just say that FOLL_FORCE doesn't work on
    VM_SHADOW_STACK. Why must FOLL_FORCE be allowed to write to SS?

    > [...]
    > Shadow stack signal format
    > --------------------------
    > So to handle alt shadow stacks we need to push some data onto a stack. To
    > prevent SROP we need to push something to the shadow stack that the kernel can
    > [...]
    > shadow stack return address or a shadow stack tokens. To make sure it can’t be
    > used, data is pushed with the high bit (bit 63) set. This bit is a linear
    > address bit in both the token format and a normal return address, so it should
    > not conflict with anything. It puts any return address in the kernel half of
    > the address space, so would never be created naturally by a userspace program.
    > It will not be a valid restore token either, as the kernel address will never
    > be pointing to the previous frame in the shadow stack.
    >
    > When a signal hits, the format pushed to the stack that is handling the signal
    > is four 8 byte values (since we are 64 bit only):
    > |1...old SSP|1...alt stack size|1...alt stack base|0|

    Do these end up being non-canonical addresses? (To avoid confusion with
    "real" kernel addresses?)

    -Kees

    --
    Kees Cook

    \
     
     \ /
      Last update: 2022-10-03 19:05    [W:2.386 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site