On 02/27/18 at 05:09pm, Dave Young wrote: > On 02/27/18 at 09:39am, Petr Tesarik wrote: > > On Tue, 27 Feb 2018 09:15:10 +0800 > > Dave Young <dyoung@xxxxxxxxxx> wrote: > > > > > On 02/26/18 at 01:08pm, Michal Suchánek wrote: > > > > On Mon, 26 Feb 2018 09:45:15 +0800 > > > > Dave Young <dyoung@xxxxxxxxxx> wrote: > > > > > > > > > On 02/24/18 at 05:34pm, Petr Tesarik wrote: > > > > > > On Sat, 24 Feb 2018 09:43:42 +0800 > > > > > > Dave Young <dyoung@xxxxxxxxxx> 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@xxxxxxxxxx> 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 If one use kexec -s --method=user then kexec-tools should fail, talked with Baoquan privately he has another idea to extend the kexec -s with --fallback: "kexec -s --fallback -l" can fallback to userspace loader this seems also a good option. > > > > > Petr T > > Thanks > Dave _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
