From: Linus Torvalds <email@example.com> To: Kees Cook <firstname.lastname@example.org> Cc: Linux Kernel Mailing List <email@example.com>, Alexander Popov <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 12:04:00 -0700 [thread overview] Message-ID: <CA+55aFyFCWH3YJnRUKtSzs9Mvny0eU+=QANxoPTE+9B9CkUWDw@mail.gmail.com> (raw) In-Reply-To: <CAGXu5jK_w7JRywdQ78FfQxeLSMmXbvyDDnaYzj27=y8wnAzKxQ@mail.gmail.com> On Wed, Aug 15, 2018 at 11:35 AM Kees Cook <email@example.com> 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
next prev parent reply other threads:[~2018-08-15 19:04 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-08-13 21:43 Kees Cook 2018-08-15 16:41 ` Linus Torvalds 2018-08-15 18:35 ` Kees Cook 2018-08-15 19:04 ` Linus Torvalds [this message] 2018-08-15 19:43 ` Alexander Popov 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
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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CA+55aFyFCWH3YJnRUKtSzs9Mvny0eU+=QANxoPTE+9B9CkUWDw@mail.gmail.com' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [GIT PULL] gcc-plugin updates for v4.19-rc1' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
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).