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: Tue, 1 Feb 2022 14:05:53 +0100 From: Rasmus Villemoes <linux@...musvillemoes.dk> To: Kees Cook <keescook@...omium.org>, Jonathan Corbet <corbet@....net> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Martin Uecker <Martin.Uecker@....uni-goettingen.de>, Ingo Molnar <mingo@...nel.org>, Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Rikard Falkeborn <rikard.falkeborn@...il.com>, Arnd Bergmann <arnd@...db.de>, linux-doc@...r.kernel.org, Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>, Andrew Morton <akpm@...ux-foundation.org>, Andy Shevchenko <andy.shevchenko@...il.com>, Nick Desaulniers <ndesaulniers@...gle.com>, "Gustavo A. R. Silva" <gustavoars@...nel.org>, linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org Subject: Re: [PATCH] linux/const.h: Explain how __is_constexpr() works On 31/01/2022 21.43, Kees Cook wrote: > The __is_constexpr() macro is dark magic. Shed some light on it with > a comment to explain how and why it works. > > Cc: Jonathan Corbet <corbet@....net> > Cc: Linus Torvalds <torvalds@...ux-foundation.org> > Cc: Martin Uecker <Martin.Uecker@....uni-goettingen.de> > Cc: Ingo Molnar <mingo@...nel.org> > Cc: Miguel Ojeda <miguel.ojeda.sandonis@...il.com> > Cc: Rikard Falkeborn <rikard.falkeborn@...il.com> > Cc: Arnd Bergmann <arnd@...db.de> > Cc: linux-doc@...r.kernel.org > Signed-off-by: Kees Cook <keescook@...omium.org> > --- > Jon, since this is pure comment, do you want to take it through the docs tree? > --- > include/linux/const.h | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) > > diff --git a/include/linux/const.h b/include/linux/const.h > index 435ddd72d2c4..7122d6a1f8ce 100644 > --- a/include/linux/const.h > +++ b/include/linux/const.h > @@ -7,6 +7,30 @@ > * This returns a constant expression while determining if an argument is > * a constant expression, most importantly without evaluating the argument. > * Glory to Martin Uecker <Martin.Uecker@....uni-goettingen.de> > + * > + * Details: > + * - sizeof() is an integer constant expression, and does not evaluate the > + * value of its operand; it only examines the type of its operand. > + * - The results of comparing two integer constant expressions is also > + * an integer constant expression. > + * - The use of literal "8" is to avoid warnings about unaligned pointers; > + * these could otherwise just be "1"s. Just the second 8, the first could be a 0 or 12345 or whatever. > + * - (long)(x) is used to avoid warnings about 64-bit types on 32-bit > + * architectures. > + * - The C standard defines an "integer constant expression" as different > + * from a "null pointer constant" (an integer constant 0 pointer). I don't see the point of this bullet. Yes, an ICE is a distinct concept from a null pointer constant, obviously. One is defined in terms of the other - and your parenthesis is not an accurate paraphrase of the definition of a null pointer constant. > + * - The conditional operator ("... ? ... : ...") returns the type of the > + * operand that isn't a null pointer constant. This behavior is the > + * central mechanism of the macro. > + * - If (x) is an integer constant expression, then the "* 0l" resolves it > + * into a null pointer constant yes, because then it becomes "An integer constant expression with the value 0,". , which forces the conditional operator > + * to return the type of the last operand: "(int *)". > + * - If (x) is not an integer constant expression, then the type of the > + * conditional operator is from the first operand: "(void *)". Not entirely correct (and by "first" you probably meant second). It's better to just quote chapter-and-verse. C99, 6.5.15.6: [...] if one operand is a null pointer constant, the result has the type of the other operand; otherwise, one operand is a pointer to void or a qualified version of void, in which case the result type is a pointer to an appropriately qualified version of void. I.e., the second and third operands are treated symmetrically in the standard. > + * - sizeof(int) == 4 and sizeof(void) == 1. > + * - The ultimate comparison to "sizeof(int)" chooses between either: > + * sizeof(*((int *) (8)) == sizeof(int) (x was a constant expression) > + * sizeof(*((void *)(8)) == sizeof(void) (x was not a constant expression) Actually, since the first operand (the condition) is a non-zero number, the _value_ of the whole expression is the value of the _second_ operand, but with a _type_ determined by the above rules. So the whole ternary operator evalutes to either (void *)((void *)((long)(x) * 0l)) or (int *)((void *)((long)(x) * 0l)) I don't think adding slightly inaccurate comments would help a future reader at all. Then it's better to just stick to Linus' "it's art, and art should not be explained". Rasmus
Powered by blists - more mailing lists