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]

Message-ID: <20200115225724.GA18268@linux.intel.com>
Date:   Wed, 15 Jan 2020 14:57:24 -0800
From:   Sean Christopherson <sean.j.christopherson@...el.com>
To:     "Luck, Tony" <tony.luck@...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 Wed, Jan 15, 2020 at 02:27:54PM -0800, Luck, Tony wrote:
> 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:

Sounds like you're also writing code, in which case you should give
yourself credit with your own Co-developed-by: tag.

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

Not at all.  I picked a semi-arbitrary name that was similar to existing
TIF names, I'll defer to anyone with an opinion.

> > > +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.

It's mostly paranoia, e.g. if sld_state==sld_off but the MSR bit was
misconfigured.  No objection if you want to omit the check.

> > > @@ -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.

There's a random newline removal in do_trap().  It's a good change in the
sense that it eliminates an extra newline, bad in the sense that it's
unrelated to the rest of the patch.