i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)

["H. J. Lu" <hjl@lucon.org>]

It turns out that 2.4 kernel has

arch/i386/kernel/process.c:     asm volatile("movl %%" #seg ",%0":"=m" (*(int *)&(value)))
arch/i386/kernel/process.c:     asm volatile("movl %%fs,%0":"=m" (*(int *)&prev->fs));
arch/i386/kernel/process.c:     asm volatile("movl %%gs,%0":"=m" (*(int *)&prev->gs));
arch/x86_64/kernel/process.c:   asm("movl %%gs,%0" : "=m" (p->thread.gsindex));
arch/x86_64/kernel/process.c:   asm("movl %%fs,%0" : "=m" (p->thread.fsindex));
arch/x86_64/kernel/process.c:   asm("movl %%es,%0" : "=m" (p->thread.es));
arch/x86_64/kernel/process.c:   asm("movl %%ds,%0" : "=m" (p->thread.ds));
arch/x86_64/kernel/process.c:   asm volatile("movl %%es,%0" : "=m" (prev->es));
arch/x86_64/kernel/process.c:   asm volatile ("movl %%ds,%0" : "=m" (prev->ds));

2.6 kernel has

arch/i386/kernel/process.c:     asm volatile("movl %%fs,%0":"=m" (*(int *)&prev->fs));
arch/i386/kernel/process.c:     asm volatile("movl %%gs,%0":"=m" (*(int *)&prev->gs));
arch/x86_64/kernel/process.c:   asm("movl %%gs,%0" : "=m" (p->thread.gsindex));
arch/x86_64/kernel/process.c:   asm("movl %%fs,%0" : "=m" (p->thread.fsindex));
arch/x86_64/kernel/process.c:   asm("movl %%es,%0" : "=m" (p->thread.es));
arch/x86_64/kernel/process.c:   asm("movl %%ds,%0" : "=m" (p->thread.ds));
arch/x86_64/kernel/process.c:   asm volatile("movl %%es,%0" : "=m" (prev->es));
arch/x86_64/kernel/process.c:   asm volatile ("movl %%ds,%0" : "=m" (prev->ds));
arch/x86_64/kernel/process.c:           asm volatile("movl %%fs,%0" : "=g" (fsindex));
arch/x86_64/kernel/process.c:           asm volatile("movl %%gs,%0" : "=g" (gsindex));

The new assembler will disallow them since those instructions with
memory operand will only use the first 16bits. If the memory operand
is 16bit, you won't see any problems. But if the memory destinatin
is 32bit, the upper 16bits may have random values. The new assembler
will force people to use

	mov (%eax),%ds
	movw (%eax),%ds
	movw %ds,(%eax)
	mov %ds,(%eax)

Will it be a big problem for kernel people?

BTW, I haven't checked glibc yet. It may have similar issues.

H.J.
---
On Fri, Mar 25, 2005 at 06:05:06PM -0800, H. J. Lu wrote:
> X86 segment register access is a special. We can move between a segment
> register and a 16/32/64bit general-purpose register. But we can only
> move between a segment register and a 16bit memory address. The current
> assembler allows "movl (%eax),%ds", but doesn't allow "movq %rax,%ds".
> The disassembler display "movl (%eax),%ds". This patch tries to fix
> those.
> 
> 
> H.J.
> ----
> gas/testsuite/
> 
> 2005-03-25  H.J. Lu  <hongjiu.lu@intel.com>
> 
> 	* gas/i386/i386.exp: Run segment and inval-seg for i386. Run
> 	x86-64-segment and x86-64-inval-seg for x86-64.
> 
> 	* gas/i386/intel.d: Expect movw for moving between memory and
> 	segment register.
> 	* gas/i386/naked.d: Likewise.
> 	* gas/i386/opcode.d: Likewise.
> 	* gas/i386/x86-64-opcode.d: Likewise.
> 
> 	* gas/i386/opcode.s: Use movw for moving between memory and
> 	segment register.
> 	* gas/i386/x86-64-opcode.s: Likewise.
> 
> 	* : Likewise.
> 
> 	* gas/i386/inval-seg.l: New.
> 	* gas/i386/inval-seg.s: New.
> 	* gas/i386/segment.l: New.
> 	* gas/i386/segment.s: New.
> 	* gas/i386/x86-64-inval-seg.l: New.
> 	* gas/i386/x86-64-inval-seg.s: New.
> 	* gas/i386/x86-64-segment.l: New.
> 	* gas/i386/x86-64-segment.s: New.
> 
> include/opcode/
> 
> 2005-03-25  H.J. Lu  <hongjiu.lu@intel.com>
> 
> 	* i386.h (i386_optab): Don't allow the `l' suffix for moving
> 	moving between memory and segment register. Allow movq for
> 	moving between general-purpose register and segment register.
> 
> opcodes/
> 
> 2005-03-25  H.J. Lu  <hongjiu.lu@intel.com>
> 
> 	* i386-dis.c (SEG_Fixup): New.
> 	(Sv): New.
> 	(dis386): Use "Sv" for 0x8c and 0x8e.
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/