Re: [PATCH v3 11/12] x86, boot: add fields to support load bzImageand ramdisk high

[H. Peter Anvin]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/