linux-kernel - Re: [RFC 00/15] x86_64: Optimize percpu accesses

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: <48752F5D.9090807@zytor.com>
Date:	Wed, 09 Jul 2008 17:36:29 -0400
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Christoph Lameter <cl@...ux-foundation.org>
CC:	Jeremy Fitzhardinge <jeremy@...p.org>, Ingo Molnar <mingo@...e.hu>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Mike Travis <travis@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jack Steiner <steiner@....com>, linux-kernel@...r.kernel.org,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [RFC 00/15] x86_64: Optimize percpu accesses

Christoph Lameter wrote:
> Jeremy Fitzhardinge wrote:
> 
>> No, it makes no difference.  %gs:X always has a 32-bit offset in the
>> instruction, regardless of how big X is:
>>
>>     mov %eax, %gs:0
>>     mov %eax, %gs:0x1234567
>> ->
>>   0:    65 89 04 25 00 00 00 00    mov    %eax,%gs:0x0
>>   8:    65 89 04 25 67 45 23 01    mov    %eax,%gs:0x1234567
> 
> The processor itself supports smaller offsets.

No, it doesn't, unless you have a base register.  There is no naked 
disp8 form, and disp16 is only available in 16- or 32-bit mode (and in 
32-bit form it requires a 67h prefix.)

> Note also that the 32 bit offset size limits the offset that can be added to the segment register. You either need to place the per cpu area either in the last 2G of the address space or in the first 2G. The zero based approach removes that limitation.

The offset is either ±2 GB from the segment register, or ±2 GB from the 
segment register plus %rip.  The latter is more efficient.

The processor *does* permit a 64-bit absolute form, which can be used 
with a segment register, but that one is hideously restricted (only move 
to/from %rax) and bloated (10 bytes!)

>>   0:    65 89 05 00 00 00 00     mov    %eax,%gs:0(%rip)        # 0x7
> 
> RIP relative also implies a 32 bit offset meaning that the code cannot be more than 2G away from the per cpu area.

Not from the per cpu area, but from the linked address of the per cpu 
area (the segment register base can point anywhere.)

In our case means between -2 GB and a smallish positive value (I believe 
it is guaranteed to be 2 MB or more.)

Being able to use %rip-relative forms would save a byte per reference, 
which is valuable.

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