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: <m1d51gpfqn.fsf@ebiederm.dsl.xmission.com>
Date:	Fri, 04 May 2007 13:10:08 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"H. Peter Anvin" <hpa@...or.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

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

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

Sure. I meant that linux/screen_info.h should already be safe.

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

Interesting. I missed that one.

>> 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*.

Yep, a real pain.

At this point it looks like a bug in kexec to me, and the bzImage loader
which is the primary way to boot linux doesn't have this problem.  Yea.

> 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 now you understand why I am surveying these things and want to get
the 32bit entry point well documented.  So the situation doesn't get worse.

Frankly while I consider what we are doing pretty sane I have always considered
the 32bit entry point at least partly experimental.  But we have enough users
of it now and enough reasons to have users of it, that it looks like we need to
do things a little more methodically.

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

True.  For small little extensions we have room.  For big things probably
not.

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/