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

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

Date:	Sat, 24 Nov 2012 11:50:01 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.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

On 11/24/2012 09:32 AM, H. Peter Anvin wrote:
> On 11/24/2012 04:37 AM, Eric W. Biederman wrote:
>>
>> 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.
>>
>
> That's not conservative... that's just plain wrong.  It means you're
> initializing the fields in struct boot_params with garbage instead of a
> predictable value (zero).
>
> We could work around it with a sentinel hack... except you *also*
> probably modify *some* fields and now we have a horrid mix of
> initialized and uninitialized fields to sort out... and there really
> isn't any sane way for the kernel to sort that out.
>
> We have a huge problem on our hands now because of it.
>

So, given the mess we now have on our hands... any suggestions how to 
best solve it?  There is the option of simply declaring old kexec 
binaries broken; they will then not work reliably with newer kernels, if 
they even work reliably now -- it is hard to know for certain.

Another option is the sentinel hack I mentioned... permanently reserve a 
field that if it is nonzero we will have the kernel erase the remainder 
of struct boot_params... except for *some fields* to be defined.  This 
is a total hack workaround and will not work if we have the same class 
of problems in another bootloader which initializes different fields, 
but, well, it might provide some value and might solve problems with 
other bootloaders which have similar enough misbehavior.

The final idea would be to declare the current struct boot_params frozen 
indefinitely, and instead create a whole new set of data structures 
going forward, perhaps inserting them into the linked list.

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