linux-kernel - Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints

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:	Mon, 23 Jul 2007 11:05:17 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Andi Kleen <ak@...e.de>
CC:	Satyam Sharma <ssatyam@....iitk.ac.in>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	David Howells <dhowells@...hat.com>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>, jh@...e.cz
Subject: Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints

Andi Kleen wrote:
>> Whoa, thanks for explaining that to me -- I didn't know, obviously. I had
>> just written a test program that used "Ir" with an automatic variable
>> defined in the inline function (as is the case with these bitops) and
>> observed that even when I gave > 32 values, it would still work -- hence
>> my conclusion.
>>
>> However, the patch still stands, does it not? [ I will modify the
>> changelog, obviously. ] The thing is that we don't want to limit
>> @nr to <= 31 in the first place, or am I wrong again? :-)
> 
> These bit operations only allow 8 bit immediates, so 0..255 would
> be correct. N might work from the 4.1 docs, but I don't know if it works 
> in all old supported gccs (3.2+)
> 
> However I is definitely not wrong and most bit numbers are small anyways.
> 

"I" is correct.  The Intel documentation on this is highly confusing
(and has bugs in it), but it does unambiguously state:

"Some assemblers support immediate bit offsets larger than 31 by using
the immediate bit offset field in combination with the displacement
field in the memory operand ... The processor will ignore the high-order
bits if they are not zero."  AMD processors might be different for all I
know.

So unless gas is capable of doing this transformation (and it's not as
of binutils-2.17.50.0.6) "I" is what's needed here.

	-hpa

-
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/