lkml.org 
[lkml]   [2012]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.



\
 
 \ /
  Last update: 2012-11-24 21:41    [W:2.553 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site