Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 15 Jul 2016 15:00:54 -0400
From: Daniel Micay <>
Cc: LKML <>, Rik van Riel <>, 
 Casey Schaufler <>, PaX Team <>,
 Brad Spengler <>,  Russell King
 <>, Catalin Marinas <>, Will
 Deacon <>, Ard Biesheuvel <>,
 Benjamin Herrenschmidt <>, Michael Ellerman
 <>, Tony Luck <>,  Fenghua Yu
 <>, "David S. Miller" <>,
 "" <>, Christoph Lameter <>, Pekka
 Enberg <>, David Rientjes <>, Joonsoo
 Kim <>, Andrew Morton <>,
 Andy Lutomirski <>, Borislav Petkov <>, Mathias
 Krause <>,  Jan Kara <>, Vitaly Wool
 <>, Andrea Arcangeli <>,  Dmitry
 Vyukov <>, Laura Abbott <>, 
 "" <>, sparclinux
 <>,  linux-arch <>,
 Linux-MM <>
Subject: Re: Re: [PATCH v2 02/11] mm: Hardened usercopy

> This could be a BUG, but I'd rather not panic the entire kernel.

It seems unlikely that it will panic without panic_on_oops and that's
an explicit opt-in to taking down the system on kernel logic errors
exactly like this. In grsecurity, it calls the kernel exploit handling
logic (panic if root, otherwise kill all process of that user and ban
them until reboot) but that same logic is also called for BUG via oops
handling so there's only really a distinction with panic_on_oops=1.

Does it make sense to be less fatal for a fatal assertion that's more
likely to be security-related? Maybe you're worried about having some
false positives for the whitelisting portion, but I don't think those
will lurk around very long with the way this works.
Download attachment "signature.asc" of type "application/pgp-signature" (852 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.