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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190213081450.GA53242@gmail.com>
Date:   Wed, 13 Feb 2019 09:14:50 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Fenghua Yu <fenghua.yu@...el.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, H Peter Anvin <hpa@...or.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Ashok Raj <ashok.raj@...el.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Michael Chan <michael.chan@...adcom.com>,
        Ravi V Shankar <ravi.v.shankar@...el.com>,
        Ricardo Neri <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


* Fenghua Yu <fenghua.yu@...el.com> wrote:

> 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?

Looks good otherwise.

Thanks,

	Ingo