linux-kernel - Re: [GIT PULL] gcc-plugins updates for v4.11-rc1

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:   Wed, 22 Feb 2017 17:25:51 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Emese Revfy <re.emese@...il.com>
Subject: Re: [GIT PULL] gcc-plugins updates for v4.11-rc1

On Tue, Feb 21, 2017 at 9:07 PM, Kees Cook <keescook@...omium.org> wrote:
> On Tue, Feb 21, 2017 at 6:34 PM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>
>> The crazy "__nocapture()" annotations are too ugly to live, and make
>> no sense. They are basically random noise to some very core header
>> files. And the "__unverified_nocapture()" ones are worse.
>
> Is it the naming, or something else?

No, it's just that it attaches to a (lot of) really core functions,
and makes those prototypes look odd and incomprehensible, and all for
a very odd and very limited and specific feature.

The plugin simply isn't important enough to warrant that kind of very
invasive marking of core functionality.

If the syntax was more pleasant, maybe it would be ok. For example,
marking the arguments individually in the argument declaration might
make it more palatable, ie the difference between

 (a) standard declaration:

       void *memcpy(void *dest, const void *src, size_t n);

 (b) nasty incomprehensible one:

       void *memcpy(void *dest, const void *src, size_t n) __nocapture(2);

 (c) possibly more legible one

       void *memcpy(void *dest, __nocapture const void *src, size_t n);

where I'm just randomly throwing out a syntax that I think _might_ be
more palatable.

Basically, those "numbered argument attributes" are ugly crap, but in
the case of things like the printf strings they are ugly shit with
very wide applicability and known very meaningful warnings that have
saved our arses several times.

So for printf, I see those "__attribute__ ((format...))" things, and I
think they are a particularly ugly marker, but it's a marker that I
think it is worth it, so the ugliness is an acceptable trade-off.

For something like "hint if something could be marked __init", the
ugliness is stronger (nonstandard fiormat, on even more core
functions), and the upside is less.

So in the __nocapture case, they are just really ugly (that "negative
index means return value" just takes the cake), and they don't even
have the major meaning and history that the printf ugliness has had.

                     Linus