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 09:51:01 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Steven Rostedt <rostedt@...dmis.org>
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 01/17/2014 09:14 AM, Steven Rostedt wrote:
>>
>>> 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.
> 

Yes.  We call this "oopsing" ;)

	-hpa


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

Powered by blists - more mailing lists