linux-kernel - Re: [GIT PULL] x86 setup: correct booting on 486 (revised)

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:	Tue, 06 Nov 2007 09:57:51 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Mikael Petterson <mikpe@...uu.se>
Subject: Re: [GIT PULL] x86 setup: correct booting on 486 (revised)

Eric W. Biederman wrote:
>>
>> I think it should be sparsely used, but stuff like simple end markers is pretty
>> much what it's good for.
>>
>> The main reason I want to avoid adding another header field is that the header
>> is a finite resource; one of the many poor decisions in its original design was
>> using a 2-byte jump at the top, so address 0x281 is the end of the universe.
> 
> That was fixed long ago (by having a 4 byte reserved field in the middle) that
> we can do a two byte jump and then do a farther jump from there to the 16bit
> code.  So as long as we actually use discipline and really reserve
> the field for a further jump there should be no need for 0x281 being the end
> of the universe.
> 

That's not the only complication.  The thing that concern me more is 
boot loaders using the jump as a length indicator, and there is really 
very little chance to test that out safely, except perhaps by breaking 
it immediately (by adding a 16-byte jump at the end; that way we provide 
a minimum of overlap for boot loader authors.)

That being said, I don't see any such field (bootsect_kludge could be 
recycled, arguably, and pad2 is three bytes which is enough for a 16-bit 
jump.)

At the moment, though, that would only push the maximum from 0x281 to 
0x290, then we run into the next field in struct boot_params.  Although 
this field can also be relocated over time, it once again shows that 
breaking this particular limit is nontrivial, and that we're better off 
trying to avoid pushing it.

However, with a little discipline I think we can make 0x281 last us for 
the usable lifetime of this format.  In the 10 years since the 2.00 
format was created, we have only added 36 bytes of header, and we have 
57 bytes left (plus 5 bytes of pad and 6 bytes of recyclable field.) 
When we get closer to full, if we haven't already created a mechanism 
making field additions obsolete I think we would be better off creating 
a pointer to a secondary header than trying to break the limitations 
involved in the current header format.

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