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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <50C95832.5030306@zytor.com>
Date:	Wed, 12 Dec 2012 20:23:14 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: kexec and struct boot_params

On 12/12/2012 06:49 PM, Yinghai Lu wrote:
>>
>> Hi, Peter,
>>
>> What's your decision about this?
>>
>> Do you mean have one boot_params mask in initdata and AND that with
>> boot_params from bootloader
>> to clean not used bytes?
>>
>> So later will not need to check
>>      if (boot_params.hdr.xloadflags & USE_EXT_BOOT_PARAMS)
>> ?
>>
>> I worked out other patches that remove kdump 896M limitation.
>> would like to post those patches to get more testing.
>> those are needed for bigger system with lots of pcie devices.
>
>
> ping!
>

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

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

Eric, any thoughts or additional opinions?

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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