linux-kernel - Re: [PATCH] x86/asm: avoid mnemonics without type suffix

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: <51E443AD.3020907@zytor.com>
Date:	Mon, 15 Jul 2013 11:47:09 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	Ramkumar Ramachandra <artagnon@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Andi Kleen <ak@...ux.intel.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Eli Friedman <eli.friedman@...il.com>,
	Jim Grosbach <grosbach@...le.com>,
	Stephen Checkoway <s@...tak.org>, LLVMdev <llvmdev@...uiuc.edu>
Subject: Re: [PATCH] x86/asm: avoid mnemonics without type suffix

On 07/14/2013 12:23 PM, Jeremy Fitzhardinge wrote:
> (resent without HTML)
> 
> On 07/14/2013 05:56 AM, Ramkumar Ramachandra wrote:
>> 1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30)
>> changed a bunch of btrl/btsl instructions to btr/bts, with the following
>> justification:
>>
>>   The inline assembly for the bit operations has been changed to remove
>>   explicit sizing hints on the instructions, so the assembler will pick
>>   the appropriate instruction forms depending on the architecture and
>>   the context.
>>
>> Unfortunately, GNU as does no such thing, and the AT&T syntax manual
>> [1] contains no references to any such inference.  As evidenced by the
>> following experiment, gas always disambiguates btr/bts to btrl/btsl.
>> Feed the following input to gas:
>>
>>   btrl	$1, 0
>>   btr	$1, 0
>>   btsl	$1, 0
>>   bts	$1, 0
> 
> When I originally did those patches, I was careful make sure that we
> didn't give implied sizes to operations with only immediate and/or
> memory operands because - in general - gas can't infer the operation
> size from such operands. However, in the case of the bit test/set
> operations, the memory access size is not really derived from the
> operation size (the SDM is a bit vague), and even if it were it would be
> an operation rather than semantic difference.  So there's no real
> problem with gas choosing 'l' as a default size in the absence of any
> explicit override or constraint.
> 
>> Check that btr matches btrl, and bts matches btsl in both cases:
>>
>>   $ as --32 -a in.s
>>   $ as --64 -a in.s
>>
>> To avoid giving readers the illusion of such an inference, and for
>> clarity, change btr/bts back to btrl/btsl.  Also, llvm-mc refuses to
>> disambiguate btr/bts automatically.
> 
> That sounds reasonable for all other operations because it makes a real
> semantic difference, but overly strict for bit operations.
> 

To be fair, we *ought to* be able to do something like:

	asm volatile(LOCK_PREFIX "bts%z0 %1,%0"
 			: BITOP_ADDR(addr) : "Ir" (nr) : "memory");

... but some older version of gcc are broken and emit "ll" rather than
"q".  Furthermore, since that would actually result in *worse* code
emitted overall (unnecessary REX prefixes), I'm not exactly happy on the
idea.

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