lkml.org 
[lkml]   [2019]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 1/4] x86/thread_info: introduce ->ftrace_int3_stack member
    From
    Date

    > On Apr 28, 2019, at 12:43 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
    >
    > On Sun, 28 Apr 2019 11:08:34 -0700
    > Andy Lutomirski <luto@amacapital.net> wrote:
    >
    >>>
    >>> Perhaps adding another slot into pt_regs that gets used by int3 to
    >>> store a slot to emulate a call on return?
    >>>
    >>>
    >>
    >> That’s not totally nuts, although finding pt_regs isn’t entirely trivial.
    >
    > I meant on the int3 handler (which stores the pt_regs).

    But that’s below the stub’s RSP, so it’s toast if another interrupt happens. Or am I misunderstanding you?

    >
    >>
    >> I still think I prefer an approach where we just emulate the call directly.
    >
    > Then, on the return of int3, if there's anything in that slot, then we
    > could possibly shift the exception handler frame (that was added by the
    > hardware), insert the slot data into the top of the stack, and then
    > call iret (which the int3 handler, would add the return ip to be the
    > function being called), which would in essence emulate the call directly.

    Oh, I get it.

    I liked Josh’s old proposal of unconditionally shifting the #BP frame 8 bytes better. It will be interesting when kernel shadow stacks are thrown in the mix, but that’s a problem for another day.

    \
     
     \ /
      Last update: 2019-04-28 22:56    [W:4.559 / U:0.888 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site