linux-kernel - Re: [PATCH 20/20] x86_64: Move CPU verification code to common file

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:	Sat, 18 Nov 2006 09:06:21 +0100
From:	Andi Kleen <ak@...e.de>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Oleg Verych <olecom@...wer.upol.cz>,
	LKML <linux-kernel@...r.kernel.org>, vgoyal@...ibm.com,
	akpm@...l.org, rjw@...k.pl, ebiederm@...ssion.com,
	Reloc Kernel List <fastboot@...ts.osdl.org>, pavel@...e.cz,
	magnus.damm@...il.com
Subject: Re: [PATCH 20/20] x86_64: Move CPU verification code to common file

> However, this test should probably be pushed earlier, into setup.S, 
> where executing a BIOS-clean reboot is much easier.

It's already in there in fact. It wasn't originally, until we discovered
that there is no way to output a message in head.S when you're
using vesafb. The only way to give a visible error is to do it 
before the video switched.

The old test was kept, although it's redundant.

This means Vivek/Eric added it now to the SMP trampoline and ACPI
S3 resume too, but there it is technically redundant too.

But you have to spin, otherwise the user cannot see what is wrong
(and that is much more important than your obscure possibility
of automatic fallback -- inserting the wrong CD is pretty common) 

Finding panic=.. would require writing a command line parser in 16bit assembly.
I have my doubts that's a good use of anyone's time.

-Andi (who wonders why he wastes so much time writing about this thing) 
-
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/