linux-hardening - Re: [PATCH] linux/const.h: Explain how __is

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 3 Feb 2022 01:28:24 +0100
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     David Laight <David.Laight@...lab.com>
Cc:     Rasmus Villemoes <rasmus.villemoes@...vas.dk>,
        Kees Cook <keescook@...omium.org>,
        Jonathan Corbet <corbet@....net>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Martin Uecker <Martin.Uecker@....uni-goettingen.de>,
        Ingo Molnar <mingo@...nel.org>,
        Rikard Falkeborn <rikard.falkeborn@...il.com>,
        Arnd Bergmann <arnd@...db.de>,
        "linux-doc@...r.kernel.org" <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-kernel@...r.kernel.org>,
        "linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>
Subject: Re: [PATCH] linux/const.h: Explain how __is_constexpr() works

On Wed, Feb 2, 2022 at 11:42 PM David Laight <David.Laight@...lab.com> wrote:
>
> The compiler needs to find a 'compatible type' either for:
>         (void *)x       and     (int *)8
> or for:
>         (void *)0       and     (int *)8
>
> In the former it is 'void *' and the latter 'int *' because the (void *)0
> is NULL and thus a valid 'int *' pointer.

I think you are trying to come up with an explanation of how it works
based on compiler outputs (it makes sense to think that the compiler
has to find some reasonable "common" type). But the conditional
operator works case-by-case, slightly differently depending on what
kind of operands you give.

In the two cases involved, there is no "finding a compatible type" /
promotions going on -- the standard gives explicitly that it is a
pointer to void (former case), and the type of the other operand
(latter case). The value is still decided by the condition.

e.g. https://godbolt.org/z/zzE8dc7Ye

0 ?          void pointer (1) : pointer to object type (42) = (void *) 0x2a
1 ?          void pointer (1) : pointer to object type (42) = (void *) 0x1
0 ? null pointer constant (0) : pointer                (42) = ( int *) 0x2a
1 ? null pointer constant (0) : pointer                (42) = ( int *) (nil)

> In any case suggesting that it is based on the value before the ? is bogus.

What Rasmus was saying is that which value is selected still depends
on the condition, because the last paragraph of the explanation in the
commit is wrong. It should be something like:

  - The ultimate comparison to "sizeof(int)" reduces to either:
        sizeof(int) == sizeof(*(int *)0)  (x was a constant expression)
        sizeof(int) == sizeof(*(void *)0) (x was not a constant expression)

Cheers,
Miguel