All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Kees Cook <keescook@chromium.org>,
	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: [PATCH v5 1/2] kernel.h: Introduce const_max_t() for VLA removal
Date: Thu, 15 Mar 2018 21:25:58 -0700	[thread overview]
Message-ID: <1521174359-46392-2-git-send-email-keescook@chromium.org> (raw)
In-Reply-To: <1521174359-46392-1-git-send-email-keescook@chromium.org>

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

To work around this and still gain -Wvla coverage, this patch introduces
a new macro, const_max_t(), for use in these cases of stack array size
declaration, where the constant expressions are retained. Since this means
losing the double-evaluation protections of the max() macro, this macro is
designed to explicitly fail if used on non-constant arguments.

Older compilers will fail with the unhelpful message:

    error: first argument to ‘__builtin_choose_expr’ not a constant

Newer compilers will fail with a hopefully more helpful message:

    error: call to ‘__error_non_const_arg’ declared with attribute error: const_max_t() used with non-constant expression

To gain the ability to compare differing types, the desired type must
be explicitly declared, as with the existing max_t() macro. This is
needed when comparing different enum types and to allow things like:

    int foo[const_max_t(size_t, 6, sizeof(something))];

[1] https://lkml.org/lkml/2018/3/7/621
[2] https://lkml.org/lkml/2018/3/10/170

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 include/linux/kernel.h | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 3fd291503576..e14531781568 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -820,6 +820,25 @@ static inline void ftrace_dump(enum ftrace_dump_mode oops_dump_mode) { }
 	      x, y)
 
 /**
+ * const_max_t - return maximum of two compile-time constant expressions
+ * @type: type used for evaluation
+ * @x: first compile-time constant expression
+ * @y: second compile-time constant expression
+ *
+ * This has no multi-evaluation defenses, and must only ever be used with
+ * compile-time constant expressions (for example when calculating a stack
+ * array size).
+ */
+size_t __error_non_const_arg(void) \
+__compiletime_error("const_max_t() used with non-constant expression");
+#define const_max_t(type, x, y)					\
+	__builtin_choose_expr(__builtin_constant_p(x) &&	\
+			      __builtin_constant_p(y),		\
+			      (type)(x) > (type)(y) ?		\
+				(type)(x) : (type)(y),		\
+			      __error_non_const_arg())
+
+/**
  * min3 - return minimum of three values
  * @x: first value
  * @y: second value
-- 
2.7.4

  reply	other threads:[~2018-03-16  4:25 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 ` Kees Cook [this message]
2018-03-16  4:25 ` [PATCH v5 2/2] " Kees Cook
2018-03-19 10:45   ` Andrey Ryabinin
2018-03-16 11:47 ` [PATCH v5 0/2] " Florian Weimer
2018-03-16 17:29   ` 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=1521174359-46392-2-git-send-email-keescook@chromium.org \
    --to=keescook@chromium.org \
    --cc=David.Laight@aculab.com \
    --cc=abbotti@mev.co.uk \
    --cc=akpm@linux-foundation.org \
    --cc=jpoimboe@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.