| 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
| ||
|
Message-ID: <52D96D85.5060708@zytor.com> 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