"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
