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

[Dave Young <dyoung@redhat.com>]

On 02/27/18 at 09:39am, Petr Tesarik wrote:
> On Tue, 27 Feb 2018 09:15:10 +0800
> Dave Young <dyoung@redhat.com> wrote:
> 
> > On 02/26/18 at 01:08pm, Michal Suchánek wrote:
> > > On Mon, 26 Feb 2018 09:45:15 +0800
> > > Dave Young <dyoung@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@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@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.
> 
> Yes! This is the way to go. But then I wouldn't call it --auto.
> I would call it "--method=", so you could specify:
> 
>   --method=kernel  (to use the in-kernel loader aka kexec_file_load)
>   --method=user    (to use the traditional user-space loader)
>   --method=kernel,user  (to prefer kexec_file_load)
>   --method=user,kernel  (to prefer kexc_load)
> 
> I'm not quite sure if it also makes sense to provide "--method=auto",
> which would use whatever default is considered sane for the running
> system.

If we have --method=kernel,user and --method=user,kernel then no need
"auto" anymore..  But I would prefer that original default behavior is kept,
kexec -l  without "--method" will use userspace loader, kexec -s -l will
use kernel space loader

> 
> Petr T

Thanks
Dave

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec