linux-kernel - Re: [PATCH v11] x86/split_lock: Enable split lock detection by kernel

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, 15 Jan 2020 14:27:54 -0800
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        H Peter Anvin <hpa@...or.com>,
        Ashok Raj <ashok.raj@...el.com>,
        Ravi V Shankar <ravi.v.shankar@...el.com>,
        linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: Re: [PATCH v11] x86/split_lock: Enable split lock detection by kernel

On Mon, Jan 13, 2020 at 09:55:21PM -0800, Sean Christopherson wrote:
> On Fri, Jan 10, 2020 at 11:24:09AM -0800, Luck, Tony wrote:

All comments accepted and code changed ... except for these three:

> > +#define TIF_SLD			18	/* split_lock_detect */
> 
> A more informative name comment would be helpful since the flag is set when
> SLD is disabled by the previous task.  Something like? 
> 
> #define TIF_NEED_SLD_RESTORE	18	/* Restore split lock detection on context switch */

That name is more informative ... but it is also really, really long. Are
you sure?

> > +bool handle_user_split_lock(struct pt_regs *regs, long error_code)
> > +{
> > +	if ((regs->flags & X86_EFLAGS_AC) || sld_state == sld_fatal)
> > +		return false;
> 
> Maybe add "|| WARN_ON_ONCE(sld_state != sld_off)" to try to prevent the
> kernel from going fully into the weeds if a spurious #AC occurs.

Can a spurious #AC occur? I don't see how.

> > @@ -242,7 +243,6 @@ do_trap(int trapnr, int signr, char *str, struct pt_regs *regs,
> >  {
> >  	struct task_struct *tsk = current;
> >  
> > -
> 
> Whitespace.
> 
> >  	if (!do_trap_no_signal(tsk, trapnr, str, regs, error_code))
> >  		return;

I'm staring at the post patch code, and I can't see what whitespace
issue you see.

-Tony