linux-kernel - Re: Multiple local register variables w/ same register

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 19 Nov 2013 22:13:00 +0000
From:	Måns Rullgård <mans@...sr.com>
To:	Richard Henderson <rth@...ddle.net>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Will Deacon <will.deacon@....com>,
	linux-kernel@...r.kernel.org,
	Catalin Marinas <Catalin.Marinas@....com>,
	lttng-dev@...ts.lttng.org, Nathan Lynch <Nathan_Lynch@...tor.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jakub Jelinek <jakub@...hat.com>,
	"gcc\@gcc.gnu.org" <gcc@....gnu.org>
Subject: Re: Multiple local register variables w/ same register

Richard Henderson <rth@...ddle.net> writes:

> On 11/20/2013 03:33 AM, Peter Zijlstra wrote:
>> On Tue, Nov 19, 2013 at 05:02:20PM +0000, Mathieu Desnoyers wrote:
>>> Unfortunately I don't have a ARM cross-compiler setup ready. Nathan
>>> could test it for us though.
>>>
>>> It might shuffle things around enough to work around the issue, but
>>> with the approach you propose, I would be concerned about the
>>> compiler being within its rights to reorder the code into the
>>> following sequence:
>>>
>>> struct thread_info *ptra, *ptrb;
>>>
>>> ptra = current_thread_info();
>>> /*
>>>  * each current_thread_info() would have a clobber on *sp, which orders
>>>  * those two wrt each other.
>>>   */
>>> ptrb = current_thread_info();
>>>
>>> load from ptra->preempt_count;
>>> /*
>>>  * however, the following accesses that depend on ptra and ptrb could be
>>>  * reordered if the compiler has no way to know that ptra and ptrb are
>>>  * aliased.
>>>  */
>>> store to ptrb->preempt_count;
>>>
>>> One question that might be worth asking: with the local register variable
>>> extension (http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Local-Reg-Vars.html#Local-Reg-Vars)
>>> (thanks to Jakub for the pointer), should the compiler consider two
>>> variables bound to the same register as being aliased or not ?
>>> AFAIU, local reg vars appear to be architecture-specific, so maybe
>>> there is something fishy on ARM ?
>
> It appears not:
>
> int __attribute__((noinline)) f(void)
> {
>   {
>     register int x __asm__("eax");
>     x = 1;
>   }
>   {
>     register int y __asm__("eax");
>     return ++y;
>   }
> }
>
> extern void abort(void);
>
> int main(void)
> {
>   if (f() != 2)
>     abort();
>   return 0;
> }
>
> Anyone see anything wrong with the testcase?  Do we thing this sort of
> thing ought to work, perhaps with scopes lengthened?

In general, I see no reason why the compiler should be forced to
preserve a register between blocks like that.  Relying on a value
magically appearing in a general-purpose register seems to me fragile at
best.  Code like this adds inter-block dependencies that would not
normally be there, and I'd rather not gamble on how the various
optimisation passes deal with it, if it is even noticed at all.

What happens if you some code clobbering eax (e.g. a function call)
between those two blocks?  What do you think should happen?

-- 
Måns Rullgård
mans@...sr.com
--
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/