[PATCH 4/6] kexec: A new system call, kexec_file_load, for in kernel kexec

[Eric W. Biederman]

"H. Peter Anvin" <hpa at zytor.com> writes:

> On 12/20/2013 03:11 PM, Eric W. Biederman wrote:
>> 
>> In that case the chrome folks would simply have to use an ELF format
>> kernel and not a bzImage.
>> 
>
> This is starting to feel like everything is going in the direction of a
> massive feature regression.  bzImage may be weird (it has definitely
> grown organically), but the features that have been added to it have
> generally been for a reason, e.g. kernel relocation and so on.

Stuff and nonsense.  bzImage is just an ugly wrapper around an ELF
image.

I am just arguing that we expose the clean portable underpinnings and
make that work.

It absolutely does not make sense to make a solution that only works for
x86.  ELF is what ever other architecture uses so we absolutely have to
make any feature we build work with ELF.

At a very basic level for this feature ELF is good enough.  bzImage
isn't.

Given that in the worst case distro's will have to package a second
binary of the same kernel in their kernel rpm.  I don't know that there
is any point in supporting anything else except ELF in the kernel.
Given that the package and distribution are going to have to change
anyway to include signing a change in file format hardly seems scary.

But my point above was really that ELF is sufficient for the use case of
doing file based verification base on fd's in addition to the use case
of using detached signatures.  Which is really a long winded way of
saying the argument "But but but my distro only ships a bzImage today"
is a horrible techinical argument.

I am not fundamentally opposed to supporting other file formats but
given that ELF wins on both practical and techincal grounds ELF should
be the primary file format for kexec_file_load.  We can worry about
other file formats once ELF is shown to work.

Eric