On Sun, 4 Nov 2007, H. Peter Anvin wrote:
>
> Joy. Apparently the Intel documentation is actually self-inconsistent.
> Section 9.9.1, page 9-17 does indeed have the "far jump or call" injunction,
> whereas the sample code in section 9.10.1, page 9-27, line 180 does a near
> jump!
See the older code. There's literally two different issues:
- flushing the pipeline. Using a regular short jump is not only
sufficient, but is a good idea because the byte sequence has no
dependency on any modes, so it is guaranteed to flush any pipeline
without itself having any behavioural differences.
This part is a no-op for later CPU's: they simply won't care, since
they serialize the pipeline on their own (and the have to, since a
correctly predicted branch no longer flushes it anyway).
So this is purely a i386/i486 thing (and *maybe* Pentium, but
definitely not PPro and later)
- setting up the proper protected mode bits in CS. This obviously changes
the CS itself, and anything that depends on any shadow state in CS will
need this to happen first. In practice, very few things really depend
on the CS bits, of course.
Doing them back-to-back is obviously the best situation, and leaves the
minimum footprint for any dubious undocumented behaviour. That said, while
the whole thing with shadow segment table is strictly speaking probably
"undocumented" behaviour, it's certainly a reality, and lots of code has
depended on the fact that even though you haven't reloaded a segment, the
segment continues to work across mode switches thanks to the shadow table.
So it's not like there's any real secret to what happens until the
longjump has been executed: we continue running with the CS shadow table
entry being in "real mode", and the effect of that tends to be minimal.
But in theory, the CS table entry could affect how instructions actually
act, even though in practice I don't think it really has any real effect
outside of the actual segment access check (and certainly did not in the
i386/i486 timeframe).
So I'd suggest having both jumps back-to-back, but realistically, the
first regular short jump is actually the one that is more important.
That's the one that really matters on i386/i486 class machines, and later
CPU's will generally do the right thing even with _neither_ jump there.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
