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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 4 Apr 2017 17:22:27 -0700 From: Linus Torvalds <torvalds@...ux-foundation.org> To: Kees Cook <keescook@...omium.org> Cc: Tommi Rantala <tommi.t.rantala@...ia.com>, Dave Jones <davej@...emonkey.org.uk>, Linux-MM <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>, Laura Abbott <labbott@...hat.com>, Ingo Molnar <mingo@...nel.org>, Josh Poimboeuf <jpoimboe@...hat.com>, Mark Rutland <mark.rutland@....com>, Eric Biggers <ebiggers@...gle.com> Subject: Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! On Tue, Apr 4, 2017 at 3:55 PM, Linus Torvalds <torvalds@...ux-foundation.org> wrote: > > I already explained what the likely fix is: make devmem_is_allowed() > return a ternary value, so that those things that *do* read the BIOS > area can just continue to do so, but they see zeroes for the parts > that the kernel has taken over. Actually, a simpler solution might be to (a) keep the binary value (b) remove the test for the low 1M (c) to avoid breakage, don't return _error_, but just always read zero that also removes (or at least makes it much more expensive) a signal of which pages are kernel allocated vs BIOS allocated. Linus
Powered by blists - more mailing lists