linux-kernel - Re: [PATCH v3 11/12] x86, boot: add fields to support load bzImage and ramdisk high

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <87haofi3d3.fsf@xmission.com>
Date:	Sat, 24 Nov 2012 04:37:12 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Yinghai Lu <yinghai@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Rob Landley <rob@...dley.net>,
	Matt Fleming <matt.fleming@...el.com>
Subject: Re: [PATCH v3 11/12] x86, boot: add fields to support load bzImage and ramdisk high

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

> On 11/22/2012 10:28 AM, Yinghai Lu wrote:
>>
>> has problem with old kexec, it only copy header from bzImage include
>> setup_header as boot_param.
>>
>
> How old are we talking here? This is a clear and blatant bug, and it would
> affect a whole bunch of things, not just this.  In fact, one really has to
> wonder how it can work at all.
>
> One option I guess would be to have a sentinel field which, if it is not zero,
> causes the kernel to zero all of struct setup_info outside of
> setup_header... however, I have a nasty suspicion that this kexec botch might be
> initializing some fields and leaving others unmodified, which basically means
> "there is no hope for sanity and it is just working by pure accident."
>
> Eric, do you have any insight here?

I seem to be missing something.

With respect to boot parameters when we are booting a bzImage
/sbin/kexec initializes the boot parameters with all of the 16bit real
mode code.  aka (setup_sects + 1) * 512 bytes.

I remember adding that as soon as we started having to deal with
pre-initialized fields in boot_params.

I don't have a clue what you folks are referring to as a bug.  

Looking I see this verbage in boot.txt

> For machine with some new BIOS other than legacy BIOS, such as EFI,
> LinuxBIOS, etc, and kexec, the 16-bit real mode setup code in kernel
> based on legacy BIOS can not be used, so a 32-bit boot protocol needs
> to be defined.
> 
> In 32-bit boot protocol, the first step in loading a Linux kernel
> should be to setup the boot parameters (struct boot_params,
> traditionally known as "zero page"). The memory for struct boot_params
> should be allocated and initialized to all zero. Then the setup header
> from offset 0x01f1 of kernel image on should be loaded into struct
> boot_params and examined. The end of setup header can be calculated as
> follow:
> 
> 	0x0202 + byte value at offset 0x0201
> 
> In addition to read/modify/write the setup header of the struct
> boot_params as that of 16-bit boot protocol, the boot loader should
> also fill the additional fields of the struct boot_params as that
> described in zero-page.txt.

Certainly /sbin/kexec isn't bothering to calculate the end of the setup
header and just being far more conservative and using all of the 16bit
real mode code as it's initializer.

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/