linux-kernel - Re: [PATCH 1/3] x86: enlightenment for ticket spinlocks

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:	Tue, 02 Feb 2010 09:04:33 +0000
From:	"Jan Beulich" <JBeulich@...ell.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	<mingo@...e.hu>, "Jeremy Fitzhardinge" <jeremy@...p.org>,
	<tglx@...utronix.de>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] x86: enlightenment for ticket spinlocks - base
	 implementation

>>> "H. Peter Anvin" <hpa@...or.com> 01.02.10 23:54 >>>
>I'm really not very happy with the way the asm statement is chopped to
>bits here.  It is quite frankly much cleaner to have a little bit of
>code replication and have two separate clean asm/alternative_io
>implementations.

Yeah, that's a tradeoff I wasn't sure about either. I can easily change
this, but to me it seemed more desirable to have less duplication.

>A thought, however:
>
>the sequence "rep;nop; movb %1,%b0" should be enough bytes to be able to
>overwrite it with a call instruction.  I am not sure if the existing

Hmm, yes, including the branch there would be 6 bytes guaranteed.

>macros allow for overwriting part of an asm statement, but it might be
>an interesting thing to do.  That should eliminate the funnies you have

They don't currently, but adding an offset shouldn't be that difficult.
The goal certainly was to avoid touching the alternative instructions
infrastructure more than absolutely necessary.

>with rip-relative addressing (which may very well be the preferred
>addressing modes.)  It should also give you the return address without
>having to play games with pushing it onto the stack as anything other
>than a return address...

Yes, for the locking path. The unlocking path could also be done with
a "proper" call (even without adjustments to the alternative instructions
data structures), but would introduce more branches in the inline stub.
It's not clear to me whether that's better.

So if you want me to give that a try, I certainly will, provided the
alternative instructions adjustments needed won't increase the
resistance to the patch.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/