Messages in this thread Patch in this message | | | Date | Tue, 27 Oct 2020 19:33:30 +0100 | From | Peter Zijlstra <> | Subject | [PATCH v2 3/3] Fix DR_STEP vs ptrace_get_debugreg(6) |
| |
Commit d53d9bc0cf78 ("x86/debug: Change thread.debugreg6 to thread.virtual_dr6") changed the semantics of the variable from random collection of bits, to exactly only those bits that ptrace() needs.
Unfortunately we lost DR_STEP for PTRACE_{BLOCK,SINGLE}STEP.
Furthermore, it turns out that userspace expects DR_STEP to be unconditionally available, even for manual TF usage outside of PTRACE_{BLOCK,SINGLE}_STEP.
Fixes: d53d9bc0cf78 ("x86/debug: Change thread.debugreg6 to thread.virtual_dr6") Reported-by: Kyle Huey <me@kylehuey.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> --- v2: uncondtionally provide DR_STEP, at the very least WINE relies on this
arch/x86/kernel/traps.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
--- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -937,10 +937,13 @@ static __always_inline void exc_debug_us instrumentation_begin(); /* - * Clear the virtual DR6 value, ptrace() routines will set bits here - * for things it wants signals for. + * Start the virtual/ptrace DR6 value with just the DR_STEP mask + * of the real DR6. ptrace_triggered() will set the DR_TRAPn bits. + * + * Userspace expects DR_STEP to be visible in ptrace_get_debugreg(6) + * even if it is not the result of PTRACE_SINGLESTEP. */ - current->thread.virtual_dr6 = 0; + current->thread.virtual_dr6 = (dr6 & DR_STEP); /* * The SDM says "The processor clears the BTF flag when it
| |