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 Mon, Oct 03, 2022 at 06:33:52PM +0000, Edgecombe, Rick P wrote:
    > On Mon, 2022-10-03 at 10:04 -0700, Kees Cook wrote:
    > > > 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?)
    >
    > Usually, but not necessarily with LAM. LAM cannot mask bit 63 though.
    > So hypothetically they could become "real" kernel addresses some day.
    > To keep them in the user half but still make sure they are not usable,
    > you would either have to encode the bits over a lot of entries which
    > would use extra space, or shrink the available address space, which
    > could cause compatibility problems.
    >
    > Do you think it's an issue?

    Nah; I think it's a good solution. I was just trying to make sure I
    understood it correctly. Thanks!

    --
    Kees Cook

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