linux-hardening - Re: [PATCH] fortify: Do not cast to "unsigned char"

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 linux-cve-announce PHC
Open Source and information security mailing list archives

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

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

Message-ID: <CAHk-=whybqnsbCe=+xfxx3ncjg-JG5+GQAZ70M8WKeAnVrZd5Q@mail.gmail.com>
Date:   Wed, 26 Oct 2022 11:47:35 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Kees Cook <keescook@...omium.org>, linux-hardening@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fortify: Do not cast to "unsigned char"

On Wed, Oct 26, 2022 at 11:26 AM Nick Desaulniers
<ndesaulniers@...gle.com> wrote:
>
> If the intent of __p is to avoid repeated application of side effects
> from the evaluation of the macro parameter p, this could also be:

Not the only intent.

The code also does

        __builtin_constant_p(*__p))

which basically checks for "is this a compile-time constant string"
(yes, I realize that it only checks the first character, but it ends
up being the same thing).

That would fail horribly with __auto_type and people using "void *".

It is true that we could probably use __auto_type in a lot of other
places where we currently use

        __typeof__(ptr) _p_ = (ptr)

but our "typeof" pattern is

 (a) much more common because of historical reasons

 (b) much more generic because it often uses a different ptr type (ie
macros that have a value and a pointer, like "put_user()", the type
comes from the pointer, but the initializer comes from the value, so
"__auto_type" ends up being completely the wrong thing).

We do have a couple of "__auto_type" uses, but because it can't
replace our __typeof__ users in general anyway, I'm not convinced we
should strive to make it hugely more common (even if the __auto_type
model probably can replace a lot of them).

                  Linus