Re: PROBLEM: x86 alignment check bug

[Gabriel Paubert <paubert@iram.es>]

On Tue, Sep 07, 2004 at 05:08:07PM -0700, David S. Miller wrote:
> On Tue, 07 Sep 2004 16:51:41 -0700
> Zachary Amsden <zach@vmware.com> wrote:
> 
> > Clearly, this is not correct.  Considering how difficult the fix is (the 
> > kernel must disassemble the faulting instruction and use register 
> > information to determine the faulting address),
> 
> While it is more difficult to disassemble x86 opcodes,
> what you describe is exactly how we handle this on
> sparc64.  In fact we do opcode decoding for most fault
> types.

For page faults, cr2 gives you the linear address, i.e., after
adding the base of the segment, which you can only find
by looking up the GDT and/or LDT for the correct segment.

Of course, the address decoding depends also of the size
attributes of the code segment (16 or 32 bits for i386, 
64 bits for x86_64) which needs also a lookup of CS in the
segment tables, and of a possible address prefix which 
affects the decoding. Of course this is fraught with race
if another thread modifies the LDT at the same time.

Then most instructions use a standard memory address
encoding, but there are a few exceptions which implicitly
use ESI and/or EDI. For the ones that use two memory 
addresses (movs/cmps), you'd have to even compute both 
addresses and decide which one is the unaligned one. 

I somehow suspect that Sparc is somewhat simpler to decode
than i386/x86_64 ;-)

Don't bloat the kernel with decoding this mess, please.
A helper library in user space, why not?

	Regards,
	Gabriel