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. Thanks Michal _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
