[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jKPA1-=LdnXZLxXpzUaFKKnMbfyNg89y_UryWd4V9hGnA@mail.gmail.com>
Date: Fri, 7 Oct 2016 10:33:33 -0700
From: Kees Cook <keescook@...omium.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Willy Tarreau <w@....eu>,
Paul Gortmaker <paul.gortmaker@...driver.com>,
Johannes Weiner <hannes@...xchg.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Antonio SJ Musumeci <trapexit@...wn.link>,
Miklos Szeredi <miklos@...redi.hu>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
stable <stable@...r.kernel.org>
Subject: Re: BUG_ON() in workingset_node_shadows_dec() triggers
On Fri, Oct 7, 2016 at 10:21 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Fri, Oct 7, 2016 at 10:16 AM, Kees Cook <keescook@...omium.org> wrote:
>>
>> Regardless, I still think that we can't let BUG continue kernel
>> execution though, since it may lead to entirely unexpected behavior
>> (possibly security-sensitive) by still running. Upgrading BUG to
>> panic(), though, I'd be fine with, as a way to get people to convert
>> to WARN.
>
> No. Really. You can upgrade BUG() to "panic()" with a kernel command
> line. But not by default.
>
> I'm not going to take any patches that make BUG() even *worse*. That
> would be insane. I'm not insane.
I'll quit debating how to change things, but I'll just try to point
out that the "stop execution" logic, currently, is not an accident.
Without CONFIG_BUG, BUG is defined as "do {} while (1)", and without
CONFIG_HAVE_ARCH_BUG, BUG is defined as "printk(...); panic(...);".
-Kees
--
Kees Cook
Nexus Security
Powered by blists - more mailing lists