linux-kernel - Re: Qemu problems in -next with 's390/spinlock: add niai spinlock hints'

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: <20170726072654.GE3218@osiris>
Date:   Wed, 26 Jul 2017 09:26:54 +0200
From:   Heiko Carstens <heiko.carstens@...ibm.com>
To:     Martin Schwidefsky <schwidefsky@...ibm.com>
Cc:     Guenter Roeck <linux@...ck-us.net>, linux-kernel@...r.kernel.org,
        linux-s390@...r.kernel.org
Subject: Re: Qemu problems in -next with 's390/spinlock: add niai spinlock
 hints'

> > > Hmm, I though that NIAI is a NOP on older machines. A runtime check for
> > > the facility bit is out of the question as the NIAI-7 gets inlined in
> > > the spin_unlock code. So yes, the only available fix is to make the
> > > NIAI hinting conditional on zEC12. Which is quite ugly as we would need
> > > an architecture level set to zEC12 for the distribution kernel to make
> > > use of NIAI.  
> > 
> > Alternatively you could generate a four-byte nop, and replace that at IPL
> > time with the needed NIAI instruction, if the facility is available. Some
> > sort of "alternative" code patching infrastructure that x86 already has.
> > Not sure if it is worth it, however...
> 
> Patching all spin_unlock inlines? There are a lot of callers for this
> function. We could think about an out-of-line spin_unlock and patch this
> single function but then we'd loose the advantage of inlining.
> I do not think it is worthwhile.
> 
> I pushed an updated patch to the features branch of s390/linux. Should
> be in linux-next tomorroy. Thanks. 

The idea would be to generate an extra section that contains the addresses
of the to be patched instructions, and how they need to be patched.  That
section, plus the code that will do the patching could reside in init
data/code sections and would be discarded after. So the additional memory
overhead after initialization would be close to zero.

However an ifdef is fine as well ;)