linux-kernel - Re: [PATCH v2 1/4] x86/split_lock: Enumerate #AC exception for split locked access feature

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:   Thu, 12 Jul 2018 22:00:17 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Dave Hansen <dave.hansen@...el.com>
cc:     Fenghua Yu <fenghua.yu@...el.com>,
        Eduardo Habkost <ehabkost@...hat.com>,
        Ingo Molnar <mingo@...hat.com>, H Peter Anvin <hpa@...or.com>,
        Ashok Raj <ashok.raj@...el.com>,
        Alan Cox <alan@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Rafael Wysocki <rafael.j.wysocki@...el.com>,
        Tony Luck <tony.luck@...el.com>,
        Ravi V Shankar <ravi.v.shankar@...el.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        x86 <x86@...nel.org>,
        Vedvyas Shanbhogue <vedvyas.shanbhogue@...el.com>
Subject: Re: [PATCH v2 1/4] x86/split_lock: Enumerate #AC exception for split
 locked access feature

On Wed, 11 Jul 2018, Dave Hansen wrote:

> On 07/10/2018 12:47 PM, Thomas Gleixner wrote:
> > And please tell your hardware people that they should stop creating
> > features which are not enumerated in one way or the other. That's just a
> > pain all over the place. Boot code, kernel, virt, tools ....
> 
> Assuming it's too late to get CPUID or MSR enumeration... (I haven't
> given up on this yet, btw)

Given the fact that they can add cpuid bits and msr and msr bits within no
time via ucode, assuming too late is the wrong approach.

As this is not yet existing silicon, the ucode patch space should be more
than sufficient for that. Or is it already reserved for the next
speculation disaster?

Btw, when is this going to be real silicon?

> How about we #define a Linux-defined X86_FEATURE_SPLIT_LOCK_AC (or
> whatever) for now.  When the hardware that has this bit for real shows
> up, we move the #define to the "correct" place, like if it is a part of
> an existing cpufeature leaf.
> 
> We also do a new setcpuid= boot option that behaves like the existing
> clearcpuid=.  That option is used by the obscure, specialized split lock
> detectino users to set the software cpufeature bit.
> 
> That way, we can merged this code *with* CPUID detection, and the only
> thing we have to do in the future is move the X86_FEATURE_SPLIT_LOCK_AC
> define to a better place.
> 
> It might be nice to make the setcpuid= thing use strings instead of
> numbers that _can_ change from kernel-to-kernel, but that's kinda an
> implementation detail.  If we have strings, maybe we can start using
> clearcpuid=pku instead of our endless list of (new) boot parameters like
> nopku, nosmap, nosmep, etc...

I might be persuaded to accept the setcpuid= magic if, and only if the
CPUID leaf and bit is documented upfront and going to stay the same.

If that's not the case we just open the door for the HW folks to ignore
proper enumeration forever.

Thanks,

	tglx