Those are the same thing, byte reversed. (The x86's are
little-endian, so when you put:
long main = 0xc8c70ff0;
into a C source file, the bytes at the address of 'main' are f0, 0f,
c7, c8 in that order, least-significant byte first. Branch to that
address, and the instruction executed is f0 0f c7 c8... kaboom).
> Thanks to Robert S.
> Thau <rst@ai.mit.edu> for insight on the early discussions of this
> defect.
I have insight on this?
BTW, workarounds for this bug have been known for a few days, but they
would utterly kill performance. (In detail: the lockup doesn't happen
if the illegal instruction handler is in L1 cache, so one way of
dealing with the problem is to lock it there. However, this keeps
anything else from ever getting into the L1 cache, which utterly
destroys performance).
The very latest is that BSDI (vendors of a commercial BSD-derivative
unix-alike for PC hardware) claim they have identified a fix which is
actually useful; the details apparently involve use of deep magic to
force a page fault on illegal instruction (and some other) traps, by
putting the trap handler, or vector, or something, on a nonexistant
page. The Linux folks are aware of this and Linus has incorporated a
preliminary version of the fix (for which he credits Ingo Molnar) into
their development tree. There is a performance hit for the handling
of the affected traps, but it's merely annoying, not devastating.
(The Cyrix bug I may have mentioned, BTW, can be worked around in
software fairly easily by diddling a few chip-control registers, and
does not require any really serious skulduggery by the OS).
So, um, what's Microsoft doing about this?
rst