From: Alexander Popov <email@example.com>
To: Linus Torvalds <firstname.lastname@example.org>,
Kees Cook <email@example.com>
Cc: Linux Kernel Mailing List <firstname.lastname@example.org>,
Dave Hansen <email@example.com>,
Ingo Molnar <firstname.lastname@example.org>,
Masahiro Yamada <email@example.com>,
Thomas Gleixner <firstname.lastname@example.org>,
Tycho Andersen <email@example.com>,
Mark Rutland <firstname.lastname@example.org>,
Laura Abbott <email@example.com>,
Will Deacon <firstname.lastname@example.org>
Subject: Re: [GIT PULL] gcc-plugin updates for v4.19-rc1
Date: Wed, 15 Aug 2018 22:43:12 +0300 [thread overview]
Message-ID: <email@example.com> (raw)
On 15.08.2018 22:04, Linus Torvalds wrote:
> On Wed, Aug 15, 2018 at 11:35 AM Kees Cook <firstname.lastname@example.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.
Could you please have a look at the commit messages (or at the code)? You are
really arguing with wrong things! Let me correct Kees and give you the details.
Please don't be angry.
Again, this plugin provides two features: kernel stack erasing and blocking
Stack Clash (ability to jump over the guard page provided by VMAP_STACK).
1. stackleak_erase() erases the stack. It has a BUG_ON() to detect
'task_struct.lowest_stack' corruption. It's not a security violation BUG(),
which you hate. We just don't want to erase wrong memory. We have discussed that
with Ingo and others.
2. stackleak_check_alloca() detects 'Stack Clash' and it does absolutely similar
things with VMAP_STACK and SCHED_STACK_END_CHECK. Having VMAP_STACK + STACKLEAK
+ THREAD_INFO_IN_TASK together protects us from all known stack depth overflows.
Yes, one day we will remove all VLA's from the mainline kernel. But STACKLEAK
plugin protects un-upstreamed code as well.
I've put so much effort (1.5 years) to polish it and make you, Ingo and others
next prev parent reply other threads:[~2018-08-15 19:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-13 21:43 [GIT PULL] gcc-plugin updates for v4.19-rc1 Kees Cook
2018-08-15 16:41 ` Linus Torvalds
2018-08-15 18:35 ` Kees Cook
2018-08-15 19:04 ` Linus Torvalds
2018-08-15 19:43 ` Alexander Popov [this message]
2018-08-15 19:45 ` Kees Cook
2018-08-15 20:18 ` Linus Torvalds
2018-08-15 20:56 ` Kees Cook
2018-08-15 21:18 ` Alexander Popov
2018-08-15 21:33 ` Linus Torvalds
2018-08-16 22:18 ` Alexander Popov
2018-08-16 9:51 ` David Laight
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).