compiler.h: enable builtin overflow checkers and add fallback code
This adds wrappers for the __builtin overflow checkers present in gcc
5.1+ as well as fallback implementations for earlier compilers. It's not
that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
the same. We obviously don't want the wrappers to have different
semantics depending on $GCC_VERSION, so we also insist on that even when
using the builtins.
There are a few problems with the 'a+b < a' idiom for checking for
overflow: For signed types, it relies on undefined behaviour and is
not actually complete (it doesn't check underflow;
e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
is wrong for all types (signed and unsigned) narrower than
int. Similarly, when a and b does not have the same type, there are
subtle cases like
u32 a;
if (a + sizeof(foo) < a)
return -EOVERFLOW;
a += sizeof(foo);
where the test is always false on 64 bit platforms. Add to that that it
is not always possible to determine the types involved at a glance.
The new overflow.h is somewhat bulky, but that's mostly a result of
trying to be type-generic, complete (e.g. catching not only overflow
but also signed underflow) and not relying on undefined behaviour.
Linus is of course right [1] that for unsigned subtraction a-b, the
right way to check for overflow (underflow) is "b > a" and not
"__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
covered here, and included mostly for completeness.
So is it worth it? I think it is, if nothing else for the documentation
value of seeing
if (check_add_overflow(a, b, &d))
return -EGOAWAY;
do_stuff_with(d);
instead of the open-coded (and possibly wrong and/or incomplete and/or
UBsan-tickling)
if (a+b < a)
return -EGOAWAY;
do_stuff_with(a+b);
While gcc does recognize the 'a+b < a' idiom for testing unsigned add
overflow, it doesn't do nearly as good for unsigned multiplication
(there's also no single well-established idiom). So using
check_mul_overflow in kcalloc and friends may also make gcc generate
slightly better code.
[1] https://lkml.org/lkml/2015/11/2/658
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-07 22:36:27 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 OR MIT */
|
|
|
|
#ifndef __LINUX_OVERFLOW_H
|
|
|
|
#define __LINUX_OVERFLOW_H
|
|
|
|
|
|
|
|
#include <linux/compiler.h>
|
2020-09-13 10:29:28 +00:00
|
|
|
#include <linux/limits.h>
|
2023-02-22 20:05:32 +00:00
|
|
|
#include <linux/const.h>
|
compiler.h: enable builtin overflow checkers and add fallback code
This adds wrappers for the __builtin overflow checkers present in gcc
5.1+ as well as fallback implementations for earlier compilers. It's not
that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
the same. We obviously don't want the wrappers to have different
semantics depending on $GCC_VERSION, so we also insist on that even when
using the builtins.
There are a few problems with the 'a+b < a' idiom for checking for
overflow: For signed types, it relies on undefined behaviour and is
not actually complete (it doesn't check underflow;
e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
is wrong for all types (signed and unsigned) narrower than
int. Similarly, when a and b does not have the same type, there are
subtle cases like
u32 a;
if (a + sizeof(foo) < a)
return -EOVERFLOW;
a += sizeof(foo);
where the test is always false on 64 bit platforms. Add to that that it
is not always possible to determine the types involved at a glance.
The new overflow.h is somewhat bulky, but that's mostly a result of
trying to be type-generic, complete (e.g. catching not only overflow
but also signed underflow) and not relying on undefined behaviour.
Linus is of course right [1] that for unsigned subtraction a-b, the
right way to check for overflow (underflow) is "b > a" and not
"__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
covered here, and included mostly for completeness.
So is it worth it? I think it is, if nothing else for the documentation
value of seeing
if (check_add_overflow(a, b, &d))
return -EGOAWAY;
do_stuff_with(d);
instead of the open-coded (and possibly wrong and/or incomplete and/or
UBsan-tickling)
if (a+b < a)
return -EGOAWAY;
do_stuff_with(a+b);
While gcc does recognize the 'a+b < a' idiom for testing unsigned add
overflow, it doesn't do nearly as good for unsigned multiplication
(there's also no single well-established idiom). So using
check_mul_overflow in kcalloc and friends may also make gcc generate
slightly better code.
[1] https://lkml.org/lkml/2015/11/2/658
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-07 22:36:27 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* In the fallback code below, we need to compute the minimum and
|
|
|
|
* maximum values representable in a given type. These macros may also
|
|
|
|
* be useful elsewhere, so we provide them outside the
|
|
|
|
* COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW block.
|
|
|
|
*
|
|
|
|
* It would seem more obvious to do something like
|
|
|
|
*
|
|
|
|
* #define type_min(T) (T)(is_signed_type(T) ? (T)1 << (8*sizeof(T)-1) : 0)
|
|
|
|
* #define type_max(T) (T)(is_signed_type(T) ? ((T)1 << (8*sizeof(T)-1)) - 1 : ~(T)0)
|
|
|
|
*
|
|
|
|
* Unfortunately, the middle expressions, strictly speaking, have
|
|
|
|
* undefined behaviour, and at least some versions of gcc warn about
|
|
|
|
* the type_max expression (but not if -fsanitize=undefined is in
|
|
|
|
* effect; in that case, the warning is deferred to runtime...).
|
|
|
|
*
|
|
|
|
* The slightly excessive casting in type_min is to make sure the
|
|
|
|
* macros also produce sensible values for the exotic type _Bool. [The
|
|
|
|
* overflow checkers only almost work for _Bool, but that's
|
|
|
|
* a-feature-not-a-bug, since people shouldn't be doing arithmetic on
|
|
|
|
* _Bools. Besides, the gcc builtins don't allow _Bool* as third
|
|
|
|
* argument.]
|
|
|
|
*
|
|
|
|
* Idea stolen from
|
|
|
|
* https://mail-index.netbsd.org/tech-misc/2007/02/05/0000.html -
|
|
|
|
* credit to Christian Biere.
|
|
|
|
*/
|
|
|
|
#define is_signed_type(type) (((type)(-1)) < (type)1)
|
overflow: Introduce castable_to_type()
NOTE: This commit does not compile due to missing RHEL-specific fix-ups,
which are split out into separate Git commits following this one.
If git bisect selected this commit, run "git bisect skip" and try again.
Repeat this until it selects a commit which compiles.
Partially backport "overflow: Introduce overflows_type() and castable_to_type()"
Only backport castable_to_type() needed by i915 driver.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2160457
Upstream Status: v6.2-rc1
commit 4b21d25bf519c9487935a664886956bb18f04f6d
Author: Kees Cook <keescook@chromium.org>
AuthorDate: Mon Oct 24 23:11:25 2022 +0300
Commit: Kees Cook <keescook@chromium.org>
CommitDate: Wed Nov 2 12:39:27 2022 -0700
Implement a robust overflows_type() macro to test if a variable or
constant value would overflow another variable or type. This can be
used as a constant expression for static_assert() (which requires a
constant expression[1][2]) when used on constant values. This must be
constructed manually, since __builtin_add_overflow() does not produce
a constant expression[3].
Additionally adds castable_to_type(), similar to __same_type(), but for
checking if a constant value would overflow if cast to a given type.
Add unit tests for overflows_type(), __same_type(), and castable_to_type()
to the existing KUnit "overflow" test:
[16:03:33] ================== overflow (21 subtests) ==================
...
[16:03:33] [PASSED] overflows_type_test
[16:03:33] [PASSED] same_type_test
[16:03:33] [PASSED] castable_to_type_test
[16:03:33] ==================== [PASSED] overflow =====================
[16:03:33] ============================================================
[16:03:33] Testing complete. Ran 21 tests: passed: 21
[16:03:33] Elapsed time: 24.022s total, 0.002s configuring, 22.598s building, 0.767s running
[1] https://en.cppreference.com/w/c/language/_Static_assert
[2] C11 standard (ISO/IEC 9899:2011): 6.7.10 Static assertions
[3] https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
6.56 Built-in Functions to Perform Arithmetic with Overflow Checking
Built-in Function: bool __builtin_add_overflow (type1 a, type2 b,
Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Tom Rix <trix@redhat.com>
Cc: Daniel Latypov <dlatypov@google.com>
Cc: Vitor Massaru Iha <vitor@massaru.org>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: linux-hardening@vger.kernel.org
Cc: llvm@lists.linux.dev
Co-developed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20221024201125.1416422-1-gwan-gyeong.mun@intel.com
Signed-off-by: Mika Penttilä <mpenttil@redhat.com>
2023-06-15 09:38:52 +00:00
|
|
|
#define is_unsigned_type(type) (!is_signed_type(type))
|
compiler.h: enable builtin overflow checkers and add fallback code
This adds wrappers for the __builtin overflow checkers present in gcc
5.1+ as well as fallback implementations for earlier compilers. It's not
that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
the same. We obviously don't want the wrappers to have different
semantics depending on $GCC_VERSION, so we also insist on that even when
using the builtins.
There are a few problems with the 'a+b < a' idiom for checking for
overflow: For signed types, it relies on undefined behaviour and is
not actually complete (it doesn't check underflow;
e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
is wrong for all types (signed and unsigned) narrower than
int. Similarly, when a and b does not have the same type, there are
subtle cases like
u32 a;
if (a + sizeof(foo) < a)
return -EOVERFLOW;
a += sizeof(foo);
where the test is always false on 64 bit platforms. Add to that that it
is not always possible to determine the types involved at a glance.
The new overflow.h is somewhat bulky, but that's mostly a result of
trying to be type-generic, complete (e.g. catching not only overflow
but also signed underflow) and not relying on undefined behaviour.
Linus is of course right [1] that for unsigned subtraction a-b, the
right way to check for overflow (underflow) is "b > a" and not
"__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
covered here, and included mostly for completeness.
So is it worth it? I think it is, if nothing else for the documentation
value of seeing
if (check_add_overflow(a, b, &d))
return -EGOAWAY;
do_stuff_with(d);
instead of the open-coded (and possibly wrong and/or incomplete and/or
UBsan-tickling)
if (a+b < a)
return -EGOAWAY;
do_stuff_with(a+b);
While gcc does recognize the 'a+b < a' idiom for testing unsigned add
overflow, it doesn't do nearly as good for unsigned multiplication
(there's also no single well-established idiom). So using
check_mul_overflow in kcalloc and friends may also make gcc generate
slightly better code.
[1] https://lkml.org/lkml/2015/11/2/658
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-07 22:36:27 +00:00
|
|
|
#define __type_half_max(type) ((type)1 << (8*sizeof(type) - 1 - is_signed_type(type)))
|
|
|
|
#define type_max(T) ((T)((__type_half_max(T) - 1) + __type_half_max(T)))
|
|
|
|
#define type_min(T) ((T)((T)-type_max(T)-(T)1))
|
|
|
|
|
2019-03-17 10:11:14 +00:00
|
|
|
/*
|
|
|
|
* Avoids triggering -Wtype-limits compilation warning,
|
|
|
|
* while using unsigned data types to check a < 0.
|
|
|
|
*/
|
|
|
|
#define is_non_negative(a) ((a) > 0 || (a) == 0)
|
|
|
|
#define is_negative(a) (!(is_non_negative(a)))
|
compiler.h: enable builtin overflow checkers and add fallback code
This adds wrappers for the __builtin overflow checkers present in gcc
5.1+ as well as fallback implementations for earlier compilers. It's not
that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
the same. We obviously don't want the wrappers to have different
semantics depending on $GCC_VERSION, so we also insist on that even when
using the builtins.
There are a few problems with the 'a+b < a' idiom for checking for
overflow: For signed types, it relies on undefined behaviour and is
not actually complete (it doesn't check underflow;
e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
is wrong for all types (signed and unsigned) narrower than
int. Similarly, when a and b does not have the same type, there are
subtle cases like
u32 a;
if (a + sizeof(foo) < a)
return -EOVERFLOW;
a += sizeof(foo);
where the test is always false on 64 bit platforms. Add to that that it
is not always possible to determine the types involved at a glance.
The new overflow.h is somewhat bulky, but that's mostly a result of
trying to be type-generic, complete (e.g. catching not only overflow
but also signed underflow) and not relying on undefined behaviour.
Linus is of course right [1] that for unsigned subtraction a-b, the
right way to check for overflow (underflow) is "b > a" and not
"__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
covered here, and included mostly for completeness.
So is it worth it? I think it is, if nothing else for the documentation
value of seeing
if (check_add_overflow(a, b, &d))
return -EGOAWAY;
do_stuff_with(d);
instead of the open-coded (and possibly wrong and/or incomplete and/or
UBsan-tickling)
if (a+b < a)
return -EGOAWAY;
do_stuff_with(a+b);
While gcc does recognize the 'a+b < a' idiom for testing unsigned add
overflow, it doesn't do nearly as good for unsigned multiplication
(there's also no single well-established idiom). So using
check_mul_overflow in kcalloc and friends may also make gcc generate
slightly better code.
[1] https://lkml.org/lkml/2015/11/2/658
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-07 22:36:27 +00:00
|
|
|
|
2020-08-12 21:47:03 +00:00
|
|
|
/*
|
|
|
|
* Allows for effectively applying __must_check to a macro so we can have
|
|
|
|
* both the type-agnostic benefits of the macros while also being able to
|
|
|
|
* enforce that the return value is, in fact, checked.
|
|
|
|
*/
|
|
|
|
static inline bool __must_check __must_check_overflow(bool overflow)
|
|
|
|
{
|
|
|
|
return unlikely(overflow);
|
|
|
|
}
|
|
|
|
|
compiler.h: enable builtin overflow checkers and add fallback code
This adds wrappers for the __builtin overflow checkers present in gcc
5.1+ as well as fallback implementations for earlier compilers. It's not
that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
the same. We obviously don't want the wrappers to have different
semantics depending on $GCC_VERSION, so we also insist on that even when
using the builtins.
There are a few problems with the 'a+b < a' idiom for checking for
overflow: For signed types, it relies on undefined behaviour and is
not actually complete (it doesn't check underflow;
e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
is wrong for all types (signed and unsigned) narrower than
int. Similarly, when a and b does not have the same type, there are
subtle cases like
u32 a;
if (a + sizeof(foo) < a)
return -EOVERFLOW;
a += sizeof(foo);
where the test is always false on 64 bit platforms. Add to that that it
is not always possible to determine the types involved at a glance.
The new overflow.h is somewhat bulky, but that's mostly a result of
trying to be type-generic, complete (e.g. catching not only overflow
but also signed underflow) and not relying on undefined behaviour.
Linus is of course right [1] that for unsigned subtraction a-b, the
right way to check for overflow (underflow) is "b > a" and not
"__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
covered here, and included mostly for completeness.
So is it worth it? I think it is, if nothing else for the documentation
value of seeing
if (check_add_overflow(a, b, &d))
return -EGOAWAY;
do_stuff_with(d);
instead of the open-coded (and possibly wrong and/or incomplete and/or
UBsan-tickling)
if (a+b < a)
return -EGOAWAY;
do_stuff_with(a+b);
While gcc does recognize the 'a+b < a' idiom for testing unsigned add
overflow, it doesn't do nearly as good for unsigned multiplication
(there's also no single well-established idiom). So using
check_mul_overflow in kcalloc and friends may also make gcc generate
slightly better code.
[1] https://lkml.org/lkml/2015/11/2/658
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-07 22:36:27 +00:00
|
|
|
#ifdef COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW
|
|
|
|
/*
|
|
|
|
* For simplicity and code hygiene, the fallback code below insists on
|
|
|
|
* a, b and *d having the same type (similar to the min() and max()
|
|
|
|
* macros), whereas gcc's type-generic overflow checkers accept
|
|
|
|
* different types. Hence we don't just make check_add_overflow an
|
|
|
|
* alias for __builtin_add_overflow, but add type checks similar to
|
|
|
|
* below.
|
|
|
|
*/
|
2020-08-12 21:47:03 +00:00
|
|
|
#define check_add_overflow(a, b, d) __must_check_overflow(({ \
|
compiler.h: enable builtin overflow checkers and add fallback code
This adds wrappers for the __builtin overflow checkers present in gcc
5.1+ as well as fallback implementations for earlier compilers. It's not
that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
the same. We obviously don't want the wrappers to have different
semantics depending on $GCC_VERSION, so we also insist on that even when
using the builtins.
There are a few problems with the 'a+b < a' idiom for checking for
overflow: For signed types, it relies on undefined behaviour and is
not actually complete (it doesn't check underflow;
e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
is wrong for all types (signed and unsigned) narrower than
int. Similarly, when a and b does not have the same type, there are
subtle cases like
u32 a;
if (a + sizeof(foo) < a)
return -EOVERFLOW;
a += sizeof(foo);
where the test is always false on 64 bit platforms. Add to that that it
is not always possible to determine the types involved at a glance.
The new overflow.h is somewhat bulky, but that's mostly a result of
trying to be type-generic, complete (e.g. catching not only overflow
but also signed underflow) and not relying on undefined behaviour.
Linus is of course right [1] that for unsigned subtraction a-b, the
right way to check for overflow (underflow) is "b > a" and not
"__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
covered here, and included mostly for completeness.
So is it worth it? I think it is, if nothing else for the documentation
value of seeing
if (check_add_overflow(a, b, &d))
return -EGOAWAY;
do_stuff_with(d);
instead of the open-coded (and possibly wrong and/or incomplete and/or
UBsan-tickling)
if (a+b < a)
return -EGOAWAY;
do_stuff_with(a+b);
While gcc does recognize the 'a+b < a' idiom for testing unsigned add
overflow, it doesn't do nearly as good for unsigned multiplication
(there's also no single well-established idiom). So using
check_mul_overflow in kcalloc and friends may also make gcc generate
slightly better code.
[1] https://lkml.org/lkml/2015/11/2/658
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-07 22:36:27 +00:00
|
|
|
typeof(a) __a = (a); \
|
|
|
|
typeof(b) __b = (b); \
|
|
|
|
typeof(d) __d = (d); \
|
|
|
|
(void) (&__a == &__b); \
|
|
|
|
(void) (&__a == __d); \
|
|
|
|
__builtin_add_overflow(__a, __b, __d); \
|
2020-08-12 21:47:03 +00:00
|
|
|
}))
|
compiler.h: enable builtin overflow checkers and add fallback code
This adds wrappers for the __builtin overflow checkers present in gcc
5.1+ as well as fallback implementations for earlier compilers. It's not
that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
the same. We obviously don't want the wrappers to have different
semantics depending on $GCC_VERSION, so we also insist on that even when
using the builtins.
There are a few problems with the 'a+b < a' idiom for checking for
overflow: For signed types, it relies on undefined behaviour and is
not actually complete (it doesn't check underflow;
e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
is wrong for all types (signed and unsigned) narrower than
int. Similarly, when a and b does not have the same type, there are
subtle cases like
u32 a;
if (a + sizeof(foo) < a)
return -EOVERFLOW;
a += sizeof(foo);
where the test is always false on 64 bit platforms. Add to that that it
is not always possible to determine the types involved at a glance.
The new overflow.h is somewhat bulky, but that's mostly a result of
trying to be type-generic, complete (e.g. catching not only overflow
but also signed underflow) and not relying on undefined behaviour.
Linus is of course right [1] that for unsigned subtraction a-b, the
right way to check for overflow (underflow) is "b > a" and not
"__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
covered here, and included mostly for completeness.
So is it worth it? I think it is, if nothing else for the documentation
value of seeing
if (check_add_overflow(a, b, &d))
return -EGOAWAY;
do_stuff_with(d);
instead of the open-coded (and possibly wrong and/or incomplete and/or
UBsan-tickling)
if (a+b < a)
return -EGOAWAY;
do_stuff_with(a+b);
While gcc does recognize the 'a+b < a' idiom for testing unsigned add
overflow, it doesn't do nearly as good for unsigned multiplication
(there's also no single well-established idiom). So using
check_mul_overflow in kcalloc and friends may also make gcc generate
slightly better code.
[1] https://lkml.org/lkml/2015/11/2/658
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-07 22:36:27 +00:00
|
|
|
|
2020-08-12 21:47:03 +00:00
|
|
|
#define check_sub_overflow(a, b, d) __must_check_overflow(({ \
|
compiler.h: enable builtin overflow checkers and add fallback code
This adds wrappers for the __builtin overflow checkers present in gcc
5.1+ as well as fallback implementations for earlier compilers. It's not
that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
the same. We obviously don't want the wrappers to have different
semantics depending on $GCC_VERSION, so we also insist on that even when
using the builtins.
There are a few problems with the 'a+b < a' idiom for checking for
overflow: For signed types, it relies on undefined behaviour and is
not actually complete (it doesn't check underflow;
e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
is wrong for all types (signed and unsigned) narrower than
int. Similarly, when a and b does not have the same type, there are
subtle cases like
u32 a;
if (a + sizeof(foo) < a)
return -EOVERFLOW;
a += sizeof(foo);
where the test is always false on 64 bit platforms. Add to that that it
is not always possible to determine the types involved at a glance.
The new overflow.h is somewhat bulky, but that's mostly a result of
trying to be type-generic, complete (e.g. catching not only overflow
but also signed underflow) and not relying on undefined behaviour.
Linus is of course right [1] that for unsigned subtraction a-b, the
right way to check for overflow (underflow) is "b > a" and not
"__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
covered here, and included mostly for completeness.
So is it worth it? I think it is, if nothing else for the documentation
value of seeing
if (check_add_overflow(a, b, &d))
return -EGOAWAY;
do_stuff_with(d);
instead of the open-coded (and possibly wrong and/or incomplete and/or
UBsan-tickling)
if (a+b < a)
return -EGOAWAY;
do_stuff_with(a+b);
While gcc does recognize the 'a+b < a' idiom for testing unsigned add
overflow, it doesn't do nearly as good for unsigned multiplication
(there's also no single well-established idiom). So using
check_mul_overflow in kcalloc and friends may also make gcc generate
slightly better code.
[1] https://lkml.org/lkml/2015/11/2/658
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-07 22:36:27 +00:00
|
|
|
typeof(a) __a = (a); \
|
|
|
|
typeof(b) __b = (b); \
|
|
|
|
typeof(d) __d = (d); \
|
|
|
|
(void) (&__a == &__b); \
|
|
|
|
(void) (&__a == __d); \
|
|
|
|
__builtin_sub_overflow(__a, __b, __d); \
|
2020-08-12 21:47:03 +00:00
|
|
|
}))
|
compiler.h: enable builtin overflow checkers and add fallback code
This adds wrappers for the __builtin overflow checkers present in gcc
5.1+ as well as fallback implementations for earlier compilers. It's not
that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
the same. We obviously don't want the wrappers to have different
semantics depending on $GCC_VERSION, so we also insist on that even when
using the builtins.
There are a few problems with the 'a+b < a' idiom for checking for
overflow: For signed types, it relies on undefined behaviour and is
not actually complete (it doesn't check underflow;
e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
is wrong for all types (signed and unsigned) narrower than
int. Similarly, when a and b does not have the same type, there are
subtle cases like
u32 a;
if (a + sizeof(foo) < a)
return -EOVERFLOW;
a += sizeof(foo);
where the test is always false on 64 bit platforms. Add to that that it
is not always possible to determine the types involved at a glance.
The new overflow.h is somewhat bulky, but that's mostly a result of
trying to be type-generic, complete (e.g. catching not only overflow
but also signed underflow) and not relying on undefined behaviour.
Linus is of course right [1] that for unsigned subtraction a-b, the
right way to check for overflow (underflow) is "b > a" and not
"__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
covered here, and included mostly for completeness.
So is it worth it? I think it is, if nothing else for the documentation
value of seeing
if (check_add_overflow(a, b, &d))
return -EGOAWAY;
do_stuff_with(d);
instead of the open-coded (and possibly wrong and/or incomplete and/or
UBsan-tickling)
if (a+b < a)
return -EGOAWAY;
do_stuff_with(a+b);
While gcc does recognize the 'a+b < a' idiom for testing unsigned add
overflow, it doesn't do nearly as good for unsigned multiplication
(there's also no single well-established idiom). So using
check_mul_overflow in kcalloc and friends may also make gcc generate
slightly better code.
[1] https://lkml.org/lkml/2015/11/2/658
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-07 22:36:27 +00:00
|
|
|
|
2020-08-12 21:47:03 +00:00
|
|
|
#define check_mul_overflow(a, b, d) __must_check_overflow(({ \
|
compiler.h: enable builtin overflow checkers and add fallback code
This adds wrappers for the __builtin overflow checkers present in gcc
5.1+ as well as fallback implementations for earlier compilers. It's not
that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
the same. We obviously don't want the wrappers to have different
semantics depending on $GCC_VERSION, so we also insist on that even when
using the builtins.
There are a few problems with the 'a+b < a' idiom for checking for
overflow: For signed types, it relies on undefined behaviour and is
not actually complete (it doesn't check underflow;
e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
is wrong for all types (signed and unsigned) narrower than
int. Similarly, when a and b does not have the same type, there are
subtle cases like
u32 a;
if (a + sizeof(foo) < a)
return -EOVERFLOW;
a += sizeof(foo);
where the test is always false on 64 bit platforms. Add to that that it
is not always possible to determine the types involved at a glance.
The new overflow.h is somewhat bulky, but that's mostly a result of
trying to be type-generic, complete (e.g. catching not only overflow
but also signed underflow) and not relying on undefined behaviour.
Linus is of course right [1] that for unsigned subtraction a-b, the
right way to check for overflow (underflow) is "b > a" and not
"__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
covered here, and included mostly for completeness.
So is it worth it? I think it is, if nothing else for the documentation
value of seeing
if (check_add_overflow(a, b, &d))
return -EGOAWAY;
do_stuff_with(d);
instead of the open-coded (and possibly wrong and/or incomplete and/or
UBsan-tickling)
if (a+b < a)
return -EGOAWAY;
do_stuff_with(a+b);
While gcc does recognize the 'a+b < a' idiom for testing unsigned add
overflow, it doesn't do nearly as good for unsigned multiplication
(there's also no single well-established idiom). So using
check_mul_overflow in kcalloc and friends may also make gcc generate
slightly better code.
[1] https://lkml.org/lkml/2015/11/2/658
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-07 22:36:27 +00:00
|
|
|
typeof(a) __a = (a); \
|
|
|
|
typeof(b) __b = (b); \
|
|
|
|
typeof(d) __d = (d); \
|
|
|
|
(void) (&__a == &__b); \
|
|
|
|
(void) (&__a == __d); \
|
|
|
|
__builtin_mul_overflow(__a, __b, __d); \
|
2020-08-12 21:47:03 +00:00
|
|
|
}))
|
compiler.h: enable builtin overflow checkers and add fallback code
This adds wrappers for the __builtin overflow checkers present in gcc
5.1+ as well as fallback implementations for earlier compilers. It's not
that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
the same. We obviously don't want the wrappers to have different
semantics depending on $GCC_VERSION, so we also insist on that even when
using the builtins.
There are a few problems with the 'a+b < a' idiom for checking for
overflow: For signed types, it relies on undefined behaviour and is
not actually complete (it doesn't check underflow;
e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
is wrong for all types (signed and unsigned) narrower than
int. Similarly, when a and b does not have the same type, there are
subtle cases like
u32 a;
if (a + sizeof(foo) < a)
return -EOVERFLOW;
a += sizeof(foo);
where the test is always false on 64 bit platforms. Add to that that it
is not always possible to determine the types involved at a glance.
The new overflow.h is somewhat bulky, but that's mostly a result of
trying to be type-generic, complete (e.g. catching not only overflow
but also signed underflow) and not relying on undefined behaviour.
Linus is of course right [1] that for unsigned subtraction a-b, the
right way to check for overflow (underflow) is "b > a" and not
"__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
covered here, and included mostly for completeness.
So is it worth it? I think it is, if nothing else for the documentation
value of seeing
if (check_add_overflow(a, b, &d))
return -EGOAWAY;
do_stuff_with(d);
instead of the open-coded (and possibly wrong and/or incomplete and/or
UBsan-tickling)
if (a+b < a)
return -EGOAWAY;
do_stuff_with(a+b);
While gcc does recognize the 'a+b < a' idiom for testing unsigned add
overflow, it doesn't do nearly as good for unsigned multiplication
(there's also no single well-established idiom). So using
check_mul_overflow in kcalloc and friends may also make gcc generate
slightly better code.
[1] https://lkml.org/lkml/2015/11/2/658
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-07 22:36:27 +00:00
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
|
|
|
|
/* Checking for unsigned overflow is relatively easy without causing UB. */
|
|
|
|
#define __unsigned_add_overflow(a, b, d) ({ \
|
|
|
|
typeof(a) __a = (a); \
|
|
|
|
typeof(b) __b = (b); \
|
|
|
|
typeof(d) __d = (d); \
|
|
|
|
(void) (&__a == &__b); \
|
|
|
|
(void) (&__a == __d); \
|
|
|
|
*__d = __a + __b; \
|
|
|
|
*__d < __a; \
|
|
|
|
})
|
|
|
|
#define __unsigned_sub_overflow(a, b, d) ({ \
|
|
|
|
typeof(a) __a = (a); \
|
|
|
|
typeof(b) __b = (b); \
|
|
|
|
typeof(d) __d = (d); \
|
|
|
|
(void) (&__a == &__b); \
|
|
|
|
(void) (&__a == __d); \
|
|
|
|
*__d = __a - __b; \
|
|
|
|
__a < __b; \
|
|
|
|
})
|
|
|
|
/*
|
|
|
|
* If one of a or b is a compile-time constant, this avoids a division.
|
|
|
|
*/
|
|
|
|
#define __unsigned_mul_overflow(a, b, d) ({ \
|
|
|
|
typeof(a) __a = (a); \
|
|
|
|
typeof(b) __b = (b); \
|
|
|
|
typeof(d) __d = (d); \
|
|
|
|
(void) (&__a == &__b); \
|
|
|
|
(void) (&__a == __d); \
|
|
|
|
*__d = __a * __b; \
|
|
|
|
__builtin_constant_p(__b) ? \
|
|
|
|
__b > 0 && __a > type_max(typeof(__a)) / __b : \
|
|
|
|
__a > 0 && __b > type_max(typeof(__b)) / __a; \
|
|
|
|
})
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For signed types, detecting overflow is much harder, especially if
|
|
|
|
* we want to avoid UB. But the interface of these macros is such that
|
|
|
|
* we must provide a result in *d, and in fact we must produce the
|
|
|
|
* result promised by gcc's builtins, which is simply the possibly
|
|
|
|
* wrapped-around value. Fortunately, we can just formally do the
|
|
|
|
* operations in the widest relevant unsigned type (u64) and then
|
|
|
|
* truncate the result - gcc is smart enough to generate the same code
|
|
|
|
* with and without the (u64) casts.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Adding two signed integers can overflow only if they have the same
|
|
|
|
* sign, and overflow has happened iff the result has the opposite
|
|
|
|
* sign.
|
|
|
|
*/
|
|
|
|
#define __signed_add_overflow(a, b, d) ({ \
|
|
|
|
typeof(a) __a = (a); \
|
|
|
|
typeof(b) __b = (b); \
|
|
|
|
typeof(d) __d = (d); \
|
|
|
|
(void) (&__a == &__b); \
|
|
|
|
(void) (&__a == __d); \
|
|
|
|
*__d = (u64)__a + (u64)__b; \
|
|
|
|
(((~(__a ^ __b)) & (*__d ^ __a)) \
|
|
|
|
& type_min(typeof(__a))) != 0; \
|
|
|
|
})
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Subtraction is similar, except that overflow can now happen only
|
|
|
|
* when the signs are opposite. In this case, overflow has happened if
|
|
|
|
* the result has the opposite sign of a.
|
|
|
|
*/
|
|
|
|
#define __signed_sub_overflow(a, b, d) ({ \
|
|
|
|
typeof(a) __a = (a); \
|
|
|
|
typeof(b) __b = (b); \
|
|
|
|
typeof(d) __d = (d); \
|
|
|
|
(void) (&__a == &__b); \
|
|
|
|
(void) (&__a == __d); \
|
|
|
|
*__d = (u64)__a - (u64)__b; \
|
|
|
|
((((__a ^ __b)) & (*__d ^ __a)) \
|
|
|
|
& type_min(typeof(__a))) != 0; \
|
|
|
|
})
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Signed multiplication is rather hard. gcc always follows C99, so
|
|
|
|
* division is truncated towards 0. This means that we can write the
|
|
|
|
* overflow check like this:
|
|
|
|
*
|
|
|
|
* (a > 0 && (b > MAX/a || b < MIN/a)) ||
|
|
|
|
* (a < -1 && (b > MIN/a || b < MAX/a) ||
|
|
|
|
* (a == -1 && b == MIN)
|
|
|
|
*
|
|
|
|
* The redundant casts of -1 are to silence an annoying -Wtype-limits
|
|
|
|
* (included in -Wextra) warning: When the type is u8 or u16, the
|
|
|
|
* __b_c_e in check_mul_overflow obviously selects
|
|
|
|
* __unsigned_mul_overflow, but unfortunately gcc still parses this
|
|
|
|
* code and warns about the limited range of __b.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define __signed_mul_overflow(a, b, d) ({ \
|
|
|
|
typeof(a) __a = (a); \
|
|
|
|
typeof(b) __b = (b); \
|
|
|
|
typeof(d) __d = (d); \
|
|
|
|
typeof(a) __tmax = type_max(typeof(a)); \
|
|
|
|
typeof(a) __tmin = type_min(typeof(a)); \
|
|
|
|
(void) (&__a == &__b); \
|
|
|
|
(void) (&__a == __d); \
|
|
|
|
*__d = (u64)__a * (u64)__b; \
|
|
|
|
(__b > 0 && (__a > __tmax/__b || __a < __tmin/__b)) || \
|
|
|
|
(__b < (typeof(__b))-1 && (__a > __tmin/__b || __a < __tmax/__b)) || \
|
|
|
|
(__b == (typeof(__b))-1 && __a == __tmin); \
|
|
|
|
})
|
|
|
|
|
|
|
|
|
2020-08-12 21:47:03 +00:00
|
|
|
#define check_add_overflow(a, b, d) __must_check_overflow( \
|
compiler.h: enable builtin overflow checkers and add fallback code
This adds wrappers for the __builtin overflow checkers present in gcc
5.1+ as well as fallback implementations for earlier compilers. It's not
that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
the same. We obviously don't want the wrappers to have different
semantics depending on $GCC_VERSION, so we also insist on that even when
using the builtins.
There are a few problems with the 'a+b < a' idiom for checking for
overflow: For signed types, it relies on undefined behaviour and is
not actually complete (it doesn't check underflow;
e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
is wrong for all types (signed and unsigned) narrower than
int. Similarly, when a and b does not have the same type, there are
subtle cases like
u32 a;
if (a + sizeof(foo) < a)
return -EOVERFLOW;
a += sizeof(foo);
where the test is always false on 64 bit platforms. Add to that that it
is not always possible to determine the types involved at a glance.
The new overflow.h is somewhat bulky, but that's mostly a result of
trying to be type-generic, complete (e.g. catching not only overflow
but also signed underflow) and not relying on undefined behaviour.
Linus is of course right [1] that for unsigned subtraction a-b, the
right way to check for overflow (underflow) is "b > a" and not
"__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
covered here, and included mostly for completeness.
So is it worth it? I think it is, if nothing else for the documentation
value of seeing
if (check_add_overflow(a, b, &d))
return -EGOAWAY;
do_stuff_with(d);
instead of the open-coded (and possibly wrong and/or incomplete and/or
UBsan-tickling)
if (a+b < a)
return -EGOAWAY;
do_stuff_with(a+b);
While gcc does recognize the 'a+b < a' idiom for testing unsigned add
overflow, it doesn't do nearly as good for unsigned multiplication
(there's also no single well-established idiom). So using
check_mul_overflow in kcalloc and friends may also make gcc generate
slightly better code.
[1] https://lkml.org/lkml/2015/11/2/658
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-07 22:36:27 +00:00
|
|
|
__builtin_choose_expr(is_signed_type(typeof(a)), \
|
|
|
|
__signed_add_overflow(a, b, d), \
|
2020-08-12 21:47:03 +00:00
|
|
|
__unsigned_add_overflow(a, b, d)))
|
compiler.h: enable builtin overflow checkers and add fallback code
This adds wrappers for the __builtin overflow checkers present in gcc
5.1+ as well as fallback implementations for earlier compilers. It's not
that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
the same. We obviously don't want the wrappers to have different
semantics depending on $GCC_VERSION, so we also insist on that even when
using the builtins.
There are a few problems with the 'a+b < a' idiom for checking for
overflow: For signed types, it relies on undefined behaviour and is
not actually complete (it doesn't check underflow;
e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
is wrong for all types (signed and unsigned) narrower than
int. Similarly, when a and b does not have the same type, there are
subtle cases like
u32 a;
if (a + sizeof(foo) < a)
return -EOVERFLOW;
a += sizeof(foo);
where the test is always false on 64 bit platforms. Add to that that it
is not always possible to determine the types involved at a glance.
The new overflow.h is somewhat bulky, but that's mostly a result of
trying to be type-generic, complete (e.g. catching not only overflow
but also signed underflow) and not relying on undefined behaviour.
Linus is of course right [1] that for unsigned subtraction a-b, the
right way to check for overflow (underflow) is "b > a" and not
"__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
covered here, and included mostly for completeness.
So is it worth it? I think it is, if nothing else for the documentation
value of seeing
if (check_add_overflow(a, b, &d))
return -EGOAWAY;
do_stuff_with(d);
instead of the open-coded (and possibly wrong and/or incomplete and/or
UBsan-tickling)
if (a+b < a)
return -EGOAWAY;
do_stuff_with(a+b);
While gcc does recognize the 'a+b < a' idiom for testing unsigned add
overflow, it doesn't do nearly as good for unsigned multiplication
(there's also no single well-established idiom). So using
check_mul_overflow in kcalloc and friends may also make gcc generate
slightly better code.
[1] https://lkml.org/lkml/2015/11/2/658
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-07 22:36:27 +00:00
|
|
|
|
2020-08-12 21:47:03 +00:00
|
|
|
#define check_sub_overflow(a, b, d) __must_check_overflow( \
|
compiler.h: enable builtin overflow checkers and add fallback code
This adds wrappers for the __builtin overflow checkers present in gcc
5.1+ as well as fallback implementations for earlier compilers. It's not
that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
the same. We obviously don't want the wrappers to have different
semantics depending on $GCC_VERSION, so we also insist on that even when
using the builtins.
There are a few problems with the 'a+b < a' idiom for checking for
overflow: For signed types, it relies on undefined behaviour and is
not actually complete (it doesn't check underflow;
e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
is wrong for all types (signed and unsigned) narrower than
int. Similarly, when a and b does not have the same type, there are
subtle cases like
u32 a;
if (a + sizeof(foo) < a)
return -EOVERFLOW;
a += sizeof(foo);
where the test is always false on 64 bit platforms. Add to that that it
is not always possible to determine the types involved at a glance.
The new overflow.h is somewhat bulky, but that's mostly a result of
trying to be type-generic, complete (e.g. catching not only overflow
but also signed underflow) and not relying on undefined behaviour.
Linus is of course right [1] that for unsigned subtraction a-b, the
right way to check for overflow (underflow) is "b > a" and not
"__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
covered here, and included mostly for completeness.
So is it worth it? I think it is, if nothing else for the documentation
value of seeing
if (check_add_overflow(a, b, &d))
return -EGOAWAY;
do_stuff_with(d);
instead of the open-coded (and possibly wrong and/or incomplete and/or
UBsan-tickling)
if (a+b < a)
return -EGOAWAY;
do_stuff_with(a+b);
While gcc does recognize the 'a+b < a' idiom for testing unsigned add
overflow, it doesn't do nearly as good for unsigned multiplication
(there's also no single well-established idiom). So using
check_mul_overflow in kcalloc and friends may also make gcc generate
slightly better code.
[1] https://lkml.org/lkml/2015/11/2/658
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-07 22:36:27 +00:00
|
|
|
__builtin_choose_expr(is_signed_type(typeof(a)), \
|
|
|
|
__signed_sub_overflow(a, b, d), \
|
2020-08-12 21:47:03 +00:00
|
|
|
__unsigned_sub_overflow(a, b, d)))
|
compiler.h: enable builtin overflow checkers and add fallback code
This adds wrappers for the __builtin overflow checkers present in gcc
5.1+ as well as fallback implementations for earlier compilers. It's not
that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
the same. We obviously don't want the wrappers to have different
semantics depending on $GCC_VERSION, so we also insist on that even when
using the builtins.
There are a few problems with the 'a+b < a' idiom for checking for
overflow: For signed types, it relies on undefined behaviour and is
not actually complete (it doesn't check underflow;
e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
is wrong for all types (signed and unsigned) narrower than
int. Similarly, when a and b does not have the same type, there are
subtle cases like
u32 a;
if (a + sizeof(foo) < a)
return -EOVERFLOW;
a += sizeof(foo);
where the test is always false on 64 bit platforms. Add to that that it
is not always possible to determine the types involved at a glance.
The new overflow.h is somewhat bulky, but that's mostly a result of
trying to be type-generic, complete (e.g. catching not only overflow
but also signed underflow) and not relying on undefined behaviour.
Linus is of course right [1] that for unsigned subtraction a-b, the
right way to check for overflow (underflow) is "b > a" and not
"__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
covered here, and included mostly for completeness.
So is it worth it? I think it is, if nothing else for the documentation
value of seeing
if (check_add_overflow(a, b, &d))
return -EGOAWAY;
do_stuff_with(d);
instead of the open-coded (and possibly wrong and/or incomplete and/or
UBsan-tickling)
if (a+b < a)
return -EGOAWAY;
do_stuff_with(a+b);
While gcc does recognize the 'a+b < a' idiom for testing unsigned add
overflow, it doesn't do nearly as good for unsigned multiplication
(there's also no single well-established idiom). So using
check_mul_overflow in kcalloc and friends may also make gcc generate
slightly better code.
[1] https://lkml.org/lkml/2015/11/2/658
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-07 22:36:27 +00:00
|
|
|
|
2020-08-12 21:47:03 +00:00
|
|
|
#define check_mul_overflow(a, b, d) __must_check_overflow( \
|
compiler.h: enable builtin overflow checkers and add fallback code
This adds wrappers for the __builtin overflow checkers present in gcc
5.1+ as well as fallback implementations for earlier compilers. It's not
that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
the same. We obviously don't want the wrappers to have different
semantics depending on $GCC_VERSION, so we also insist on that even when
using the builtins.
There are a few problems with the 'a+b < a' idiom for checking for
overflow: For signed types, it relies on undefined behaviour and is
not actually complete (it doesn't check underflow;
e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
is wrong for all types (signed and unsigned) narrower than
int. Similarly, when a and b does not have the same type, there are
subtle cases like
u32 a;
if (a + sizeof(foo) < a)
return -EOVERFLOW;
a += sizeof(foo);
where the test is always false on 64 bit platforms. Add to that that it
is not always possible to determine the types involved at a glance.
The new overflow.h is somewhat bulky, but that's mostly a result of
trying to be type-generic, complete (e.g. catching not only overflow
but also signed underflow) and not relying on undefined behaviour.
Linus is of course right [1] that for unsigned subtraction a-b, the
right way to check for overflow (underflow) is "b > a" and not
"__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
covered here, and included mostly for completeness.
So is it worth it? I think it is, if nothing else for the documentation
value of seeing
if (check_add_overflow(a, b, &d))
return -EGOAWAY;
do_stuff_with(d);
instead of the open-coded (and possibly wrong and/or incomplete and/or
UBsan-tickling)
if (a+b < a)
return -EGOAWAY;
do_stuff_with(a+b);
While gcc does recognize the 'a+b < a' idiom for testing unsigned add
overflow, it doesn't do nearly as good for unsigned multiplication
(there's also no single well-established idiom). So using
check_mul_overflow in kcalloc and friends may also make gcc generate
slightly better code.
[1] https://lkml.org/lkml/2015/11/2/658
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-07 22:36:27 +00:00
|
|
|
__builtin_choose_expr(is_signed_type(typeof(a)), \
|
|
|
|
__signed_mul_overflow(a, b, d), \
|
2020-08-12 21:47:03 +00:00
|
|
|
__unsigned_mul_overflow(a, b, d)))
|
compiler.h: enable builtin overflow checkers and add fallback code
This adds wrappers for the __builtin overflow checkers present in gcc
5.1+ as well as fallback implementations for earlier compilers. It's not
that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
the same. We obviously don't want the wrappers to have different
semantics depending on $GCC_VERSION, so we also insist on that even when
using the builtins.
There are a few problems with the 'a+b < a' idiom for checking for
overflow: For signed types, it relies on undefined behaviour and is
not actually complete (it doesn't check underflow;
e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
is wrong for all types (signed and unsigned) narrower than
int. Similarly, when a and b does not have the same type, there are
subtle cases like
u32 a;
if (a + sizeof(foo) < a)
return -EOVERFLOW;
a += sizeof(foo);
where the test is always false on 64 bit platforms. Add to that that it
is not always possible to determine the types involved at a glance.
The new overflow.h is somewhat bulky, but that's mostly a result of
trying to be type-generic, complete (e.g. catching not only overflow
but also signed underflow) and not relying on undefined behaviour.
Linus is of course right [1] that for unsigned subtraction a-b, the
right way to check for overflow (underflow) is "b > a" and not
"__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
covered here, and included mostly for completeness.
So is it worth it? I think it is, if nothing else for the documentation
value of seeing
if (check_add_overflow(a, b, &d))
return -EGOAWAY;
do_stuff_with(d);
instead of the open-coded (and possibly wrong and/or incomplete and/or
UBsan-tickling)
if (a+b < a)
return -EGOAWAY;
do_stuff_with(a+b);
While gcc does recognize the 'a+b < a' idiom for testing unsigned add
overflow, it doesn't do nearly as good for unsigned multiplication
(there's also no single well-established idiom). So using
check_mul_overflow in kcalloc and friends may also make gcc generate
slightly better code.
[1] https://lkml.org/lkml/2015/11/2/658
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-07 22:36:27 +00:00
|
|
|
|
|
|
|
#endif /* COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW */
|
|
|
|
|
2018-08-01 21:25:39 +00:00
|
|
|
/** check_shl_overflow() - Calculate a left-shifted value and check overflow
|
|
|
|
*
|
|
|
|
* @a: Value to be shifted
|
|
|
|
* @s: How many bits left to shift
|
|
|
|
* @d: Pointer to where to store the result
|
|
|
|
*
|
|
|
|
* Computes *@d = (@a << @s)
|
|
|
|
*
|
|
|
|
* Returns true if '*d' cannot hold the result or when 'a << s' doesn't
|
|
|
|
* make sense. Example conditions:
|
|
|
|
* - 'a << s' causes bits to be lost when stored in *d.
|
|
|
|
* - 's' is garbage (e.g. negative) or so large that the result of
|
|
|
|
* 'a << s' is guaranteed to be 0.
|
|
|
|
* - 'a' is negative.
|
|
|
|
* - 'a << s' sets the sign bit, if any, in '*d'.
|
|
|
|
*
|
|
|
|
* '*d' will hold the results of the attempted shift, but is not
|
2021-04-01 16:06:29 +00:00
|
|
|
* considered "safe for use" if true is returned.
|
2018-08-01 21:25:39 +00:00
|
|
|
*/
|
2020-08-12 21:47:03 +00:00
|
|
|
#define check_shl_overflow(a, s, d) __must_check_overflow(({ \
|
2018-08-01 21:25:39 +00:00
|
|
|
typeof(a) _a = a; \
|
|
|
|
typeof(s) _s = s; \
|
|
|
|
typeof(d) _d = d; \
|
|
|
|
u64 _a_full = _a; \
|
|
|
|
unsigned int _to_shift = \
|
2019-03-17 10:11:14 +00:00
|
|
|
is_non_negative(_s) && _s < 8 * sizeof(*d) ? _s : 0; \
|
2018-08-01 21:25:39 +00:00
|
|
|
*_d = (_a_full << _to_shift); \
|
2019-03-17 10:11:14 +00:00
|
|
|
(_to_shift != _s || is_negative(*_d) || is_negative(_a) || \
|
|
|
|
(*_d >> _to_shift) != _a); \
|
2020-08-12 21:47:03 +00:00
|
|
|
}))
|
2018-08-01 21:25:39 +00:00
|
|
|
|
overflow: Introduce castable_to_type()
NOTE: This commit does not compile due to missing RHEL-specific fix-ups,
which are split out into separate Git commits following this one.
If git bisect selected this commit, run "git bisect skip" and try again.
Repeat this until it selects a commit which compiles.
Partially backport "overflow: Introduce overflows_type() and castable_to_type()"
Only backport castable_to_type() needed by i915 driver.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2160457
Upstream Status: v6.2-rc1
commit 4b21d25bf519c9487935a664886956bb18f04f6d
Author: Kees Cook <keescook@chromium.org>
AuthorDate: Mon Oct 24 23:11:25 2022 +0300
Commit: Kees Cook <keescook@chromium.org>
CommitDate: Wed Nov 2 12:39:27 2022 -0700
Implement a robust overflows_type() macro to test if a variable or
constant value would overflow another variable or type. This can be
used as a constant expression for static_assert() (which requires a
constant expression[1][2]) when used on constant values. This must be
constructed manually, since __builtin_add_overflow() does not produce
a constant expression[3].
Additionally adds castable_to_type(), similar to __same_type(), but for
checking if a constant value would overflow if cast to a given type.
Add unit tests for overflows_type(), __same_type(), and castable_to_type()
to the existing KUnit "overflow" test:
[16:03:33] ================== overflow (21 subtests) ==================
...
[16:03:33] [PASSED] overflows_type_test
[16:03:33] [PASSED] same_type_test
[16:03:33] [PASSED] castable_to_type_test
[16:03:33] ==================== [PASSED] overflow =====================
[16:03:33] ============================================================
[16:03:33] Testing complete. Ran 21 tests: passed: 21
[16:03:33] Elapsed time: 24.022s total, 0.002s configuring, 22.598s building, 0.767s running
[1] https://en.cppreference.com/w/c/language/_Static_assert
[2] C11 standard (ISO/IEC 9899:2011): 6.7.10 Static assertions
[3] https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
6.56 Built-in Functions to Perform Arithmetic with Overflow Checking
Built-in Function: bool __builtin_add_overflow (type1 a, type2 b,
Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Tom Rix <trix@redhat.com>
Cc: Daniel Latypov <dlatypov@google.com>
Cc: Vitor Massaru Iha <vitor@massaru.org>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: linux-hardening@vger.kernel.org
Cc: llvm@lists.linux.dev
Co-developed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20221024201125.1416422-1-gwan-gyeong.mun@intel.com
Signed-off-by: Mika Penttilä <mpenttil@redhat.com>
2023-06-15 09:38:52 +00:00
|
|
|
#define __overflows_type_constexpr(x, T) ( \
|
|
|
|
is_unsigned_type(typeof(x)) ? \
|
|
|
|
(x) > type_max(typeof(T)) : \
|
|
|
|
is_unsigned_type(typeof(T)) ? \
|
|
|
|
(x) < 0 || (x) > type_max(typeof(T)) : \
|
|
|
|
(x) < type_min(typeof(T)) || (x) > type_max(typeof(T)))
|
|
|
|
|
|
|
|
#define __overflows_type(x, T) ({ \
|
|
|
|
typeof(T) v = 0; \
|
|
|
|
check_add_overflow((x), v, &v); \
|
|
|
|
})
|
|
|
|
|
|
|
|
/**
|
|
|
|
* castable_to_type - like __same_type(), but also allows for casted literals
|
|
|
|
*
|
|
|
|
* @n: variable or constant value
|
|
|
|
* @T: variable or data type
|
|
|
|
*
|
|
|
|
* Unlike the __same_type() macro, this allows a constant value as the
|
|
|
|
* first argument. If this value would not overflow into an assignment
|
|
|
|
* of the second argument's type, it returns true. Otherwise, this falls
|
|
|
|
* back to __same_type().
|
|
|
|
*/
|
|
|
|
#define castable_to_type(n, T) \
|
|
|
|
__builtin_choose_expr(__is_constexpr(n), \
|
|
|
|
!__overflows_type_constexpr(n, T), \
|
|
|
|
__same_type(n, T))
|
|
|
|
|
2018-05-07 23:47:02 +00:00
|
|
|
/**
|
overflow: Implement size_t saturating arithmetic helpers
commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f
Author: Kees Cook <keescook@chromium.org>
Date: Sat Sep 18 15:17:53 2021 -0700
overflow: Implement size_t saturating arithmetic helpers
In order to perform more open-coded replacements of common allocation
size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
multiplication, addition, and subtraction. For example, it is common in
allocators, especially on realloc, to add to an existing size:
p = krealloc(map->patch,
sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
GFP_KERNEL);
There is no existing saturating replacement for this calculation, and
just leaving the addition open coded inside array_size() could
potentially overflow as well. For example, an overflow in an expression
for a size_t argument might wrap to zero:
array_size(anything, something_at_size_max + 1) == 0
Introduce size_mul(), size_add(), and size_sub() helpers that
implicitly promote arguments to size_t and saturated calculations for
use in allocations. With these helpers it is also possible to redefine
array_size(), array3_size(), flex_array_size(), and struct_size() in
terms of the new helpers.
As with the check_*_overflow() helpers, the new helpers use __must_check,
though what is really desired is a way to make sure that assignment is
only to a size_t lvalue. Without this, it's still possible to introduce
overflow/underflow via type conversion (i.e. from size_t to int).
Enforcing this will currently need to be left to static analysis or
future use of -Wconversion.
Additionally update the overflow unit tests to force runtime evaluation
for the pathological cases.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Len Baker <len.baker@gmx.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168378
Signed-off-by: Nico Pache <npache@redhat.com>
2023-02-22 20:05:32 +00:00
|
|
|
* size_mul() - Calculate size_t multiplication with saturation at SIZE_MAX
|
2018-05-07 23:47:02 +00:00
|
|
|
*
|
overflow: Implement size_t saturating arithmetic helpers
commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f
Author: Kees Cook <keescook@chromium.org>
Date: Sat Sep 18 15:17:53 2021 -0700
overflow: Implement size_t saturating arithmetic helpers
In order to perform more open-coded replacements of common allocation
size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
multiplication, addition, and subtraction. For example, it is common in
allocators, especially on realloc, to add to an existing size:
p = krealloc(map->patch,
sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
GFP_KERNEL);
There is no existing saturating replacement for this calculation, and
just leaving the addition open coded inside array_size() could
potentially overflow as well. For example, an overflow in an expression
for a size_t argument might wrap to zero:
array_size(anything, something_at_size_max + 1) == 0
Introduce size_mul(), size_add(), and size_sub() helpers that
implicitly promote arguments to size_t and saturated calculations for
use in allocations. With these helpers it is also possible to redefine
array_size(), array3_size(), flex_array_size(), and struct_size() in
terms of the new helpers.
As with the check_*_overflow() helpers, the new helpers use __must_check,
though what is really desired is a way to make sure that assignment is
only to a size_t lvalue. Without this, it's still possible to introduce
overflow/underflow via type conversion (i.e. from size_t to int).
Enforcing this will currently need to be left to static analysis or
future use of -Wconversion.
Additionally update the overflow unit tests to force runtime evaluation
for the pathological cases.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Len Baker <len.baker@gmx.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168378
Signed-off-by: Nico Pache <npache@redhat.com>
2023-02-22 20:05:32 +00:00
|
|
|
* @factor1: first factor
|
|
|
|
* @factor2: second factor
|
2018-05-07 23:47:02 +00:00
|
|
|
*
|
overflow: Implement size_t saturating arithmetic helpers
commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f
Author: Kees Cook <keescook@chromium.org>
Date: Sat Sep 18 15:17:53 2021 -0700
overflow: Implement size_t saturating arithmetic helpers
In order to perform more open-coded replacements of common allocation
size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
multiplication, addition, and subtraction. For example, it is common in
allocators, especially on realloc, to add to an existing size:
p = krealloc(map->patch,
sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
GFP_KERNEL);
There is no existing saturating replacement for this calculation, and
just leaving the addition open coded inside array_size() could
potentially overflow as well. For example, an overflow in an expression
for a size_t argument might wrap to zero:
array_size(anything, something_at_size_max + 1) == 0
Introduce size_mul(), size_add(), and size_sub() helpers that
implicitly promote arguments to size_t and saturated calculations for
use in allocations. With these helpers it is also possible to redefine
array_size(), array3_size(), flex_array_size(), and struct_size() in
terms of the new helpers.
As with the check_*_overflow() helpers, the new helpers use __must_check,
though what is really desired is a way to make sure that assignment is
only to a size_t lvalue. Without this, it's still possible to introduce
overflow/underflow via type conversion (i.e. from size_t to int).
Enforcing this will currently need to be left to static analysis or
future use of -Wconversion.
Additionally update the overflow unit tests to force runtime evaluation
for the pathological cases.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Len Baker <len.baker@gmx.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168378
Signed-off-by: Nico Pache <npache@redhat.com>
2023-02-22 20:05:32 +00:00
|
|
|
* Returns: calculate @factor1 * @factor2, both promoted to size_t,
|
|
|
|
* with any overflow causing the return value to be SIZE_MAX. The
|
|
|
|
* lvalue must be size_t to avoid implicit type conversion.
|
2018-05-07 23:47:02 +00:00
|
|
|
*/
|
overflow: Implement size_t saturating arithmetic helpers
commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f
Author: Kees Cook <keescook@chromium.org>
Date: Sat Sep 18 15:17:53 2021 -0700
overflow: Implement size_t saturating arithmetic helpers
In order to perform more open-coded replacements of common allocation
size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
multiplication, addition, and subtraction. For example, it is common in
allocators, especially on realloc, to add to an existing size:
p = krealloc(map->patch,
sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
GFP_KERNEL);
There is no existing saturating replacement for this calculation, and
just leaving the addition open coded inside array_size() could
potentially overflow as well. For example, an overflow in an expression
for a size_t argument might wrap to zero:
array_size(anything, something_at_size_max + 1) == 0
Introduce size_mul(), size_add(), and size_sub() helpers that
implicitly promote arguments to size_t and saturated calculations for
use in allocations. With these helpers it is also possible to redefine
array_size(), array3_size(), flex_array_size(), and struct_size() in
terms of the new helpers.
As with the check_*_overflow() helpers, the new helpers use __must_check,
though what is really desired is a way to make sure that assignment is
only to a size_t lvalue. Without this, it's still possible to introduce
overflow/underflow via type conversion (i.e. from size_t to int).
Enforcing this will currently need to be left to static analysis or
future use of -Wconversion.
Additionally update the overflow unit tests to force runtime evaluation
for the pathological cases.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Len Baker <len.baker@gmx.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168378
Signed-off-by: Nico Pache <npache@redhat.com>
2023-02-22 20:05:32 +00:00
|
|
|
static inline size_t __must_check size_mul(size_t factor1, size_t factor2)
|
2018-05-07 23:47:02 +00:00
|
|
|
{
|
|
|
|
size_t bytes;
|
|
|
|
|
overflow: Implement size_t saturating arithmetic helpers
commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f
Author: Kees Cook <keescook@chromium.org>
Date: Sat Sep 18 15:17:53 2021 -0700
overflow: Implement size_t saturating arithmetic helpers
In order to perform more open-coded replacements of common allocation
size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
multiplication, addition, and subtraction. For example, it is common in
allocators, especially on realloc, to add to an existing size:
p = krealloc(map->patch,
sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
GFP_KERNEL);
There is no existing saturating replacement for this calculation, and
just leaving the addition open coded inside array_size() could
potentially overflow as well. For example, an overflow in an expression
for a size_t argument might wrap to zero:
array_size(anything, something_at_size_max + 1) == 0
Introduce size_mul(), size_add(), and size_sub() helpers that
implicitly promote arguments to size_t and saturated calculations for
use in allocations. With these helpers it is also possible to redefine
array_size(), array3_size(), flex_array_size(), and struct_size() in
terms of the new helpers.
As with the check_*_overflow() helpers, the new helpers use __must_check,
though what is really desired is a way to make sure that assignment is
only to a size_t lvalue. Without this, it's still possible to introduce
overflow/underflow via type conversion (i.e. from size_t to int).
Enforcing this will currently need to be left to static analysis or
future use of -Wconversion.
Additionally update the overflow unit tests to force runtime evaluation
for the pathological cases.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Len Baker <len.baker@gmx.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168378
Signed-off-by: Nico Pache <npache@redhat.com>
2023-02-22 20:05:32 +00:00
|
|
|
if (check_mul_overflow(factor1, factor2, &bytes))
|
2018-05-07 23:47:02 +00:00
|
|
|
return SIZE_MAX;
|
|
|
|
|
|
|
|
return bytes;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
overflow: Implement size_t saturating arithmetic helpers
commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f
Author: Kees Cook <keescook@chromium.org>
Date: Sat Sep 18 15:17:53 2021 -0700
overflow: Implement size_t saturating arithmetic helpers
In order to perform more open-coded replacements of common allocation
size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
multiplication, addition, and subtraction. For example, it is common in
allocators, especially on realloc, to add to an existing size:
p = krealloc(map->patch,
sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
GFP_KERNEL);
There is no existing saturating replacement for this calculation, and
just leaving the addition open coded inside array_size() could
potentially overflow as well. For example, an overflow in an expression
for a size_t argument might wrap to zero:
array_size(anything, something_at_size_max + 1) == 0
Introduce size_mul(), size_add(), and size_sub() helpers that
implicitly promote arguments to size_t and saturated calculations for
use in allocations. With these helpers it is also possible to redefine
array_size(), array3_size(), flex_array_size(), and struct_size() in
terms of the new helpers.
As with the check_*_overflow() helpers, the new helpers use __must_check,
though what is really desired is a way to make sure that assignment is
only to a size_t lvalue. Without this, it's still possible to introduce
overflow/underflow via type conversion (i.e. from size_t to int).
Enforcing this will currently need to be left to static analysis or
future use of -Wconversion.
Additionally update the overflow unit tests to force runtime evaluation
for the pathological cases.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Len Baker <len.baker@gmx.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168378
Signed-off-by: Nico Pache <npache@redhat.com>
2023-02-22 20:05:32 +00:00
|
|
|
* size_add() - Calculate size_t addition with saturation at SIZE_MAX
|
2018-05-07 23:47:02 +00:00
|
|
|
*
|
overflow: Implement size_t saturating arithmetic helpers
commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f
Author: Kees Cook <keescook@chromium.org>
Date: Sat Sep 18 15:17:53 2021 -0700
overflow: Implement size_t saturating arithmetic helpers
In order to perform more open-coded replacements of common allocation
size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
multiplication, addition, and subtraction. For example, it is common in
allocators, especially on realloc, to add to an existing size:
p = krealloc(map->patch,
sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
GFP_KERNEL);
There is no existing saturating replacement for this calculation, and
just leaving the addition open coded inside array_size() could
potentially overflow as well. For example, an overflow in an expression
for a size_t argument might wrap to zero:
array_size(anything, something_at_size_max + 1) == 0
Introduce size_mul(), size_add(), and size_sub() helpers that
implicitly promote arguments to size_t and saturated calculations for
use in allocations. With these helpers it is also possible to redefine
array_size(), array3_size(), flex_array_size(), and struct_size() in
terms of the new helpers.
As with the check_*_overflow() helpers, the new helpers use __must_check,
though what is really desired is a way to make sure that assignment is
only to a size_t lvalue. Without this, it's still possible to introduce
overflow/underflow via type conversion (i.e. from size_t to int).
Enforcing this will currently need to be left to static analysis or
future use of -Wconversion.
Additionally update the overflow unit tests to force runtime evaluation
for the pathological cases.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Len Baker <len.baker@gmx.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168378
Signed-off-by: Nico Pache <npache@redhat.com>
2023-02-22 20:05:32 +00:00
|
|
|
* @addend1: first addend
|
|
|
|
* @addend2: second addend
|
2018-05-07 23:47:02 +00:00
|
|
|
*
|
overflow: Implement size_t saturating arithmetic helpers
commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f
Author: Kees Cook <keescook@chromium.org>
Date: Sat Sep 18 15:17:53 2021 -0700
overflow: Implement size_t saturating arithmetic helpers
In order to perform more open-coded replacements of common allocation
size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
multiplication, addition, and subtraction. For example, it is common in
allocators, especially on realloc, to add to an existing size:
p = krealloc(map->patch,
sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
GFP_KERNEL);
There is no existing saturating replacement for this calculation, and
just leaving the addition open coded inside array_size() could
potentially overflow as well. For example, an overflow in an expression
for a size_t argument might wrap to zero:
array_size(anything, something_at_size_max + 1) == 0
Introduce size_mul(), size_add(), and size_sub() helpers that
implicitly promote arguments to size_t and saturated calculations for
use in allocations. With these helpers it is also possible to redefine
array_size(), array3_size(), flex_array_size(), and struct_size() in
terms of the new helpers.
As with the check_*_overflow() helpers, the new helpers use __must_check,
though what is really desired is a way to make sure that assignment is
only to a size_t lvalue. Without this, it's still possible to introduce
overflow/underflow via type conversion (i.e. from size_t to int).
Enforcing this will currently need to be left to static analysis or
future use of -Wconversion.
Additionally update the overflow unit tests to force runtime evaluation
for the pathological cases.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Len Baker <len.baker@gmx.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168378
Signed-off-by: Nico Pache <npache@redhat.com>
2023-02-22 20:05:32 +00:00
|
|
|
* Returns: calculate @addend1 + @addend2, both promoted to size_t,
|
|
|
|
* with any overflow causing the return value to be SIZE_MAX. The
|
|
|
|
* lvalue must be size_t to avoid implicit type conversion.
|
2018-05-07 23:47:02 +00:00
|
|
|
*/
|
overflow: Implement size_t saturating arithmetic helpers
commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f
Author: Kees Cook <keescook@chromium.org>
Date: Sat Sep 18 15:17:53 2021 -0700
overflow: Implement size_t saturating arithmetic helpers
In order to perform more open-coded replacements of common allocation
size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
multiplication, addition, and subtraction. For example, it is common in
allocators, especially on realloc, to add to an existing size:
p = krealloc(map->patch,
sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
GFP_KERNEL);
There is no existing saturating replacement for this calculation, and
just leaving the addition open coded inside array_size() could
potentially overflow as well. For example, an overflow in an expression
for a size_t argument might wrap to zero:
array_size(anything, something_at_size_max + 1) == 0
Introduce size_mul(), size_add(), and size_sub() helpers that
implicitly promote arguments to size_t and saturated calculations for
use in allocations. With these helpers it is also possible to redefine
array_size(), array3_size(), flex_array_size(), and struct_size() in
terms of the new helpers.
As with the check_*_overflow() helpers, the new helpers use __must_check,
though what is really desired is a way to make sure that assignment is
only to a size_t lvalue. Without this, it's still possible to introduce
overflow/underflow via type conversion (i.e. from size_t to int).
Enforcing this will currently need to be left to static analysis or
future use of -Wconversion.
Additionally update the overflow unit tests to force runtime evaluation
for the pathological cases.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Len Baker <len.baker@gmx.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168378
Signed-off-by: Nico Pache <npache@redhat.com>
2023-02-22 20:05:32 +00:00
|
|
|
static inline size_t __must_check size_add(size_t addend1, size_t addend2)
|
2018-05-07 23:47:02 +00:00
|
|
|
{
|
|
|
|
size_t bytes;
|
|
|
|
|
overflow: Implement size_t saturating arithmetic helpers
commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f
Author: Kees Cook <keescook@chromium.org>
Date: Sat Sep 18 15:17:53 2021 -0700
overflow: Implement size_t saturating arithmetic helpers
In order to perform more open-coded replacements of common allocation
size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
multiplication, addition, and subtraction. For example, it is common in
allocators, especially on realloc, to add to an existing size:
p = krealloc(map->patch,
sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
GFP_KERNEL);
There is no existing saturating replacement for this calculation, and
just leaving the addition open coded inside array_size() could
potentially overflow as well. For example, an overflow in an expression
for a size_t argument might wrap to zero:
array_size(anything, something_at_size_max + 1) == 0
Introduce size_mul(), size_add(), and size_sub() helpers that
implicitly promote arguments to size_t and saturated calculations for
use in allocations. With these helpers it is also possible to redefine
array_size(), array3_size(), flex_array_size(), and struct_size() in
terms of the new helpers.
As with the check_*_overflow() helpers, the new helpers use __must_check,
though what is really desired is a way to make sure that assignment is
only to a size_t lvalue. Without this, it's still possible to introduce
overflow/underflow via type conversion (i.e. from size_t to int).
Enforcing this will currently need to be left to static analysis or
future use of -Wconversion.
Additionally update the overflow unit tests to force runtime evaluation
for the pathological cases.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Len Baker <len.baker@gmx.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168378
Signed-off-by: Nico Pache <npache@redhat.com>
2023-02-22 20:05:32 +00:00
|
|
|
if (check_add_overflow(addend1, addend2, &bytes))
|
2018-05-07 23:47:02 +00:00
|
|
|
return SIZE_MAX;
|
|
|
|
|
|
|
|
return bytes;
|
|
|
|
}
|
|
|
|
|
overflow: Implement size_t saturating arithmetic helpers
commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f
Author: Kees Cook <keescook@chromium.org>
Date: Sat Sep 18 15:17:53 2021 -0700
overflow: Implement size_t saturating arithmetic helpers
In order to perform more open-coded replacements of common allocation
size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
multiplication, addition, and subtraction. For example, it is common in
allocators, especially on realloc, to add to an existing size:
p = krealloc(map->patch,
sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
GFP_KERNEL);
There is no existing saturating replacement for this calculation, and
just leaving the addition open coded inside array_size() could
potentially overflow as well. For example, an overflow in an expression
for a size_t argument might wrap to zero:
array_size(anything, something_at_size_max + 1) == 0
Introduce size_mul(), size_add(), and size_sub() helpers that
implicitly promote arguments to size_t and saturated calculations for
use in allocations. With these helpers it is also possible to redefine
array_size(), array3_size(), flex_array_size(), and struct_size() in
terms of the new helpers.
As with the check_*_overflow() helpers, the new helpers use __must_check,
though what is really desired is a way to make sure that assignment is
only to a size_t lvalue. Without this, it's still possible to introduce
overflow/underflow via type conversion (i.e. from size_t to int).
Enforcing this will currently need to be left to static analysis or
future use of -Wconversion.
Additionally update the overflow unit tests to force runtime evaluation
for the pathological cases.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Len Baker <len.baker@gmx.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168378
Signed-off-by: Nico Pache <npache@redhat.com>
2023-02-22 20:05:32 +00:00
|
|
|
/**
|
|
|
|
* size_sub() - Calculate size_t subtraction with saturation at SIZE_MAX
|
|
|
|
*
|
|
|
|
* @minuend: value to subtract from
|
|
|
|
* @subtrahend: value to subtract from @minuend
|
|
|
|
*
|
|
|
|
* Returns: calculate @minuend - @subtrahend, both promoted to size_t,
|
|
|
|
* with any overflow causing the return value to be SIZE_MAX. For
|
|
|
|
* composition with the size_add() and size_mul() helpers, neither
|
|
|
|
* argument may be SIZE_MAX (or the result with be forced to SIZE_MAX).
|
|
|
|
* The lvalue must be size_t to avoid implicit type conversion.
|
2019-04-10 20:27:25 +00:00
|
|
|
*/
|
overflow: Implement size_t saturating arithmetic helpers
commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f
Author: Kees Cook <keescook@chromium.org>
Date: Sat Sep 18 15:17:53 2021 -0700
overflow: Implement size_t saturating arithmetic helpers
In order to perform more open-coded replacements of common allocation
size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
multiplication, addition, and subtraction. For example, it is common in
allocators, especially on realloc, to add to an existing size:
p = krealloc(map->patch,
sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
GFP_KERNEL);
There is no existing saturating replacement for this calculation, and
just leaving the addition open coded inside array_size() could
potentially overflow as well. For example, an overflow in an expression
for a size_t argument might wrap to zero:
array_size(anything, something_at_size_max + 1) == 0
Introduce size_mul(), size_add(), and size_sub() helpers that
implicitly promote arguments to size_t and saturated calculations for
use in allocations. With these helpers it is also possible to redefine
array_size(), array3_size(), flex_array_size(), and struct_size() in
terms of the new helpers.
As with the check_*_overflow() helpers, the new helpers use __must_check,
though what is really desired is a way to make sure that assignment is
only to a size_t lvalue. Without this, it's still possible to introduce
overflow/underflow via type conversion (i.e. from size_t to int).
Enforcing this will currently need to be left to static analysis or
future use of -Wconversion.
Additionally update the overflow unit tests to force runtime evaluation
for the pathological cases.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Len Baker <len.baker@gmx.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168378
Signed-off-by: Nico Pache <npache@redhat.com>
2023-02-22 20:05:32 +00:00
|
|
|
static inline size_t __must_check size_sub(size_t minuend, size_t subtrahend)
|
2018-05-07 23:47:02 +00:00
|
|
|
{
|
|
|
|
size_t bytes;
|
|
|
|
|
overflow: Implement size_t saturating arithmetic helpers
commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f
Author: Kees Cook <keescook@chromium.org>
Date: Sat Sep 18 15:17:53 2021 -0700
overflow: Implement size_t saturating arithmetic helpers
In order to perform more open-coded replacements of common allocation
size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
multiplication, addition, and subtraction. For example, it is common in
allocators, especially on realloc, to add to an existing size:
p = krealloc(map->patch,
sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
GFP_KERNEL);
There is no existing saturating replacement for this calculation, and
just leaving the addition open coded inside array_size() could
potentially overflow as well. For example, an overflow in an expression
for a size_t argument might wrap to zero:
array_size(anything, something_at_size_max + 1) == 0
Introduce size_mul(), size_add(), and size_sub() helpers that
implicitly promote arguments to size_t and saturated calculations for
use in allocations. With these helpers it is also possible to redefine
array_size(), array3_size(), flex_array_size(), and struct_size() in
terms of the new helpers.
As with the check_*_overflow() helpers, the new helpers use __must_check,
though what is really desired is a way to make sure that assignment is
only to a size_t lvalue. Without this, it's still possible to introduce
overflow/underflow via type conversion (i.e. from size_t to int).
Enforcing this will currently need to be left to static analysis or
future use of -Wconversion.
Additionally update the overflow unit tests to force runtime evaluation
for the pathological cases.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Len Baker <len.baker@gmx.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168378
Signed-off-by: Nico Pache <npache@redhat.com>
2023-02-22 20:05:32 +00:00
|
|
|
if (minuend == SIZE_MAX || subtrahend == SIZE_MAX ||
|
|
|
|
check_sub_overflow(minuend, subtrahend, &bytes))
|
2018-05-07 23:47:02 +00:00
|
|
|
return SIZE_MAX;
|
|
|
|
|
|
|
|
return bytes;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
overflow: Implement size_t saturating arithmetic helpers
commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f
Author: Kees Cook <keescook@chromium.org>
Date: Sat Sep 18 15:17:53 2021 -0700
overflow: Implement size_t saturating arithmetic helpers
In order to perform more open-coded replacements of common allocation
size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
multiplication, addition, and subtraction. For example, it is common in
allocators, especially on realloc, to add to an existing size:
p = krealloc(map->patch,
sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
GFP_KERNEL);
There is no existing saturating replacement for this calculation, and
just leaving the addition open coded inside array_size() could
potentially overflow as well. For example, an overflow in an expression
for a size_t argument might wrap to zero:
array_size(anything, something_at_size_max + 1) == 0
Introduce size_mul(), size_add(), and size_sub() helpers that
implicitly promote arguments to size_t and saturated calculations for
use in allocations. With these helpers it is also possible to redefine
array_size(), array3_size(), flex_array_size(), and struct_size() in
terms of the new helpers.
As with the check_*_overflow() helpers, the new helpers use __must_check,
though what is really desired is a way to make sure that assignment is
only to a size_t lvalue. Without this, it's still possible to introduce
overflow/underflow via type conversion (i.e. from size_t to int).
Enforcing this will currently need to be left to static analysis or
future use of -Wconversion.
Additionally update the overflow unit tests to force runtime evaluation
for the pathological cases.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Len Baker <len.baker@gmx.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168378
Signed-off-by: Nico Pache <npache@redhat.com>
2023-02-22 20:05:32 +00:00
|
|
|
* array_size() - Calculate size of 2-dimensional array.
|
2018-05-07 23:47:02 +00:00
|
|
|
*
|
overflow: Implement size_t saturating arithmetic helpers
commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f
Author: Kees Cook <keescook@chromium.org>
Date: Sat Sep 18 15:17:53 2021 -0700
overflow: Implement size_t saturating arithmetic helpers
In order to perform more open-coded replacements of common allocation
size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
multiplication, addition, and subtraction. For example, it is common in
allocators, especially on realloc, to add to an existing size:
p = krealloc(map->patch,
sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
GFP_KERNEL);
There is no existing saturating replacement for this calculation, and
just leaving the addition open coded inside array_size() could
potentially overflow as well. For example, an overflow in an expression
for a size_t argument might wrap to zero:
array_size(anything, something_at_size_max + 1) == 0
Introduce size_mul(), size_add(), and size_sub() helpers that
implicitly promote arguments to size_t and saturated calculations for
use in allocations. With these helpers it is also possible to redefine
array_size(), array3_size(), flex_array_size(), and struct_size() in
terms of the new helpers.
As with the check_*_overflow() helpers, the new helpers use __must_check,
though what is really desired is a way to make sure that assignment is
only to a size_t lvalue. Without this, it's still possible to introduce
overflow/underflow via type conversion (i.e. from size_t to int).
Enforcing this will currently need to be left to static analysis or
future use of -Wconversion.
Additionally update the overflow unit tests to force runtime evaluation
for the pathological cases.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Len Baker <len.baker@gmx.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168378
Signed-off-by: Nico Pache <npache@redhat.com>
2023-02-22 20:05:32 +00:00
|
|
|
* @a: dimension one
|
|
|
|
* @b: dimension two
|
2018-05-07 23:47:02 +00:00
|
|
|
*
|
overflow: Implement size_t saturating arithmetic helpers
commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f
Author: Kees Cook <keescook@chromium.org>
Date: Sat Sep 18 15:17:53 2021 -0700
overflow: Implement size_t saturating arithmetic helpers
In order to perform more open-coded replacements of common allocation
size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
multiplication, addition, and subtraction. For example, it is common in
allocators, especially on realloc, to add to an existing size:
p = krealloc(map->patch,
sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
GFP_KERNEL);
There is no existing saturating replacement for this calculation, and
just leaving the addition open coded inside array_size() could
potentially overflow as well. For example, an overflow in an expression
for a size_t argument might wrap to zero:
array_size(anything, something_at_size_max + 1) == 0
Introduce size_mul(), size_add(), and size_sub() helpers that
implicitly promote arguments to size_t and saturated calculations for
use in allocations. With these helpers it is also possible to redefine
array_size(), array3_size(), flex_array_size(), and struct_size() in
terms of the new helpers.
As with the check_*_overflow() helpers, the new helpers use __must_check,
though what is really desired is a way to make sure that assignment is
only to a size_t lvalue. Without this, it's still possible to introduce
overflow/underflow via type conversion (i.e. from size_t to int).
Enforcing this will currently need to be left to static analysis or
future use of -Wconversion.
Additionally update the overflow unit tests to force runtime evaluation
for the pathological cases.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Len Baker <len.baker@gmx.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168378
Signed-off-by: Nico Pache <npache@redhat.com>
2023-02-22 20:05:32 +00:00
|
|
|
* Calculates size of 2-dimensional array: @a * @b.
|
|
|
|
*
|
|
|
|
* Returns: number of bytes needed to represent the array or SIZE_MAX on
|
|
|
|
* overflow.
|
2018-05-07 23:47:02 +00:00
|
|
|
*/
|
overflow: Implement size_t saturating arithmetic helpers
commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f
Author: Kees Cook <keescook@chromium.org>
Date: Sat Sep 18 15:17:53 2021 -0700
overflow: Implement size_t saturating arithmetic helpers
In order to perform more open-coded replacements of common allocation
size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
multiplication, addition, and subtraction. For example, it is common in
allocators, especially on realloc, to add to an existing size:
p = krealloc(map->patch,
sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
GFP_KERNEL);
There is no existing saturating replacement for this calculation, and
just leaving the addition open coded inside array_size() could
potentially overflow as well. For example, an overflow in an expression
for a size_t argument might wrap to zero:
array_size(anything, something_at_size_max + 1) == 0
Introduce size_mul(), size_add(), and size_sub() helpers that
implicitly promote arguments to size_t and saturated calculations for
use in allocations. With these helpers it is also possible to redefine
array_size(), array3_size(), flex_array_size(), and struct_size() in
terms of the new helpers.
As with the check_*_overflow() helpers, the new helpers use __must_check,
though what is really desired is a way to make sure that assignment is
only to a size_t lvalue. Without this, it's still possible to introduce
overflow/underflow via type conversion (i.e. from size_t to int).
Enforcing this will currently need to be left to static analysis or
future use of -Wconversion.
Additionally update the overflow unit tests to force runtime evaluation
for the pathological cases.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Len Baker <len.baker@gmx.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168378
Signed-off-by: Nico Pache <npache@redhat.com>
2023-02-22 20:05:32 +00:00
|
|
|
#define array_size(a, b) size_mul(a, b)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* array3_size() - Calculate size of 3-dimensional array.
|
|
|
|
*
|
|
|
|
* @a: dimension one
|
|
|
|
* @b: dimension two
|
|
|
|
* @c: dimension three
|
|
|
|
*
|
|
|
|
* Calculates size of 3-dimensional array: @a * @b * @c.
|
|
|
|
*
|
|
|
|
* Returns: number of bytes needed to represent the array or SIZE_MAX on
|
|
|
|
* overflow.
|
|
|
|
*/
|
|
|
|
#define array3_size(a, b, c) size_mul(size_mul(a, b), c)
|
2018-05-07 23:47:02 +00:00
|
|
|
|
2020-06-09 01:22:33 +00:00
|
|
|
/**
|
|
|
|
* flex_array_size() - Calculate size of a flexible array member
|
|
|
|
* within an enclosing structure.
|
|
|
|
*
|
|
|
|
* @p: Pointer to the structure.
|
|
|
|
* @member: Name of the flexible array member.
|
|
|
|
* @count: Number of elements in the array.
|
|
|
|
*
|
|
|
|
* Calculates size of a flexible array of @count number of @member
|
|
|
|
* elements, at the end of structure @p.
|
|
|
|
*
|
|
|
|
* Return: number of bytes needed or SIZE_MAX on overflow.
|
|
|
|
*/
|
|
|
|
#define flex_array_size(p, member, count) \
|
2023-02-22 20:05:32 +00:00
|
|
|
__builtin_choose_expr(__is_constexpr(count), \
|
|
|
|
(count) * sizeof(*(p)->member) + __must_be_array((p)->member), \
|
|
|
|
size_mul(count, sizeof(*(p)->member) + __must_be_array((p)->member)))
|
overflow: Implement size_t saturating arithmetic helpers
commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f
Author: Kees Cook <keescook@chromium.org>
Date: Sat Sep 18 15:17:53 2021 -0700
overflow: Implement size_t saturating arithmetic helpers
In order to perform more open-coded replacements of common allocation
size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
multiplication, addition, and subtraction. For example, it is common in
allocators, especially on realloc, to add to an existing size:
p = krealloc(map->patch,
sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
GFP_KERNEL);
There is no existing saturating replacement for this calculation, and
just leaving the addition open coded inside array_size() could
potentially overflow as well. For example, an overflow in an expression
for a size_t argument might wrap to zero:
array_size(anything, something_at_size_max + 1) == 0
Introduce size_mul(), size_add(), and size_sub() helpers that
implicitly promote arguments to size_t and saturated calculations for
use in allocations. With these helpers it is also possible to redefine
array_size(), array3_size(), flex_array_size(), and struct_size() in
terms of the new helpers.
As with the check_*_overflow() helpers, the new helpers use __must_check,
though what is really desired is a way to make sure that assignment is
only to a size_t lvalue. Without this, it's still possible to introduce
overflow/underflow via type conversion (i.e. from size_t to int).
Enforcing this will currently need to be left to static analysis or
future use of -Wconversion.
Additionally update the overflow unit tests to force runtime evaluation
for the pathological cases.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Len Baker <len.baker@gmx.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168378
Signed-off-by: Nico Pache <npache@redhat.com>
2023-02-22 20:05:32 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* struct_size() - Calculate size of structure with trailing flexible array.
|
|
|
|
*
|
|
|
|
* @p: Pointer to the structure.
|
|
|
|
* @member: Name of the array member.
|
|
|
|
* @count: Number of elements in the array.
|
|
|
|
*
|
2024-03-26 20:43:34 +00:00
|
|
|
* Calculates size of memory needed for structure of @p followed by an
|
overflow: Implement size_t saturating arithmetic helpers
commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f
Author: Kees Cook <keescook@chromium.org>
Date: Sat Sep 18 15:17:53 2021 -0700
overflow: Implement size_t saturating arithmetic helpers
In order to perform more open-coded replacements of common allocation
size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
multiplication, addition, and subtraction. For example, it is common in
allocators, especially on realloc, to add to an existing size:
p = krealloc(map->patch,
sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
GFP_KERNEL);
There is no existing saturating replacement for this calculation, and
just leaving the addition open coded inside array_size() could
potentially overflow as well. For example, an overflow in an expression
for a size_t argument might wrap to zero:
array_size(anything, something_at_size_max + 1) == 0
Introduce size_mul(), size_add(), and size_sub() helpers that
implicitly promote arguments to size_t and saturated calculations for
use in allocations. With these helpers it is also possible to redefine
array_size(), array3_size(), flex_array_size(), and struct_size() in
terms of the new helpers.
As with the check_*_overflow() helpers, the new helpers use __must_check,
though what is really desired is a way to make sure that assignment is
only to a size_t lvalue. Without this, it's still possible to introduce
overflow/underflow via type conversion (i.e. from size_t to int).
Enforcing this will currently need to be left to static analysis or
future use of -Wconversion.
Additionally update the overflow unit tests to force runtime evaluation
for the pathological cases.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Len Baker <len.baker@gmx.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168378
Signed-off-by: Nico Pache <npache@redhat.com>
2023-02-22 20:05:32 +00:00
|
|
|
* array of @count number of @member elements.
|
|
|
|
*
|
|
|
|
* Return: number of bytes needed or SIZE_MAX on overflow.
|
|
|
|
*/
|
|
|
|
#define struct_size(p, member, count) \
|
2023-02-22 20:05:32 +00:00
|
|
|
__builtin_choose_expr(__is_constexpr(count), \
|
|
|
|
sizeof(*(p)) + flex_array_size(p, member, count), \
|
|
|
|
size_add(sizeof(*(p)), flex_array_size(p, member, count)))
|
2020-06-09 01:22:33 +00:00
|
|
|
|
2024-03-26 20:43:34 +00:00
|
|
|
/**
|
|
|
|
* struct_size_t() - Calculate size of structure with trailing flexible array
|
|
|
|
* @type: structure type name.
|
|
|
|
* @member: Name of the array member.
|
|
|
|
* @count: Number of elements in the array.
|
|
|
|
*
|
|
|
|
* Calculates size of memory needed for structure @type followed by an
|
|
|
|
* array of @count number of @member elements. Prefer using struct_size()
|
|
|
|
* when possible instead, to keep calculations associated with a specific
|
|
|
|
* instance variable of type @type.
|
|
|
|
*
|
|
|
|
* Return: number of bytes needed or SIZE_MAX on overflow.
|
|
|
|
*/
|
|
|
|
#define struct_size_t(type, member, count) \
|
|
|
|
struct_size((type *)NULL, member, count)
|
|
|
|
|
2024-03-26 20:43:34 +00:00
|
|
|
/**
|
|
|
|
* _DEFINE_FLEX() - helper macro for DEFINE_FLEX() family.
|
|
|
|
* Enables caller macro to pass (different) initializer.
|
|
|
|
*
|
|
|
|
* @type: structure type name, including "struct" keyword.
|
|
|
|
* @name: Name for a variable to define.
|
|
|
|
* @member: Name of the array member.
|
|
|
|
* @count: Number of elements in the array; must be compile-time const.
|
|
|
|
* @initializer: initializer expression (could be empty for no init).
|
|
|
|
*/
|
|
|
|
#define _DEFINE_FLEX(type, name, member, count, initializer) \
|
|
|
|
_Static_assert(__builtin_constant_p(count), \
|
|
|
|
"onstack flex array members require compile-time const count"); \
|
|
|
|
union { \
|
|
|
|
u8 bytes[struct_size_t(type, member, count)]; \
|
|
|
|
type obj; \
|
|
|
|
} name##_u initializer; \
|
|
|
|
type *name = (type *)&name##_u
|
|
|
|
|
|
|
|
/**
|
|
|
|
* DEFINE_FLEX() - Define an on-stack instance of structure with a trailing
|
|
|
|
* flexible array member.
|
|
|
|
*
|
|
|
|
* @type: structure type name, including "struct" keyword.
|
|
|
|
* @name: Name for a variable to define.
|
|
|
|
* @member: Name of the array member.
|
|
|
|
* @count: Number of elements in the array; must be compile-time const.
|
|
|
|
*
|
|
|
|
* Define a zeroed, on-stack, instance of @type structure with a trailing
|
|
|
|
* flexible array member.
|
|
|
|
* Use __struct_size(@name) to get compile-time size of it afterwards.
|
|
|
|
*/
|
|
|
|
#define DEFINE_FLEX(type, name, member, count) \
|
|
|
|
_DEFINE_FLEX(type, name, member, count, = {})
|
|
|
|
|
compiler.h: enable builtin overflow checkers and add fallback code
This adds wrappers for the __builtin overflow checkers present in gcc
5.1+ as well as fallback implementations for earlier compilers. It's not
that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
the same. We obviously don't want the wrappers to have different
semantics depending on $GCC_VERSION, so we also insist on that even when
using the builtins.
There are a few problems with the 'a+b < a' idiom for checking for
overflow: For signed types, it relies on undefined behaviour and is
not actually complete (it doesn't check underflow;
e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
is wrong for all types (signed and unsigned) narrower than
int. Similarly, when a and b does not have the same type, there are
subtle cases like
u32 a;
if (a + sizeof(foo) < a)
return -EOVERFLOW;
a += sizeof(foo);
where the test is always false on 64 bit platforms. Add to that that it
is not always possible to determine the types involved at a glance.
The new overflow.h is somewhat bulky, but that's mostly a result of
trying to be type-generic, complete (e.g. catching not only overflow
but also signed underflow) and not relying on undefined behaviour.
Linus is of course right [1] that for unsigned subtraction a-b, the
right way to check for overflow (underflow) is "b > a" and not
"__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
covered here, and included mostly for completeness.
So is it worth it? I think it is, if nothing else for the documentation
value of seeing
if (check_add_overflow(a, b, &d))
return -EGOAWAY;
do_stuff_with(d);
instead of the open-coded (and possibly wrong and/or incomplete and/or
UBsan-tickling)
if (a+b < a)
return -EGOAWAY;
do_stuff_with(a+b);
While gcc does recognize the 'a+b < a' idiom for testing unsigned add
overflow, it doesn't do nearly as good for unsigned multiplication
(there's also no single well-established idiom). So using
check_mul_overflow in kcalloc and friends may also make gcc generate
slightly better code.
[1] https://lkml.org/lkml/2015/11/2/658
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-07 22:36:27 +00:00
|
|
|
#endif /* __LINUX_OVERFLOW_H */
|