Messages in this thread | | | From | Gabriel Paubert <> | Date | Wed, 8 Sep 2004 14:12:36 +0200 | Subject | Re: PROBLEM: x86 alignment check bug |
| |
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 - 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/
| |