linux-kernel - Re: arch/i386/boot rewrite, and all the hard-coded video cards

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:	Mon, 30 Apr 2007 20:34:21 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Dave Jones <davej@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Andi Kleen <ak@...e.de>, Jeff Garzik <jeff@...zik.org>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Linus Torvalds <torvalds@...l.org>
Subject: Re: arch/i386/boot rewrite, and all the hard-coded video cards

"H. Peter Anvin" <hpa@...or.com> writes:

> Dave Jones wrote:
>> 
>> I don't really care, but I wonder what the point is of rewriting something
>> that hardly ever gets notably changed, and is rarely (if ever?) a source
>> of bugs.  It might be crufty old assembly, but it's worked well for years.
>> 
>
> Well, it hardly gets notably changed because it is a nightmare to get it
> right, and when it is changed, it is likely to be a bug magnet.  The
> sheer number of bugs I have found in the process of figuring out what
> the current code is doing is pretty much evidence of that.  I'm
> surprised fewer bugs are actually manifest, but I guess that shows how
> little of the code is actually used.

This sounds plausible.  Although I don't recall seeing that many bugs.
Even if we don't merge your changes the knowledge of the code gained
should be invaluable for future maintenance purposes.  I reserve judgement
on the sanity of the rewrite until I see the patches.

> The "solution" that people have been employing has been to require the
> use of special bootloaders for different environments, which enter at
> code32_start instead.  Hardly an improvement.

This part is incorrect.  Every example I have seen of entering in at
a different entry point is because the environment does not support
16bit BIOS calls.  So the easiest way to skip the kernels BIOS calls
is to skip setup.S.

Not that the x86 BIOS is bad.  It is nearly a marvel in it's simplicity
and ubiquitousness, but it isn't everywhere, and it doesn't make
sense for it to be everywhere.

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