linux-kernel - Re: [GIT PULL] x86 setup: correct booting on 486DX4

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]

Message-ID: <alpine.LFD.0.999.0711041546510.15101@woody.linux-foundation.org>
Date:	Sun, 4 Nov 2007 15:59:17 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Mikael Petterson <mikpe@...uu.se>,
	Eric Biederman <ebiederm@...ssion.com>
Subject: Re: [GIT PULL] x86 setup: correct booting on 486DX4

On Sun, 4 Nov 2007, H. Peter Anvin wrote:
> 
> It's not an instruction-decoding issue at all (that's a 16- vs 32-bit issue,
> which can only be changed by a ljmp).  Apparently the 486DX4 mis-executes the
> load to segment register, which is an EU function in that context.  (And yes,
> it's sort-of-documented behaviour in the sense that the documentation says "do
> things this way", but the Intel docs are unfortunately full of "do things this
> way" which don't make sense and occasionally are actively harmful, too.)

I still disagree.

I took out "Programming the 80386" just to check, and the documentation 
very clearly states that when changing the CR0 bits (I quote):

	"The program must execute a jump instruction immediately after 
	 changing the value of the PE bit in order to flush the execution 
	 pipeline of any instructions that may have been fetched in the 
	 wrong mode. [...]"

In other words, not only is this documented since day 1, it makes total 
sense, and they even said exactöy *why* that jump had to be done.

In fact, there's even a code example. It's page 624 in my copy of the 
book, and yes, it has a short jump to flush things, followed by a long 
jump. The code there looks like this:

	; *****
	; ** [4] Enter Protected Mode
	; *****
		SMSW AX
		OR   AX, PE
		LMSW AX
		JMP  Flush
	Flush:
		JMP far ptr Start32

which is pretty damn conclusive. It's documented, it has examples, it 
works. In other words, it's how you should do things.

And Linux always did it correctly. I don't understand why you disagree, 
and why Jeremy says

	"Having successfully broken the rules for a long time so far, 
	 maybe we can get away with still cutting corners..."

when the fact is, we used to *not* cut corners, we used to *not* break the 
rules, and what we used to do (a short jump immediately after setting PE) 
was exactly what Intel always said you should do, and there is no question 
what-so-ever about it.

So here's a suggestion:

 - make the code do what it used to do. A regular jump to flush the 
   pipeline. Which is what Intel has always said should be done.

and I really don't see that there is any argument about this. 

			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/