linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Daniel Micay <danielmicay@gmail.com>,
	Ingo Molnar <mingo@kernel.org>, Kees Cook <keescook@chromium.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Alexander Popov <alex.popov@linux.com>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>,
	PaX Team <pageexec@freemail.hu>,
	Brad Spengler <spender@grsecurity.net>,
	Andy Lutomirski <luto@kernel.org>,
	Tycho Andersen <tycho@tycho.ws>,
	Laura Abbott <labbott@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Borislav Petkov <bp@alien8.de>,
	Richard Sandiford <richard.sandiford@arm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"Dmitry V . Levin" <ldv@altlinux.org>,
	Emese Revfy <re.emese@gmail.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	Thomas Garnier <thgarnie@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexei Starovoitov <ast@kernel.org>, Josef Bacik <jbacik@fb.com>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Nicholas Piggin <npiggin@gmail.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	"David S . Miller" <davem@davemloft.net>,
	Ding Tianhong <dingtianhong@huawei.com>,
	David Woodhouse <dwmw@amazon.co.uk>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Dominik Brodowski <linux@dominikbrodowski.net>,
	Juergen Gross <jgross@suse.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Mathias Krause <minipli@googlemail.com>,
	Vikas Shivappa <vikas.shivappa@linux.intel.com>,
	Kyle Huey <me@kylehuey.com>,
	Dmitry Safonov <dsafonov@virtuozzo.com>,
	Will Deacon <will.deacon@arm.com>, X86 ML <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC v9 4/7] x86/entry: Erase kernel stack in syscall_trace_enter()
Date: Tue, 6 Mar 2018 14:41:55 -0800	[thread overview]
Message-ID: <CA+55aFyuQZ-cYxPeGF2VJu2GjzznQTua6sVBi4+CFdUi+=+Ajw@mail.gmail.com> (raw)
In-Reply-To: <20180306172927.7a975cee@vmware.local.home>

On Tue, Mar 6, 2018 at 2:29 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> Yeah but I would argue that static variables are different.

Not really.

You're basically saying "I'd like my language to have intrinsic
undefined behavior, so that when I hit a bug that might trigger that
undefined behavior I get a warning":.

Do such bugs happen? Sure. But _other_ bugs happen all the time, and
the ONLY real reason you are so adamant about _that_ particular
warning, is that "undefined behavior" is such a serious problem.

Think about that for a second.

Make the serious problem go away, and the warning MAKES NO SENSE.

Do you want a compiler to warn you when you write code like this:

    double area(double radius)
    {
         return radius*2*pi;
    }

just because it's obviously buggy shit?

And do you *really* expect a compiler warning for that kind of
obviously buggy shit?

I bet you don't.

And if you don't, why do you expect a compiler warning for

  int g(int c)
  {
         int i = 0;
         if (c)
                 i = 1;
         return i;
  }

which is *literally* what your example would have been had just C been
specified to avoid unnecessary undefined behavior?

Seriously. Look at that example, and tell me that gcc should warn
about it. I can imagine the warning ("warning: function 'g()' is
stupidly written, just use !!c").

But nobody sane really would expect a compiler to warn about it. Once
a compiler is that smart, you wouldn't write code for it, you'd just
ask it to generate code from a description.

Guys, everybody agrees that C isn't a safe language.

Do you think that lack of safety is a _good_ thing?

Do you realize that most of the lack of safety is almost directly
about flexibility, simplicity, and good code generation?

But what if I told you that some of the lack of safety doesn't
actually add to flexibility, simplicity, _or_ good code generation?
Wouldn't you say "we don't want it to be unsafe" then?

I'm literally telling you that lack of variable initialization is
almost purely a bad thing. C would be a safer language, with less
undefined behavior, if it just made the initialization of automatic
variables be something you cannot avoid.

For scalars in particular, there is basically no downside. Aggregate
types really are much less black-and-white.

                 Linus

  reply	other threads:[~2018-03-06 22:41 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-03 20:00 [PATCH RFC v9 0/7] Introduce the STACKLEAK feature and a test for it Alexander Popov
2018-03-03 20:00 ` [PATCH RFC v9 1/7] gcc-plugins: Clean up the cgraph_create_edge* macros Alexander Popov
2018-03-03 20:00 ` [PATCH RFC v9 2/7] x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscalls Alexander Popov
2018-03-05 16:41   ` Dave Hansen
2018-03-05 19:43     ` Laura Abbott
2018-03-05 19:50       ` Dave Hansen
2018-03-05 20:25       ` Peter Zijlstra
2018-03-05 21:21         ` Alexander Popov
2018-03-05 21:36           ` Kees Cook
2018-03-21 11:04         ` Alexander Popov
2018-03-21 15:33           ` Dave Hansen
2018-03-22 20:56             ` Alexander Popov
2018-03-26 17:32               ` Kees Cook
2018-03-26 17:43                 ` Andy Lutomirski
2018-03-03 20:00 ` [PATCH RFC v9 3/7] gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack Alexander Popov
2018-03-03 20:00 ` [PATCH RFC v9 4/7] x86/entry: Erase kernel stack in syscall_trace_enter() Alexander Popov
2018-03-05 19:40   ` Dave Hansen
2018-03-05 20:06     ` Kees Cook
2018-03-05 20:15       ` Linus Torvalds
2018-03-05 21:02         ` Alexander Popov
2018-03-05 21:02         ` Kees Cook
2018-03-05 21:40           ` Linus Torvalds
2018-03-05 22:07             ` Linus Torvalds
2018-03-06  0:56             ` Kees Cook
2018-03-06  4:30               ` Linus Torvalds
2018-03-06 17:58                 ` Andy Lutomirski
2018-03-06  7:56               ` [OLD PATCH] net: recvmsg: Unconditionally zero struct sockaddr_storage " Ingo Molnar
2018-03-06  8:08           ` Ingo Molnar
2018-03-06 15:16             ` Daniel Micay
2018-03-06 15:28               ` Daniel Micay
2018-03-06 18:56               ` Linus Torvalds
2018-03-06 19:07                 ` Peter Zijlstra
2018-03-06 19:07                 ` Ard Biesheuvel
2018-03-06 19:16                   ` Linus Torvalds
2018-03-06 20:42                     ` Arnd Bergmann
2018-03-06 21:01                       ` Linus Torvalds
2018-03-06 21:21                         ` Arnd Bergmann
2018-03-06 21:29                           ` Linus Torvalds
2018-03-06 22:09                             ` Arnd Bergmann
2018-03-06 22:24                               ` Linus Torvalds
2018-03-06 21:36                         ` Steven Rostedt
2018-03-06 21:41                           ` Linus Torvalds
2018-03-06 21:47                             ` Linus Torvalds
2018-03-06 22:29                               ` Steven Rostedt
2018-03-06 22:41                                 ` Linus Torvalds [this message]
2018-03-06 22:52                                   ` Steven Rostedt
2018-03-06 23:09                                     ` Linus Torvalds
2018-03-12  8:22                               ` Ingo Molnar
2018-03-12  9:00                                 ` Ard Biesheuvel
2018-03-12  9:21                                   ` Ingo Molnar
2018-03-06 21:47                           ` Arnd Bergmann
2018-03-06 22:19                             ` Linus Torvalds
2018-03-05 20:26       ` Peter Zijlstra
2018-03-03 20:00 ` [PATCH RFC v9 5/7] lkdtm: Add a test for STACKLEAK Alexander Popov
2018-03-03 20:00 ` [PATCH RFC v9 6/7] fs/proc: Show STACKLEAK metrics in the /proc file system Alexander Popov
2018-03-03 20:00 ` [PATCH RFC v9 7/7] doc: self-protection: Add information about STACKLEAK feature Alexander Popov
2018-03-05 19:34 ` [PATCH RFC v9 0/7] Introduce the STACKLEAK feature and a test for it Kees Cook
2018-03-05 19:42   ` Dave Hansen
2018-03-05 20:02     ` Kees Cook

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+55aFyuQZ-cYxPeGF2VJu2GjzznQTua6sVBi4+CFdUi+=+Ajw@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=alex.popov@linux.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=aryabinin@virtuozzo.com \
    --cc=ast@kernel.org \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=danielmicay@gmail.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=dingtianhong@huawei.com \
    --cc=dsafonov@virtuozzo.com \
    --cc=dwmw@amazon.co.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=jbacik@fb.com \
    --cc=jgross@suse.com \
    --cc=jpoimboe@redhat.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=labbott@redhat.com \
    --cc=ldv@altlinux.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=luto@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=me@kylehuey.com \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=minipli@googlemail.com \
    --cc=npiggin@gmail.com \
    --cc=pageexec@freemail.hu \
    --cc=re.emese@gmail.com \
    --cc=richard.sandiford@arm.com \
    --cc=rostedt@goodmis.org \
    --cc=spender@grsecurity.net \
    --cc=tglx@linutronix.de \
    --cc=thgarnie@google.com \
    --cc=tycho@tycho.ws \
    --cc=vikas.shivappa@linux.intel.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will.deacon@arm.com \
    --cc=x86@kernel.org \
    /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
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).