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]

Message-ID: <20180515172908.GC244301@romley-ivt3.sc.intel.com>
Date:   Tue, 15 May 2018 10:29:09 -0700
From:   Fenghua Yu <fenghua.yu@...el.com>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     Fenghua Yu <fenghua.yu@...el.com>,
        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 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).

I guess how to improve boot time is still a concern for client and VM.
If split lock issue can be identified and fixed in boot time, it just
helps and dosn't hurt anything.

Turning on the feature during boot time makes user easier to identify
any split lock issue not just during boot time and also run time.

Having said that, there is a sysfs interface in patch #10 that allows
user to turn on/off the feature during boot time.

Does that sound better?

Thanks.

-Fenghua