linux-kernel - Re: [RFC PATCH 1/3] Replace paravirt_probe with "platform type" boot header field

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: <463B81BC.1030504@zytor.com>
Date:	Fri, 04 May 2007 11:55:56 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Rusty Russell <rusty@...tcorp.com.au>, Andi Kleen <ak@...e.de>,
	Chris Wright <chrisw@...s-sol.org>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Zachary Amsden <zach@...are.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 1/3] Replace paravirt_probe with "platform type" boot
 header field

Eric W. Biederman wrote:
> 
> You should be able to just include linux/screen_info.h instead of duplicating
> it inline.
> 

I'm working on it!!!!!

> I like the use of struct header in the middle of boot_params that
> seems like a nice maintenance device, although I'm not quite certain about
> 
> However you haven't documented the old swap_dev field in struct header.
> At least rdev still knows about it, so it is probably inappropriate to
> merge it with syssize.  Not that syssize is actually useful for anything
> in a modern system.

Actually, ROM bootloaders care about it, which is why it was expanded
out in boot loader protocol 2.04; see the documentation.

> So I just looked at what /sbin/kexec does so we know what to expect.
> If I have a bzImage I just grab the first setup_sects (i.e. setup.S) and make
> it the initial linux boot parameters, placing the command line immediately
> afterwards.
> 
> If I just have a vmlinux so I have to fake it I memset x86_linux_faked_param_header
> to zero, before placing in the values I care about.  And the size.  4K aka 1 page.
> Although I due put the command line at 2K, I think that is actually the historical
> kernel usage of the zero page.

Oh flippin' hell.  *STABBITY STAB STAB STAB*.

All of which is just evil.  So much for "oh, the definition of the
zeropage never changes, so it doesn't matter."

> elilo does something similar but starts with a 16K pages and then backs up
> 2K for the command line.
> 
> Gujin does something similar but also seems to place a command line at 2K.
> 
> So short of the first 2K we can reasonably expect new parameters to be zero
> initialized.  Past that we need to be a little more careful.

Oh flippin' hell.

> And 4K seems to be our maximum size for backwards compatibility.  Although
> we use it in a fairly sparse way, so we should be ok.

Sort of.  It's pretty full.

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