linux-kernel - Re: kexec and struct boot

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]

Message-ID: <CAE9FiQUTa2PmdV-gmespggPwvmfMzP7mpUHvpTDx=6cfGLEpyA@mail.gmail.com>
Date:	Wed, 12 Dec 2012 22:55:40 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: kexec and struct boot_params

On Wed, Dec 12, 2012 at 8:23 PM, H. Peter Anvin <hpa@...or.com> wrote:
> I still want to do what I mentioned before, because we need to not rely on
> the initialized/16-bit portion so much:
>
> 1. add a field in the uninitialized portion, call it "sentinel";
> 2. make sure the byte position corresponding to the "sentinel" field is
>    nonzero in the bzImage file;
> 3. if the kernel boots up and sentinel is nonzero, erase those fields
>    that you identified as uninitialized;

thanks for the instruction. please check if you are ok with update patch

> 4. assign a proper boot loader ID to kexec, so we have a way of dealing
>    with this kind of debacles in the future (that is what the
>    bootloader ID is for: it gives us a way to work around
>    bootloader-specific problems.)

ok, add one patch for kexec-tools

>
> We also need to formalize the 64-bit entry point properly, including all the
> entry conditions and so forth.  That needs to be documented.

do you mean, in some file, like bzImage_entry_64.txt
1. kernel 16 bit code length is defined by setup_sects in setup_header.
2. after that there are kernel code
   a. 32bit entry is 0,
   b. 64bit entry is 0x200
3. when using 32bit entry, kernel should under 1G, initrd should be
under 2G, zero_page, command_line should be under 1G.
 when using 64bit entry, kernel, initrd, zero_page, command_line could
be above 4G.

Thanks

Yinghai

Download attachment "ext_ramdisk_image.patch" of type "application/octet-stream" (9767 bytes)