linux-kernel - Re: [PATCH 09/15] x86/split_lock: Explicitly enable or disable #AC for split locked accesses

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]

Date:   Wed, 16 May 2018 09:37:33 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Fenghua Yu <fenghua.yu@...el.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
        "H. Peter Anvin" <hpa@...ux.intel.com>,
        Ashok Raj <ashok.raj@...el.com>,
        Ravi V Shankar <ravi.v.shankar@...el.com>,
        Tony Luck <tony.luck@...el.com>,
        Rafael Wysocki <rafael.j.wysocki@...el.com>,
        Arjan van de Ven <arjan@...radead.org>,
        Alan Cox <alan@...ux.intel.com>, x86 <x86@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 09/15] x86/split_lock: Explicitly enable or disable #AC
 for split locked accesses

On 05/15/2018 10:29 AM, Fenghua Yu wrote:
> On Tue, May 15, 2018 at 09:15:16AM -0700, Dave Hansen wrote:
>> On 05/14/2018 11:52 AM, Fenghua Yu wrote:
>>> By default, we don't set or clear the bit 29 in TEST_CTL MSR 0x33 and
>>> the bit is inherited from BIOS/hardware setting.
>>>
>>> The kernel parameter "split_lock_ac=on/off" explicitly sets or clears
>>> the bit during boot time.
>>
>> The more I think about this...  Why do we need this at boot anyway?
>> Surely boot-time kernel code can't cause performance issues in the same
>> way that untrusted repeated userspace can.  Why don't we just let
>> userspace turn this on?
> 
> Turning split lock earlier can captuer split lock performance issue
> in the boot path. Actually we did find two split lock issues during
> boot time by turning on the feature earlier (see patch 4 and 5).

Yeah, but you're going to have a pretty hard time arguing that these are
even close to the same class of issues that occur when all the CPUs are
up and userspace is pounding the system with split locks.

It also seems like the kind of thing that deserves to be a debugging
option, or Kconfig thing rather than a kernel command-line option that
has to live forever.