linux-kernel - Re: [GIT PULL] gcc-plugins update for v4.8-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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFz2m30L5FRQDuwMEzj-32sk29Er3i+KtQKb0D_rLU239w@mail.gmail.com>
Date:	Mon, 8 Aug 2016 15:38:25 -0700
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>,
	Laura Abbott <labbott@...hat.com>,
	PaX Team <pageexec@...email.hu>
Subject: Re: [GIT PULL] gcc-plugins update for v4.8-rc1

On Tue, Aug 2, 2016 at 3:20 PM, Kees Cook <keescook@...omium.org> wrote:
>
> Please pull this new gcc-plugin for v4.8-rc1.

So I'm not pulling this for four reasons:

 (a) most of it is back-merges. There are 8 actual commits - but they
are preceded by 11 pointless merges of the kbuild branch. No thank
you.

 (b) of the eight actual commits, five are not about the new entropy
plugin at all, but are generic plugin fixes. Why did those not go
through the plugin support tree? I get the strong feeling that the
plugin infrastructure wasn't actually ready.

 (c) Of the four remaining commits that actually add entropy, the
"extra_latent_entropy" thing isn't about the gcc plugin at all, but
has a pointless "klet's mix it into the plugin pool" code under an
#ifdef. For no possible reason I can see.

 (d) you don't actually describe what the plugin does in the pull
request. I had to try to figure it out from reading the commit and the
plugin code. And quite frankly, even then it is not actually at all
obvious to me that this adds any real entropy at all in the situation
that actually matters most - the embedded "everythingsis the same, and
everybody uses the same build" situation.

>From what I can tell, 990% of the "entropy" this adds is about
build-time things (random numbers generated at build-time), and the
only real runtime entropy it adds comes from the frame pointer. And
that may well be identical from boot to boot when there are no real
timing differences.

The build-time random numbers are just pure garbage. There is *no*
entropy in them for the situation that matters most. You might as well
just generate one single random number at build-time without any fancy
new compiler plugin thing.

On a real PC, this plugin doesn't seem to matter, so it really seems
to be mostly about embedded hw without good sources of entropy. But
I'd really want to hear why such a platform would get noticeably more
entropy from the frame pointer games.

So quite honestly, a lot of this smells very much like "security
theater" to me. Fancy code that makes things look really complex and
fancy.  But where much of it seems to be quite dubious.

What are we going to do next? Ask people to remove their shoes while
compiling the kernel in the name of "security"?

Tell me I'm wrong. Tell me I misread the plugin, and it's stronger
than my reading implies.

But that would just be a stronger argument for actually having a
description of what the plugin does.  See my point (d) above.

                  Linus