LKML Archive on lore.kernel.org
 help / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Kees Cook <keescook@chromium.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Alexander Popov <alex.popov@linux.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Ingo Molnar <mingo@kernel.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tycho Andersen <tycho@tycho.ws>,
	Mark Rutland <mark.rutland@arm.com>,
	Laura Abbott <labbott@redhat.com>,
	Will Deacon <will.deacon@arm.com>
Subject: Re: [GIT PULL] gcc-plugin updates for v4.19-rc1
Date: Wed, 15 Aug 2018 13:18:57 -0700
Message-ID: <CA+55aFy6jNLsywVYdGp83AMrXBo_P-pkjkphPGrO=82SPKCpLQ@mail.gmail.com> (raw)
In-Reply-To: <CAGXu5jJ1JNSxJABUTAO85z_hXjSkjD=nWEho7KrYJTqqVGivig@mail.gmail.com>

On Wed, Aug 15, 2018 at 12:45 PM Kees Cook <keescook@chromium.org> wrote:
>
> 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.

The thing is, BUG() is not debuggable.

I absolutely refuse to take any hardening patches at all that have
BUG() or panic() or similar machine-killing in it.

I care not one whit about the reason for them. In fact, if the reason
is stated as "it makes debugging easiler", then I fart in your general
direction and call your mother a hamster.

Dammit, I suspect you guys are "testing" this by running things in a
VM, and then a BUG() looks like a good thing to do.

But if people run things on real machines, then BUG() is absolutely
the last thing you EVER want to do for "debugging".

This is why I scanned your pull request for BUG() and similar. Because
I simply will not take "hardening" that kills the machine. That's a
hard requirement. No excuses, and absolutely zero exceptions.

After a year or two, when the hardening has actually been in place,
and you can say "hey, look, none of the warnings happened", I may be
ok with turning them into BUG() calls.

> It also handles VLA abuse, since those could (and have in past
> exploits) been used to jump over guard pages.

I really don't think that's a valid model at all. We need to get rid
of the VLA abuse, not make complex compiler plugins for it.

I thought VLA's were mostly gone. I think we can at this point almost
just mark them broken, or disable any code that uses them when people
enable the stack options.

Adding a few

        depends on !SAFE_STACK

to the drivers or code that still uses VLA's and then making the stack plugin do

        select SAFE_STACK

and simply refuse to compile alloca sounds reasonable to me.

People who then want some stack validation or clearing can either
decide they don't care about those pieces, or fix them one by one.

               Linus

  reply index

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
2018-08-15 19:43       ` Alexander Popov
2018-08-15 19:45       ` Kees Cook
2018-08-15 20:18         ` Linus Torvalds [this message]
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 publically 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+55aFy6jNLsywVYdGp83AMrXBo_P-pkjkphPGrO=82SPKCpLQ@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=alex.popov@linux.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=keescook@chromium.org \
    --cc=labbott@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tycho@tycho.ws \
    --cc=will.deacon@arm.com \
    --cc=yamada.masahiro@socionext.com \
    /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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org linux-kernel@archiver.kernel.org
	public-inbox-index lkml


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox