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: <472E551E.2010507@zytor.com>
Date:	Sun, 04 Nov 2007 15:26:22 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Linus Torvalds <torvalds@...ux-foundation.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

Linus Torvalds wrote:
> 
> On Sun, 4 Nov 2007, H. Peter Anvin wrote:
>>     
>>     Apparently, the 486DX4 does not correctly serialize a mov to %cr0, so
>>     we really do need the far jump immediately afterwards.
> 
> Hmm. I'm not sure I agree with the commit message.
> 
> This is documented behaviour on i386 and i486: instruction decoding is 
> decoupled from execution, so things that change processor mode have to do 
> a jump to make sure that %cr0 changes take effect.
> 

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'm not entirely sure that it needs to be a long-jump, btw. I think any
> regular branch is sufficient. You obviously *do* need to make the long 
> jump later (to reload %cs in protected mode), but I'm not sure it's needed 
> in that place. I forget the exact rules (but they definitely were 
> documented).

That's exactly the issue here.  The code without this patch deferred the 
long jump until after the segment loads, this worked on all processors 
except, apparently, the 486DX4.  Hence, move the ljmp up to the earliest 
possible location.

	-hpa
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ