linux-kernel - Re: [PATCH] Fix i486 suspend to disk CR4 oops

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: <48A9F36B.8090509@zytor.com>
Date:	Mon, 18 Aug 2008 15:10:51 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Pavel Machek <pavel@...e.cz>
CC:	David Fries <david@...es.net>,
	"Maciej W. Rozycki" <macro@...ux-mips.org>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [PATCH] Fix i486 suspend to disk CR4 oops

Pavel Machek wrote:
> 
> Okay, can it happen that that cr4 is zero legitimately? If newer 486SX
> chips support cr4 but not coprocessor...?
> 									Pavel

Theoretically it can, but that means no features are enabled, so there 
is no need to enable the features.

The real question is if the following can happen: can it be such that we 
want CR4 to be zero in a situation where CR4 is nonzero to start out with?

The main bit in CR4 that could be set that we wouldn't want set would be 
CR4.PAE, so this could happen if there is a CPU with CR4.PAE but none of 
the other CR4 bits that we would normally set unconditionally.

I'm pretty sure this can't happen on any physical CPUs, since all 
physical CPUs supporting PAE would also support DE, MCE, and PGE.  It 
could possibly happen on a virtual CPU, although it is of course 
extremely unlikely we'd get there with CR4 not zero to start out with.

Still, it is at least theoretically wrong.

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