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

[Dave Young]

On 02/26/18 at 01:08pm, Michal Suchánek wrote:
> On Mon, 26 Feb 2018 09:45:15 +0800
> Dave Young <dyoung at redhat.com> wrote:
> 
> > On 02/24/18 at 05:34pm, Petr Tesarik wrote:
> > > On Sat, 24 Feb 2018 09:43:42 +0800
> > > Dave Young <dyoung at redhat.com> wrote:
> > >   
> > > > On 02/23/18 at 09:29am, Petr Tesarik wrote:  
> > > > > Hi Baoquan,
> > > > > 
> > > > > 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? Why bother to make change
> > > > > > in code? I believe there's returned message telling if
> > > > > > KEXEC_FILE_LOAD works or not.    
> > > > > 
> > > > > Well... let me give a bit of background. As you have probably
> > > > > noticed, this syscall was originally available only for x86_64,
> > > > > but more and more architectures are also adding it now.
> > > > > 
> > > > > Next, kexec is actually called by a script (which locates a
> > > > > suitable kernel and initrd, constructs the kernel command line,
> > > > > etc.). The script must either:
> > > > > 
> > > > >   A. know somehow if the currently running kernel implements
> > > > >      kexec_file_load(2), or
> > > > > 
> > > > >   B. try one method first, and if it fails, retry with the
> > > > > other.
> > > > > 
> > > > > I agree that kexec(1) should probably allow the user to force a
> > > > > specific method, but I don't see the benefit of implementing
> > > > > fallback in an external script and not in kexec-tools itself.
> > > > > 
> > > > > OTOH if you want to push the fallback logic out of kexec-tools,
> > > > > then I would like to get better diagnostic at least. Letting my
> > > > > script parse kexec output is, um, suboptimal.    
> > > > 
> > > > In Fedora/RHEL we use this in scripts by checking the arch first,
> > > > for distribution it is enough?  
> > > 
> > > No.
> > > 
> > > First, you would also have to check the kernel version (and
> > > maintain an ugly mapping of which kernel version introduced
> > > kexec_file_load on which architecture).  
> > 
> > The kernel version update is rare for these new syscall added, but
> > it is indeed needed to match with them
> > 
> > > 
> > > Second, it's not just the architecture. kexec_load(2) will fail if
> > > SecureBoot is active. OTOH kexec_file_load(2) will fail if the
> > > kernel is not signed. For kernel hackers who don't use SecureBoot,
> > > signing self-built kernels is just overkill. So, you should also
> > > check the state of SecureBoot, possibly also whether the kernel
> > > image is signed with a valid key, repeating a bit too much of the
> > > kernel logic, and quite likely introducing subtle differences...  
> > 
> > Hmm, I did not say the exact details, yes, we checked the Secure Boot
> > state and only use kexec_file_load for that special case.
> > 
> > kexec_file and kexec_file_load is not exactly same so if one want to
> > use one instead of another for a specific functionality it seems not
> > good to automatically switch to another if one failed. For example
> > which one should be the first choice, it is hard to say.
> 
> Hard to say indeed, However, I would assume that architectures that
> implement kexec_file_load do so because it is required in some case and
> hence it will be actively maintained when available. However, some
> architectures may not require it and will be slow to implement it. So
> using kexec_file_load when available sounds like the right thing.
> Technically the implementation details are different but for most users
> this does not matter.
> 
> For those that do care I provide option to select one or the other.

I would say it breaks things, a better way should be introducing another
kexec-tools option for example kexec --auto for this purpose. Probably
add some --auto=... to select the first chance.

> 
> Thanks
> 
> Michal
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Thanks
Dave