Skip to content
Snippets Groups Projects
  1. Jan 25, 2020
  2. Dec 23, 2019
  3. Dec 07, 2019
  4. Nov 14, 2019
  5. Nov 02, 2019
  6. Oct 08, 2019
  7. Oct 06, 2019
  8. Aug 21, 2019
  9. Aug 15, 2019
  10. Aug 13, 2019
  11. Aug 01, 2019
  12. Jul 31, 2019
  13. Jul 30, 2019
  14. Jul 27, 2019
  15. Jul 26, 2019
  16. Jul 24, 2019
  17. Jul 23, 2019
  18. Jul 21, 2019
  19. Jul 20, 2019
    • jD91mZM2's avatar
      WIP(ptrace): Only use non-signal stack when using a default handler · 6a3825d4
      jD91mZM2 authored
      This is a curious problem and it's really hard to solve it in a way
      that doesn't feel hacky. On one hand, of course you want to be able to
      modify and intercept what happens when you use a signal, right? On the
      other hand, changes made to the context (especially singlestepping)
      while a signal is handled (such as `SIGSTOP`) are not preserved since
      the stack is restored after the signal handler was invoked.
      
      I think what we have in this change makes sense anyway, as we don't
      really want users modifying registers and other data in the default
      signal behavior that occurs **in kernel mode**. Also trying to use
      `PTRACE_SINGLESTEP` will set the singlestep flag only if in a
      user-mode signal handler, else it will set it on the instruction after
      the signal handling, which I guess makes sense since it can't affect
      the kernel-mode code that runs the default handler.
      
      I don't know. Help. Pls.
      Verified
      6a3825d4
    • jD91mZM2's avatar
      Fix sigaction Undefind Behavior · 8695ecd8
      jD91mZM2 authored
      Rust does not allow a `fn`-pointer to be null. This fixes that, while
      luckily doing it in a way that leaves system calls
      backwards-compatible :)
      Verified
      8695ecd8
    • jD91mZM2's avatar
    • jD91mZM2's avatar
      Verified
      3d442424
Loading