lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 29 Aug 2022 23:14:56 +0200 From: Rasmus Villemoes <linux@...musvillemoes.dk> To: Kees Cook <keescook@...omium.org> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@...el.com>, Andrzej Hajda <andrzej.hajda@...el.com>, "Gustavo A. R. Silva" <gustavoars@...nel.org>, Nick Desaulniers <ndesaulniers@...gle.com>, linux-hardening@...r.kernel.org, Daniel Latypov <dlatypov@...gle.com>, Vitor Massaru Iha <vitor@...saru.org>, linux-kernel@...r.kernel.org Subject: Re: [PATCH] overflow: Allow mixed type arguments On 29/08/2022 22.47, Kees Cook wrote: > When the check_[op]_overflow() helpers were introduced, all arguments were > required to be the same type to make the fallback macros simpler. However, > once the fallback macros were removed[1], it is fine to allow mixed > types, which makes using the helpers much more useful, as they can be > used to test for type-based overflows (e.g. adding two large ints but > storing into a u8), as would be handy in the drm core[2]. > > Remove the restriction, and add additional self-tests that exercise some > of the mixed-type overflow cases. Makes sense. I'm a little worried about the implications for -stable backports to kernels that can still be built with gcc < 5.1, but we can't let that dictate what is done in mainline. And even people building old kernels shouldn't be using ancient compilers. > > -#define DEFINE_TEST_ARRAY(t) \ > - static const struct test_ ## t { \ > - t a, b; \ > - t sum, diff, prod; \ > - bool s_of, d_of, p_of; \ > - } t ## _tests[] > +#define DEFINE_TEST_ARRAY_TYPED(t1, t2, t) \ > + static const struct test_ ## t1 ## t2 ## t { \ > + t1 a; \ > + t2 b; \ > + t sum, diff, prod; \ > + bool s_of, d_of, p_of; \ > + } t1 ## t2 ## t ## _tests[] Can I get you to throw in some extra _, because this... > +DEFINE_TEST_FUNC_TYPED(u32u32int, int, "%d"); ...makes my eyes hurt a little. Maybe even make it u32_u32__int, so it's emphasized that the order is [src op src -> tgt] and not [tgt = src op src]. Rasmus
Powered by blists - more mailing lists