linux-kernel - Simplifying or removing DEBUG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 21 Apr 2015 12:57:10 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"H. Peter Anvin" <hpa@...or.com>, Jan Beulich <jbeulich@...e.com>,
	Ingo Molnar <mingo@...nel.org>, X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Borislav Petkov <bp@...en8.de>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Simplifying or removing DEBUG_STACK?

Hi all-

On x86_64, we use IST for #BP and #DB.  On x86_32, we don't.

We started using IST for #BP in:

b556b35e98ad [PATCH] x86_64: Move int 3 handler to debug stack and
allow to increase it.

and we started using IST for #DB even earlier in:

7abe2c67299e [PATCH] x86-64 merge for 2.6.4

This has some unpleasant side effects these days.  Primarily, it
requires a bunch of ugly code to avoid recursive use of the debug
stack when, say, an NMI interrupts do_int3 or do_debug and either hits
a kprobe int3 or a #DB if it inadvertently touches a userspace
watchpoint.  See TRACE_IRQS_OFF_DEBUG for another bit wart in that
code.

Here are all of the reasons I can come up with for using IST:

1. SYSENTER with TF set will immediately (or after one instruction --
I'm not quite sure) cause #DB.  This is easy to handle -- we can just
set up a sysenter stack just like x86_32.

2. #DB needs paranoid gsbase handling (due to SYSENTER if nothing
else).  However, there's no real reason that IST and paranoid gsbase
handling need to be tied together.

3. Stack usage.  Almost anything can hit a kprobe and any uaccess
operation can hit a watchpoint.  I'm not sure how much of a problem
this is.  If it is a real problem, we could use something more like
the irqstack mechanism instead of IST.

4. kgdb.  kgdb doesn't appear to respect the kprobe blacklist at all,
so kdbg would blow up if it tried to breakpoint early or late in
syscall handling.  (Hmm.  I bet kdbg also blows up if you use it to
put a breakpoint early in do_int3.)

Thoughts?

Even if it turns out that we can't get rid of IST for #DB and #BP, I
bet we could simplify matters by rigging up the all of the IST entries
to switch IST off for #DB and #BP immediately upon entry and to leave
them off until immediately before returning, thereby simplifying the
logic quite a bit.  I think this would be a pure performance win --
the only patch here in which performance matters is NMI AFAICT, and
the NMI code already does that, albeit rather deeply buried.

--Andy

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/