[PATCH] kexec: do KEXEC_FILE_LOAD and fallback to KEXEC_LOAD if not supported.

Michal Suchánek msuchanek at suse.de
Fri Feb 23 11:21:06 PST 2018

On Fri, 23 Feb 2018 07:20:43 +0800
Baoquan He <bhe at redhat.com> wrote:

> Hi Michal,
> On 02/22/18 at 11:24pm, Michal Suchanek wrote:
> > The new KEXEC_FILE_LOAD is preferred in the case the platform
> > supports it because it allows kexec in locked down secure boot mode.
> > 
> > However, some platforms do not support it so fall back to the old
> > syscall there.  
> I didn't read code change, just from patch log, I tend to not agree.
> There are two options KEXEC_FILE_LOAD and KEXEC_LOAD, some platforms
> do not support, why does some platforms not choose KEXEC_LOAD, the
> working one? 

Because nobody wrote the support. If you volunteer to write support for
KEXEC_FILE_LOAD for every platform Linux supports and add the respective
syscall numbers to kexec so it knows how to execute the syscall on
every platform I will consider it alternative fix. 

Some people will argue that not everyone applies the patches
to support KEXEC_FILE_LOAD in the kernel overnight, though.

> Why bother to make change in code? 

Because it is unusable as is. Just calling kexec fails with locked-down
secure boot. Calling kexec -s fails on almost every platform except x86.

> I believe there's
> returned message telling if KEXEC_FILE_LOAD works or not.

That is not a solution. A way to call kexec that actually works is
needed. This patch removes the need to use the undocumented -s option
to get the new superior syscall you seem to prefer. It will just do the
right thing in most cases. It allows the user to select either syscall
explicitly as well. I do not see the problem with that.



More information about the kexec mailing list