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:   Sat, 23 Jun 2018 11:17:03 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Fenghua Yu <fenghua.yu@...el.com>
cc:     Ingo Molnar <mingo@...e.hu>,
        "H. Peter Anvin" <hpa@...ux.intel.com>,
        Ashok Raj <ashok.raj@...el.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Rafael Wysocki <rafael.j.wysocki@...el.com>,
        Tony Luck <tony.luck@...el.com>,
        Alan Cox <alan@...ux.intel.com>,
        Ravi V Shankar <ravi.v.shankar@...el.com>,
        Arjan van de Ven <arjan@...radead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: Re: [RFC PATCH 02/16] x86/split_lock: Handle #AC exception for split
 lock in kernel mode

On Fri, 22 Jun 2018, Fenghua Yu wrote:
> On Fri, Jun 22, 2018 at 12:49:00PM +0200, Thomas Gleixner wrote:
> > On Sun, 27 May 2018, Fenghua Yu wrote:
> > > +static void wait_for_reexecution(void)
> > > +{
> > > +	while (time_before(jiffies, disable_split_lock_jiffies +
> > > +			   reenable_split_lock_delay))
> > > +		cpu_relax();
> > > +}
> > > +
> > > +/*
> > > + * TEST_CTL MSR is shared among threads on the same core. To simplify
> > > + * situation, disable_split_lock_jiffies is global instead of per core.
> > 
> > This patch surely earns extra points in the trainwreck engineering contest,
> > but that's not taking place on LKML.
> > 
> > The whole thing is simply:
> > 
> > handle_ac()
> > {
> > 	if (user_mode(regs)) {
> > 		 do_trap(AC, SIGBUS, ...);
> > 	} else {
> > 		disable_ac_on_local_cpu();
> > 		WARN_ONCE(1);
> > 	}
> > }
> 
> Should I add kernel parameter or control knob to opt-out the feature?

A simple command line option 'acoff' or something more sensible should be
ok. No sysfs knobs or whatever please. The Kconfig option is not required
either.

> I'm afraid firmware may hang system after handling split lock if the
> feature is enabled by kernel, e.g. "reboot" hits split lock in firmware
> and firmware hangs the system after handling #AC.

Have you observed the problem in reality? I mean why would 'reboot' be the
critical path? I'd rather expect that EFI callbacks or SMM 'value add'
would trip over it.

Vs. reboot. If that is the only problem then we might just have to clear
#AC enable before issuing it, but that does not need to be part of the
initial patch set. Its an orthogonal issue.

Thanks,

	tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ