linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Kees Cook <keescook@chromium.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Randy Dunlap <rdunlap@infradead.org>,
	Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	Ingo Molnar <mingo@kernel.org>,
	David Laight <David.Laight@aculab.com>,
	Ian Abbott <abbotti@mev.co.uk>,
	linux-input@vger.kernel.org, linux-btrfs@vger.kernel.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-hardening@lists.openwall.com
Subject: Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()
Date: Fri, 16 Mar 2018 12:47:58 +0100	[thread overview]
Message-ID: <ab2933a2-ca7b-eb3b-744d-bc037b1be688@redhat.com> (raw)
In-Reply-To: <1521174359-46392-1-git-send-email-keescook@chromium.org>

On 03/16/2018 05:25 AM, Kees Cook wrote:
> In the effort to remove all VLAs from the kernel[1], it is desirable to
> build with -Wvla. However, this warning is overly pessimistic, in that
> it is only happy with stack array sizes that are declared as constant
> expressions, and not constant values. One case of this is the evaluation
> of the max() macro which, due to its construction, ends up converting
> constant expression arguments into a constant value result. Attempts
> to adjust the behavior of max() ran afoul of version-dependent compiler
> behavior[2].

I find this commit message confusing.  VLAs have precisely defined 
semantics which differ from other arrays, and these differences can be 
observable (maybe not in the kernel, but certainly for userspace), so 
the compiler has to treat a VLA as such even if the length is a constant 
known at compile time.  (The original intent of the warning probably was 
a portability check anyway.)

If you want to catch stack frames which have unbounded size, 
-Werror=stack-usage=1000 or -Werror=vla-larger-than=1000 (with the 
constant adjusted as needed) might be the better approach.

Thanks,
Florian

  parent reply	other threads:[~2018-03-16 11:47 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-16  4:25 [PATCH v5 0/2] Remove false-positive VLAs when using max() Kees Cook
2018-03-16  4:25 ` [PATCH v5 1/2] kernel.h: Introduce const_max_t() for VLA removal Kees Cook
2018-03-16  4:25 ` [PATCH v5 2/2] Remove false-positive VLAs when using max() Kees Cook
2018-03-19 10:45   ` Andrey Ryabinin
2018-03-16 11:47 ` Florian Weimer [this message]
2018-03-16 17:29   ` [PATCH v5 0/2] " Linus Torvalds
2018-03-16 17:32     ` Florian Weimer
2018-03-16 17:44     ` David Laight
2018-03-16 20:25       ` Linus Torvalds
2018-03-16 17:55     ` Al Viro
2018-03-16 18:14       ` Al Viro
2018-03-16 19:27       ` Linus Torvalds
2018-03-16 20:03         ` Miguel Ojeda
2018-03-16 20:14           ` Linus Torvalds
2018-03-16 20:19             ` Linus Torvalds
2018-03-17  0:48             ` Miguel Ojeda
2018-03-17  1:49             ` Miguel Ojeda
2018-03-16 20:12         ` Al Viro
2018-03-16 20:15           ` Linus Torvalds
2018-03-16 20:18             ` Al Viro
2018-03-17  7:27         ` Kees Cook
2018-03-17 18:52           ` Linus Torvalds
2018-03-17 20:07             ` Kees Cook
2018-03-17 22:55               ` Josh Poimboeuf
2018-03-20 23:23               ` Linus Torvalds
2018-03-20 23:26                 ` Linus Torvalds
2018-03-21  0:05                   ` Al Viro
2018-03-22 15:01                 ` Kees Cook
2018-03-22 15:13                   ` David Laight
2018-03-22 17:04                   ` Linus Torvalds
2018-03-18 21:13             ` Rasmus Villemoes
2018-03-18 21:33               ` Linus Torvalds
2018-03-18 22:59                 ` Rasmus Villemoes
2018-03-18 23:36                   ` Linus Torvalds
2018-03-19  9:43                     ` David Laight
2018-03-19 23:29                       ` Linus Torvalds
2018-03-20  3:10                         ` Arnd Bergmann

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=ab2933a2-ca7b-eb3b-744d-bc037b1be688@redhat.com \
    --to=fweimer@redhat.com \
    --cc=David.Laight@aculab.com \
    --cc=abbotti@mev.co.uk \
    --cc=akpm@linux-foundation.org \
    --cc=jpoimboe@redhat.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=mingo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=torvalds@linux-foundation.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).