linux-kernel - Re: [PATCH 2/5] x86, mpx: hook #BR exception handler to allocate bound tables

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:	Fri, 17 Jan 2014 12:14:57 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Borislav Petkov <bp@...en8.de>,
	"Ren, Qiaowei" <qiaowei.ren@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/5] x86, mpx: hook #BR exception handler to allocate
 bound tables

On Fri, 17 Jan 2014 08:51:03 -0800
"H. Peter Anvin" <hpa@...or.com> wrote:

> On 01/17/2014 08:47 AM, Borislav Petkov wrote:
> > 
> > Right, so Steve and I played a couple of scenarios in IRC with this. So
> > #BR is comparable with #PF, AFAICT, and as expected we don't take any
> > locks when handling page faults in kernel space as we might deadlock.
> > 
> > Now, what happens if a thread is sleeping on some lock down that
> > GFP_KERNEL allocation path and another thread gets a #BR and goes that
> > same mmap_pgoff path and tries to grab that same lock?
> 
> It goes to sleep.  Same as if we take a page fault and have to page
> something in.

Yep, which is what I was explaining to Boris on IRC.

> 
> > Also, what happens if you take a #BR in NMI context, say the NMI
> > handler?
> 
> You should never, ever do that.  We should never take a #BR in the
> kernel, full stop -- if we do it is panic time.

Right. It should actually do what a page fault does too. If we page
fault in NMI, it reports it and crashes.

> 
> > All I'm trying to say is, it might not be such a good idea to sleep in a
> > fault handler...
> 
> A fault handler from user space is really nothing other than a different
> kind of system call.  It is nothing magic about it.

Exactly. I was saying that #BR should be just like #PF, as it can
detect bugs in the kernel too. The first thing the handler should do is
check to see if the fault occurred in userspace or kernel space. If it
is userspace, then there's no restrictions. If it is kernel space then
we should do the bare minimum to report the bug and then kill whatever
task happened to do it.

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