linux-hardening - Re: [PATCH 5.15 13/20] exit: Put an upper limit on how often we can oops

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:   Wed, 25 Jan 2023 10:44:23 -0800
From:   Eric Biggers <ebiggers@...nel.org>
To:     Harshit Mogalapalli <harshit.m.mogalapalli@...cle.com>
Cc:     stable@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Kees Cook <keescook@...omium.org>,
        SeongJae Park <sj@...nel.org>,
        Seth Jenkins <sethjenkins@...gle.com>,
        Jann Horn <jannh@...gle.com>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org,
        Luis Chamberlain <mcgrof@...nel.org>,
        Vegard Nossum <vegard.nossum@...cle.com>,
        Darren Kenny <darren.kenny@...cle.com>
Subject: Re: [PATCH 5.15 13/20] exit: Put an upper limit on how often we can
 oops

Hi Harshit,

On Wed, Jan 25, 2023 at 07:39:10PM +0530, Harshit Mogalapalli wrote:
> 
> Thanks for the backports.
> 
> I have tried backporting the oops_limit patches to LTS 5.15.y and had a
> similar set of patches, just want to add a note here on an alternate way for
> backporting this patch without resolving conflicts manually:
> 
> Here is the sequence:
> 
> * Patch 12:  [panic: Separate sysctl logic from CONFIG_SMP]
> --> Cherry-pick Commit: 05ea0424f0e2 ("exit: Move oops specific logic from
> do_exit into make_task_dead") upstream
> --> Cherry-pick Commit: de77c3a5b95c ("exit: Move force_uaccess back into
> do_exit") upstream
> * Patch 13 which is Commit: d4ccd54d28d3 ("exit: Put an upper limit on how
> often we can oops") upstream, will be a clean cherry-pick.
> 
> The benefit may be making future backports simpler in make_task_dead().
> 
> This was the only difference, so your backport looks good to me.
> 

It's certainly an option.  The reason why I didn't do it that way is to reduce
the impact of any potential bugs where do_exit() is still called when the new
make_task_dead() function should be used instead.  With my series, the effect is
just that oops_limit won't take effect in such cases.  If we also backported
commit 05ea0424f0e2 ("exit: Move oops specific logic from do_exit into
make_task_dead"), then do_exit() will lose various other things, such as
panicing when called from an interrupt handler.  That would increase the chance
of regressions, unless we made absolutely sure that everywhere that should be
using make_task_dead() is indeed using it instead of do_exit().

Commit 0e25498f8cd4 ("exit: Add and use make_task_dead."), which I backported,
did the vast majority of conversions to make_task_dead().

Some architectures still have uses of do_exit() that got cleaned up later,
though.  It seems it was mostly unreachable code, and some cases that should
have been doing something else such as BUG() or sending a signal to userspace.
So, generally not super important cases.

Still, getting all that would bring in many more patches.  We could do that, but
since this is already a 20-patch series, I wanted to limit the scope a bit.
These extra patches could always be backported later on top of this if desired.

- Eric