[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240708191840.335463-1-kees@kernel.org>
Date: Mon, 8 Jul 2024 12:18:35 -0700
From: Kees Cook <kees@...nel.org>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Kees Cook <kees@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Miguel Ojeda <ojeda@...nel.org>,
Marco Elver <elver@...gle.com>,
Nathan Chancellor <nathan@...nel.org>,
Hao Luo <haoluo@...gle.com>,
Przemek Kitszel <przemyslaw.kitszel@...el.com>,
Jann Horn <jannh@...gle.com>,
Tony Luck <tony.luck@...el.com>,
Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Hyeonggon Yoo <42.hyeyoo@...il.com>,
"Guilherme G. Piccoli" <gpiccoli@...lia.com>,
Mark Rutland <mark.rutland@....com>,
Jakub Kicinski <kuba@...nel.org>,
Petr Pavlu <petr.pavlu@...e.com>,
Alexander Lobakin <aleksander.lobakin@...el.com>,
Tony Ambardar <tony.ambardar@...il.com>,
linux-kernel@...r.kernel.org,
linux-mm@...ck.org,
linux-hardening@...r.kernel.org
Subject: [RFC][PATCH 1/4] compiler_types: Add integral/pointer type helper macros
Many compiler builtins (e.g. _Generic, __builtin_choose_expr) perform
integral vs pointer argument type evaluation on outputs before evaluating
the input expression. This means that all outputs must be syntactically
valid for all inputs, even if the output would be otherwise filtering
the types. For example, this will fail to build:
#define handle_int_or_ptr(x) \
_Generic((x), \
int: handle_int(x), \
int *: handle_ptr(x))
...
handle_int_or_ptr(7);
error: passing argument 1 of 'handle_ptr' makes pointer from integer without a cast [-Wint-conversion]
108 | handle_int_or_ptr(x);
| ^
| |
| int
To deal with this, provide helpers that force expressions into the
desired type, where the mismatched cases are syntactically value, but
will never actually happen:
#define handle_int_or_ptr(x) \
_Generic((x), \
int: handle_int(__force_integral_expr(x)), \
int *: handle_ptr(__force_ptr_expr(x)))
Now handle_int() only ever sees an int, and handle_ptr() only ever sees
a pointer, regardless of the input type.
Signed-off-by: Kees Cook <kees@...nel.org>
---
Cc: Nick Desaulniers <ndesaulniers@...gle.com>
Cc: Miguel Ojeda <ojeda@...nel.org>
Cc: Marco Elver <elver@...gle.com>
Cc: Nathan Chancellor <nathan@...nel.org>
Cc: Hao Luo <haoluo@...gle.com>
Cc: Przemek Kitszel <przemyslaw.kitszel@...el.com>
---
include/linux/compiler_types.h | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index f14c275950b5..7754f3b6a91f 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -450,6 +450,29 @@ struct ftrace_likely_data {
/* Are two types/vars the same type (ignoring qualifiers)? */
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
+/* Is the variable addressable? */
+#define __is_ptr_or_array(p) \
+ (__builtin_classify_type(p) == __builtin_classify_type(NULL))
+
+/* Return an array decayed to a pointer. */
+#define __decay(p) \
+ (&*__builtin_choose_expr(__is_ptr_or_array(p), p, NULL))
+
+/* Report if variable is a pointer type. */
+#define __is_ptr(p) __same_type(p, __decay(p))
+
+/* Always produce an integral expression, with specific type/vale fallback. */
+#define ___force_integral_expr(x, type, val) \
+ __builtin_choose_expr(!__is_ptr(x), (x), (type)val)
+#define __force_integral_expr(x) \
+ ___force_integral_expr(x, int, 0)
+
+/* Always produce a pointer expression, with specific type/value fallback. */
+#define ___force_ptr_expr(x, type, value) \
+ __builtin_choose_expr(__is_ptr(x), (x), &(type){ value })
+#define __force_ptr_expr(x) \
+ __builtin_choose_expr(__is_ptr(x), (x), NULL)
+
/*
* __unqual_scalar_typeof(x) - Declare an unqualified scalar type, leaving
* non-scalar types unchanged.
--
2.34.1
Powered by blists - more mailing lists