On Tue, 27 Feb 2018 17:14:02 +0800 Dave Young <dyoung@xxxxxxxxxx> wrote: > 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. In the updated series it is easy to turn on or off the fallback so an option can be added for that. However, the fallback only works by trying -s first. Implementing fallback in either direction would complicate things a bit. Especially since error codes of kexec-tools do not tend to be nice and consistent. Thanks Michal _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
