linux-kernel - Re: [GIT PULL] Protection Keys (pkeys) support

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+55aFyN9=K0Kw4t0CT=jnfqUAE+PJPo-SvXyQJkHqac_vkyYg@mail.gmail.com>
Date:	Sun, 20 Mar 2016 19:21:27 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Dave Hansen <dave@...1.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	Andy Lutomirski <luto@...nel.org>
Subject: Re: [GIT PULL] Protection Keys (pkeys) support

So I finally got around to this one and the objtool pull request, and
note that there's a conflict in the arch/x86/Kconfig file.

And I'm not sending this email because the conflict would have been
hard to resolve - it was completely trivial. But the conflict does
show that once again people are starting to add the new options to the
end of the list, even though that list is supposedly sorted.

HOWEVER.

I didn't actually fix that up in the merge, because I think that those
options should be done differently anyway.

So all of these are under the "X86" config options as "select"
statements that are true for x86. However, all the new ones (and an
alarming number of old ones) aren't actually really "these are true
for x86". No, they are *conditionally* true for x86.

For example, if we were to sort those thing, the two PKEY-related
options would have to be split up:

        select ARCH_USES_HIGH_VMA_FLAGS         if
X86_INTEL_MEMORY_PROTECTION_KEYS
        select ARCH_HAS_PKEYS                   if
X86_INTEL_MEMORY_PROTECTION_KEYS

which would actually make it really nasty to see that they are related.

There's also a *lot* of those X86 selects that are "if X86_64". So
they really aren't x86 options, they are x86-64 options.

So instead of having a _huge_ list of select statements under the X86
option, why aren't those split up, and the select statements are
closer to the thing that actually controls them.

I realize that for many *common* options that really are "this
architecture uses the generic XYZ feature", the current "select" model
is really good. But it's starting to look really quite nasty for some
of these more specialized options, and I really think it would be
better to move (for example) the select for ARCH_HAS_PKEYS and
ARCH_USES_HIGH_VMA_FLAGS to actually be under the
X86_INTEL_MEMORY_PROTECTION_KEYS config option, rather than try to lie
and make it look like this is somehow some "x86 feature". It's much
more specific than that.

Anyway, it's all merged in my tree, but is going through the built
tests and I'll do a boot test too before pushing out. So no need to do
anything wrt these pull requests, this was more of a "Hmm, I really
think the x86 Kconfig file is getting pretty nasty".

               Linus