[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyFCWH3YJnRUKtSzs9Mvny0eU+=QANxoPTE+9B9CkUWDw@mail.gmail.com>
Date: Wed, 15 Aug 2018 12:04:00 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kees Cook <keescook@...omium.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Alexander Popov <alex.popov@...ux.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Ingo Molnar <mingo@...nel.org>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
Thomas Gleixner <tglx@...utronix.de>,
Tycho Andersen <tycho@...ho.ws>,
Mark Rutland <mark.rutland@....com>,
Laura Abbott <labbott@...hat.com>,
Will Deacon <will.deacon@....com>
Subject: Re: [GIT PULL] gcc-plugin updates for v4.19-rc1
On Wed, Aug 15, 2018 at 11:35 AM Kees Cook <keescook@...omium.org> wrote:
>
> I swear I'm doing my best. Are you speaking of
> stackleak_check_alloca() or stackleak_erase()? These were both
> discussed on the list, and we weren't able to come up with
> alternatives: in both cases we're off the stack, and recovery is
> seemingly impossible.
Why do you even *test* that thing? Why don't you just allocate stack
and clear it.
Dammit, the whole f*cking point of this patch-set is to clear the
stack used. It is *not* supposed to do anything else. If the process
runs out of stack, that's caught by the vmalloc'ed stack.
And if you don't have vmalloc'ed stack, then clearly you don't care.
I refuse to take this kind of code that does stupid things, and then
*because* it does those initial stupid things it does even more stupid
things to correct for it.
I hated the thing to begin with, told people that there are better
approaches that don't have the downsides, got ignored, and then I'm
pushed crap.
No.
Linus
Powered by blists - more mailing lists