lkml.org 
[lkml]   [2004]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.187 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site