archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <>
To: Linus Torvalds <>
Cc: Linux Kernel Mailing List <>,
	Alexander Popov <>,
	Dave Hansen <>,
	Ingo Molnar <>,
	Masahiro Yamada <>,
	Thomas Gleixner <>,
	Tycho Andersen <>,
	Mark Rutland <>,
	Laura Abbott <>,
	Will Deacon <>
Subject: Re: [GIT PULL] gcc-plugin updates for v4.19-rc1
Date: Wed, 15 Aug 2018 12:45:44 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Aug 15, 2018 at 12:04 PM, Linus Torvalds
<> wrote:
> On Wed, Aug 15, 2018 at 11:35 AM Kees Cook <> 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.

I feel like we're talking cross purposes. The BUG() cases were for
places where we detect that we're executing with an impossible stack
pointer. It seems like trying to recover from that would just hide the
corruption for a later time that would be much harder to debug. These
weren't left in here to upset you. :) I have tried to take your "make
it debuggable" declaration to heart.

> 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.

It also handles VLA abuse, since those could (and have in past
exploits) been used to jump over guard pages. If you're saying you
want to see VLAs entirely removed and this feature dropped from the
plugin before you'll accept it, that's what we can do. I was trying to
help things develop in parallel since we're now three releases into
removing VLAs and it continues to be slow work.

> And if you don't  have vmalloc'ed stack, then clearly you don't care.

Agreed: this is why the plugin already does an "imply VMAP_STACK" for
Kconfig. Are you suggesting we should make it a hard "depends on

> 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.

I tried to detail in the pull request how we absolutely did not ignore
you. Something like 15 people have been helping to remove VLAs, and
I've been testing both gcc's stack forced-initialization patch and
Clang's, and doing it via a plugin (none are really "there" yet).


Kees Cook
Pixel Security

  parent reply	other threads:[~2018-08-15 19:45 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
2018-08-15 19:45       ` Kees Cook [this message]
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

Reply instructions:

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 \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).