linux-kernel - Re: BUG_ON() in workingset_node_shadows

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:   Thu, 6 Oct 2016 16:05:59 -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 Thu, Oct 6, 2016 at 3:29 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Thu, Oct 6, 2016 at 3:07 PM, Kees Cook <keescook@...omium.org> wrote:
>> The "cleanest" way to handle it seemed to be the lock-busting logic
>> already built into BUG, so I moved to that.
>
> Heh. The lock-busting logic in BUG() has always been broken. It's been
> random hacks. It doesn't actually work in any general case, it just
> occasionally happens to get things right. Mostly it tries to handle
> the console locking (the whole "oops_in_progress" magic) so that if
> you have a BUG_ON() in bad areas, at least you still end up getting
> output.

It seems to handle other things too, file descriptors, I think? Some
giant warning, I think about fds, went away when I switched from
do_exit() to BUG(). I'd have to go look more closely.

> But no, it's not reliable in any way, shape or form. That's really why
> you want to continue after a BUG().

Yeah, agreed about the unreliability. It's why I'm a fan of
panic_on_oops. :P (Except when doing lots of tests under lkdtm, then I
like having multiple Oopses without rebooting, but perhaps that is
literally the only use-case...)

>> By far the most problematic is "stop kernel execution from
>> continuing", but that's currently the behavior that BUG depends on, so
>> replacing BUG with anything needs to either fix the surrounding logic
>> to fail sanely or we have the keep the feature.
>
> Well, I'm not sure how much we actually end up depending on it,
> considering that we now have two examples of BUG() implementations
> that actually do _not_ depend on stopping execution: both the sound
> subsystem and the XFS version of BUG_ON() end up not actually doing
> the BUG() thing.

Yeah, for sure. I didn't mean to imply they all depended on it, just
that finding those that do will require manual inspection. We'll not
be able to do a flag-day on BUG until we fix everything.

-Kees

-- 
Kees Cook
Nexus Security