linux-kernel - Re: [PATCH 1/1] Fix int1 recursion when no perf_bp

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 14 Dec 2015 10:28:38 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Jeff Merkey <linux.mdb@...il.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Andy Lutomirski <luto@...nel.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Borislav Petkov <bp@...en8.de>, Jiri Olsa <jolsa@...nel.org>
Subject: Re: [PATCH 1/1] Fix int1 recursion when no perf_bp_event is
 registeredy


* Jeff Merkey <linux.mdb@...il.com> wrote:

> On 12/14/15, Ingo Molnar <mingo@...nel.org> wrote:
> >
> > A: Because it messes up the order in which people normally read text.
> > Q: Why is top-posting such a bad thing?
> > A: Top-posting.
> > Q: What is the most annoying thing in e-mail?
> >
> > * Jeff Merkey <linux.mdb@...il.com> wrote:
> >
> >> I trigger it by writing to the dr7 and dr1, 2, 3 or four register and set an 
> >> execute breakpoint without going through arch_install_hw_breakpoint.  When 
> >> the breakpoint fires, the system crashes and hangs on the processor stuck in 
> >> an endless loop inside the int1 handler in hw_breakpoint.c --
> >
> > What is still not clear to me, can you trigger the hang not via some special
> >
> > kernel driver that goes outside regular APIs and messes with the state of the 
> > debug registers, but via the proper access methods, i.e. various user-space 
> > ABIs?
> 
> Any process that can get access to the debug registers can trigger this 
> condition. [...]

A process on an unmodified Linux kernel can only modify debug registers via the 
proper APIs:

> [...]  As it stands, if restricted to the established API in hw_breakpoint.c 
> this bug should not occur unless someone triggers an errant breakpoint. [...]

So am I interpreting your report correctly:

  "If the Linux kernel is modified to change debug registers without using the
   proper APIs (such as loading a module that changes hardware registers in a raw 
   fashion), things may break and a difficult to debug hang may occur."

right?

This key piece of information should have been part of the original report.

So I'm wondering, why does your module modify debug registers in a raw fashion? 
Why doesn't it use the proper APIs?

Thanks,

	Ingo
--
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/