lkml.org 
[lkml]   [2022]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v4 29/39] x86/shstk: Handle signals for shadow stack
    On Fri, Dec 02, 2022 at 04:35:56PM -0800, Rick Edgecombe wrote:
    > From: Yu-cheng Yu <yu-cheng.yu@intel.com>
    >
    > When a signal is handled normally the context is pushed to the stack
    > before handling it. For shadow stacks, since the shadow stack only track's
    > return addresses, there isn't any state that needs to be pushed. However,
    > there are still a few things that need to be done. These things are
    > userspace visible and which will be kernel ABI for shadow stacks.
    >
    > One is to make sure the restorer address is written to shadow stack, since
    > the signal handler (if not changing ucontext) returns to the restorer, and
    > the restorer calls sigreturn. So add the restorer on the shadow stack
    > before handling the signal, so there is not a conflict when the signal
    > handler returns to the restorer.
    >
    > The other thing to do is to place some type of checkable token on the
    > thread's shadow stack before handling the signal and check it during
    > sigreturn. This is an extra layer of protection to hamper attackers
    > calling sigreturn manually as in SROP-like attacks.
    >
    > For this token we can use the shadow stack data format defined earlier.
    > Have the data pushed be the previous SSP. In the future the sigreturn
    > might want to return back to a different stack. Storing the SSP (instead
    > of a restore offset or something) allows for future functionality that
    > may want to restore to a different stack.
    >
    > So, when handling a signal push
    > - the SSP pointing in the shadow stack data format
    > - the restorer address below the restore token.
    >
    > In sigreturn, verify SSP is stored in the data format and pop the shadow
    > stack.
    >
    > Tested-by: Pengfei Xu <pengfei.xu@intel.com>
    > Tested-by: John Allen <john.allen@amd.com>
    > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>

    Reviewed-by: Kees Cook <keescook@chromium.org>

    --
    Kees Cook

    \
     
     \ /
      Last update: 2022-12-03 03:47    [W:7.003 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site