linux-kernel - RE: [PATCH v3 10/10] x86/split_lock: Handle #AC exception for split lock

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:   Wed, 13 Feb 2019 14:37:11 +0000
From:   "Yu, Fenghua" <fenghua.yu@...el.com>
To:     Ingo Molnar <mingo@...nel.org>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H Peter Anvin" <hpa@...or.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Michael Chan <michael.chan@...adcom.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        "Neri, Ricardo" <ricardo.neri@...el.com>,
        linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: RE: [PATCH v3 10/10] x86/split_lock: Handle #AC exception for split
 lock

> From: Ingo Molnar [mailto:mingo.kernel.org@...il.com] On Behalf Of Ingo Molnar
> > On Mon, Feb 11, 2019 at 11:53:39AM +0100, Ingo Molnar wrote:
> > > > +		do_trap(trapnr, signr, str, regs, error_code, BUS_ADRALN,
> NULL);
> > > > +	}
> > > > +}
> > >
> > > Is there any experience with how frequently this signal is killing
> > > user-space processes on a modern distro? Any expectation of how
> > > frequent such SIGBUS task terminations are going to be in the field?
> >
> > We did pretty intensive testing internally (zero day tests, many
> > engineers and testers use the patches in their dailly work, etc). So
> > far I'm not aware of any user space process hiting split lock issue. I
> > guess GCC or other compilers takes care of the issue already. Inline
> > assembly code may hit the issue if code is not right, but there are
> > fewer inline assembly code in user space.
> >
> > So far we only find two kernel split lock issues and fix them in the
> > first two patches in this patch set. We also find one BIOS split lock
> > issue internally which has been fixed in production BIOS.
> >
> > Thanks.
> 
> Ok, still, for binary compatibility's sake, could you please add a sysctl knob
> (root-only, etc.) and a kernel boot parameter that disables this check?

In this patch set, we already extend kernel option "clearcpuid=" to support CPU
cap flags. So "clearcpuid=split_lock_detection" can disable this split lock
check during boot time.

In next version, I will add "/sys/kernel/split_lock_detection" to enable or disable
the split lock check during run time.

Hopefully these work.

Thanks.

-Fenghua