linux-kernel - Re: [PATCH] fix i486 boot failure due to stale %ds

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 4 Nov 2007 16:15:21 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Mikael Pettersson <mikpe@...uu.se>,
	linux-kernel@...r.kernel.org, mingo@...hat.com, tglx@...utronix.de
Subject: Re: [PATCH] fix i486 boot failure due to stale %ds

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/