linux-kernel - Re: [bisected] 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91 oopses on s390

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]

Date:   Mon, 9 Apr 2018 11:17:11 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     Sebastian Ott <sebott@...ux.ibm.com>,
        Sebastian Ott <sebott@...ux.vnet.ibm.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Martin Uecker <Martin.Uecker@....uni-goettingen.de>,
        Ingo Molnar <mingo@...nel.org>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Subject: Re: [bisected] 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91 oopses on s390

On Mon, Apr 9, 2018 at 11:00 AM, Kees Cook <keescook@...omium.org> wrote:
>
> Can we update the comment near the top to explain why we need
> __UNIQUE_ID() since we've now rediscovered why it was originally
> there?

Too late, since it's already committed in my tree and going through
the build test paces.

But I really hope somebody revisits __UNIQUE_ID, and maybe they can
then add a comment to the users too.

It looks like gcc needs at least version 4.3 to have a working
__COUNTER__ implementation. What a coincidence - we don't really
support anything older now anyway.

And similarly for clang - the only versions that didn't have it are
not able to build the kernel anyway.

So we should remove any version conditionals, and we should remove the
known-broken generic fallback that uses __LINE__ instead of
__COUNTER__.

And once you do that, the "prefix" is actually pointlessm and we could
drop it to make __UNIQUE_ID() easier to use.

The *REAL* problem, however, is that __UNIQUE_ID is such a pain to use
in general. You basically have two choices:

 - use it as a single-declaration throwaway variable name that is
never actually used

 - use it only in a wrapper macro that then passes it off as an
argument to another macro that uses it several times

That "throwaway" use sounds pointless, but it's actually the *common*
use we have for this thing outside of this min/max case. It's used to
shut up the compiler about other unused variables, where people do
things like

   static __unused__ __UNIQUE_ID(xyz) = .. mark other variable as used here ..;

and I think the reason it's common is that it's the only *easy* use of
that unique-name-generator macro. Having to pass it off to a second
macro to use as a variable name makes it cumbersome to use for most
normal macro cases.

It would be nice to have the equivalent of __COUNTER__ that just
expanded not to a continually increasing number, but expanded to a
number that expands for each macro expansion.

Then you could do things like

    int UNIQUE(a) = (a);

to generate a variable name that was unique within a particular macro
expansion, and then actually _use_ UNIQUE(a) in the same macro
expansion to refer to it without having to pass it off as a name to
another macro that does the declaration and use.

You can't use __UNIQUE_ID() for that, because every new __UNIQUE_ID(a)
will give _another_ unique ID.

(And you *could* use the __LINE__ based one for that, but then you'd
get the whole "nasty shadowing" problem if we have nested macros
again).

Ugh. We have no wonderful model for unique names. Which is why we
obviously just use the "add underscores until it's unique" and the get
it wrong with nesting.

                Linus