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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 06 Nov 2007 10:41:12 -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 have a hard time believing in discipline when I see the amount of
> not invented here and various oddball mistakes (cause by overlooking
> things) that seems to go on when extending the format.  We never
> needed to change the way the command line was passed, and we should
> have kept the longer jump where we had it.
> 

The longer jump was never documented, and so didn't exist.  There was 
definitely no way to rely on it.

The old command-line protocol had some really ugly interactions with the 
absolutely insane hoisting code from the pre-2.02 days.  I didn't have 
enough guts back then to scream and just rip it out, mostly because it 
took me a long time to figure out what the heck it really did (as 
opposed to what it claimed it did.)  That being said, we probably could 
have gotten away with leaving the protocol as-is while ripping out the 
guts (as I eventually did in the rewrite), even if the old protocol only 
had a 16-bit pointer.

> If we are going to through and add an additional pointer to a notes section
> let's please put a jump in there so we can make the header longer as
> we choose.

The problem is that that will only buy us 15 bytes, and eat up 3 (in 
practice, 4) of them...

It might be worth doing anyway, as it'd only break the 32-bit entrypoint 
users to reorganize struct boot_params.

	-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