On Thu, Jul 23, 2015 at 1:49 PM, Andy Lutomirski <l...@amacapital.net> wrote:
>
> Issue A: to return with RF clear, we need to disarm the breakpoint.
> If it's limited to the duration of the NMI, that's easy. If not, when
> do we re-arm? New prepare_exit_to_usermode hook? Hmm, setting ti
> flags during context switch may target the wrong task.
We don't re-arm it.
We can entertain the notion *eventually* to do something clever, but
for now, just say: stability and simplicity is more important.
People can use tracepoints in interrupts-off code (they get rewritten
with 'int3', that's fine), but not instruction breakpoints.
> Issue C: #DB with invalid stack pointer (can happen due to watchpoints
> during SYSCALL entry or SYSRET exit). I guess we need to ban such
> watchpoints.
.. but this is unrelated, to NMI, just "syscall is a nasty interface".
Don't we already ban them?
> Issue D: debug exception inside EFI (especially mixed-mode EFI). We
> can't return using RET, so we need to catch that case.
If NMI code calls EFI code, then it's broken.
> These issues mostly go away if we preemptively disarm DR7 early in NMI
> processing and rearm it at the end.
I'm not *violently* opposed to that, but it's just a band-aid. It
doesn't *fix* anything. You aren't protecting against random DB
exceptions just because somebody put a data breakpoint on the NMI
stack, for example. You still get page faults. Etc etc.
So I thinkt he whole "use ret instead" is a pretty simple approach.
Make that "just work".
Then, if you want to play with dr7 inside NMI to make it more likely
that you can have breakpoints live in irq-off situation, I think
that's a magic special case. It shouldn't be part of the design.
Things should work without it.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
