| Message ID | 20140815135520.GT27466@arm.com |
|---|---|
| State | New |
| Headers | show |
On Fri, Aug 15, 2014 at 02:55:20PM +0100, Will Deacon wrote: > On Tue, Aug 12, 2014 at 01:37:36PM +0100, Vivek Goyal wrote: > > On Tue, Aug 12, 2014 at 12:10:30PM +0100, Will Deacon wrote: > > > Hmm, so whilst I can easily wire-up the new syscall, it's pretty useless for > > > anybody other than x86 at the moment. There are a bunch of arch helpers: > > > > > > arch_kexec_kernel_image_probe > > > arch_kexec_kernel_verify_sig > > > arch_kexec_kernel_image_load > > > arch_kimage_file_post_load_cleanup > > > > > > which are only implemented for x86 (arch/x86/kernel/machine_kexec_64.c), > > > even though I don't really see what makes them arch-specific as opposed to > > > file format specific. > > > > Yes, at this point of time, this system call will work only on x86. Agreed > > that primarily it is file format details which are primarily in arch > > specific section. > > > > I think that some of the code will become arch independent as other > > arches start implementing this syscall. > > > > > > > > So this syscall will always fail with -ENOEXEC at the moment. Is it still > > > worth wiring it up? > > > > I thought that for other arches I have not even defined the syscall. So > > it probably will fail with -ENOSYS. > > What I meant was, if I wire it into asm-generic/unistd.h then it will return > -ENOEXEC for architectures using that file (e.g. arm64). > > Patch below, but I don't think it's very useful. > Hi Will, I have not even defined a syscall number for other arches. IIUC, this patch will forcibly introduce a syscall number for the new syscall for arches which use asm-generic/unistd.h. So question I have is that why should we do it now. One can do it once somebody enables kexec_file_load() on arm64. Right now I see that kexec_file_load() gets compiled if CONFIG_KEXEC=y. So even on arm64 it must be getting compiled in. But it is not being hooked up using system call table. So there should not be any way to invoke syscalll definition. So my understand is that in current form, one can not invoke kexec_file_load() on arm64. Is that right. Now I have put one more patch to make compilation of kexec_file_load() conditional on config option CONFIG_KEXEC_FILE. And this option can be enabled only on x86_64. That means kexec_file_load() will not even be compiled in on arm64 (once the patch gets merged). Right now patch is sitting in andrew's tree. http://ozlabs.org/~akpm/mmotm/broken-out/kexec-create-a-new-config-option-config_kexec_file-for-new-syscall.patch Can you please help me understand that why do we need this patch if at this point of time we are not even fixing a system call number for kexec_file_load() for arches except x86_64. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Mon, Aug 18, 2014 at 01:15:40PM -0400, Vivek Goyal wrote: > On Fri, Aug 15, 2014 at 02:55:20PM +0100, Will Deacon wrote: > > What I meant was, if I wire it into asm-generic/unistd.h then it will return > > -ENOEXEC for architectures using that file (e.g. arm64). > > > > Patch below, but I don't think it's very useful. > > > > Hi Will, > > I have not even defined a syscall number for other arches. IIUC, this > patch will forcibly introduce a syscall number for the new syscall for > arches which use asm-generic/unistd.h. > > So question I have is that why should we do it now. One can do it once > somebody enables kexec_file_load() on arm64. > > Right now I see that kexec_file_load() gets compiled if CONFIG_KEXEC=y. So > even on arm64 it must be getting compiled in. But it is not being hooked > up using system call table. So there should not be any way to invoke > syscalll definition. So my understand is that in current form, one can > not invoke kexec_file_load() on arm64. Is that right. > > Now I have put one more patch to make compilation of kexec_file_load() > conditional on config option CONFIG_KEXEC_FILE. And this option can > be enabled only on x86_64. That means kexec_file_load() will not even > be compiled in on arm64 (once the patch gets merged). Right now patch > is sitting in andrew's tree. > > http://ozlabs.org/~akpm/mmotm/broken-out/kexec-create-a-new-config-option-config_kexec_file-for-new-syscall.patch > > Can you please help me understand that why do we need this patch if at > this point of time we are not even fixing a system call number for > kexec_file_load() for arches except x86_64. From what I read, the only arch which supports this call is x86_64, and it requires arch code make work. So simply wiring up the syscall is not enough. What is probably worth doing is reserving the syscall number _if_ it's going to be useful on architectures - by that, I mean inserting the syscall number with a comment in the unistd.h file, rather than defining a constant.
On Mon, Aug 18, 2014 at 06:40:10PM +0100, Russell King - ARM Linux wrote: > On Mon, Aug 18, 2014 at 01:15:40PM -0400, Vivek Goyal wrote: > > On Fri, Aug 15, 2014 at 02:55:20PM +0100, Will Deacon wrote: > > > What I meant was, if I wire it into asm-generic/unistd.h then it will return > > > -ENOEXEC for architectures using that file (e.g. arm64). > > > > > > Patch below, but I don't think it's very useful. > > > > > > > Hi Will, > > > > I have not even defined a syscall number for other arches. IIUC, this > > patch will forcibly introduce a syscall number for the new syscall for > > arches which use asm-generic/unistd.h. > > > > So question I have is that why should we do it now. One can do it once > > somebody enables kexec_file_load() on arm64. > > > > Right now I see that kexec_file_load() gets compiled if CONFIG_KEXEC=y. So > > even on arm64 it must be getting compiled in. But it is not being hooked > > up using system call table. So there should not be any way to invoke > > syscalll definition. So my understand is that in current form, one can > > not invoke kexec_file_load() on arm64. Is that right. > > > > Now I have put one more patch to make compilation of kexec_file_load() > > conditional on config option CONFIG_KEXEC_FILE. And this option can > > be enabled only on x86_64. That means kexec_file_load() will not even > > be compiled in on arm64 (once the patch gets merged). Right now patch > > is sitting in andrew's tree. > > > > http://ozlabs.org/~akpm/mmotm/broken-out/kexec-create-a-new-config-option-config_kexec_file-for-new-syscall.patch > > > > Can you please help me understand that why do we need this patch if at > > this point of time we are not even fixing a system call number for > > kexec_file_load() for arches except x86_64. > > >From what I read, the only arch which supports this call is x86_64, and > it requires arch code make work. So simply wiring up the syscall is not > enough. > Yes, it will require some arch work (more arch specific kernel image format related work) to make syscall work on other arches. Generic portion of the syscall should work without any significant change. > What is probably worth doing is reserving the syscall number _if_ it's > going to be useful on architectures - by that, I mean inserting the > syscall number with a comment in the unistd.h file, rather than > defining a constant. I think this syscall is going to be useful on other arches also. I think specially on arm64 where UEFI is there and I am hoping at some point of time secureboot on arm64 machines will show up (if it is not already there). Do we have to reserve a syscall number now. Does it break anything. Or it can be reserved later once somebody decides to enable this syscall on arm64 or any other arch which uses generic/unistd.h. Right now it sounds more like nice to have item. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h index 11d11bc5c78f..92ae121fa055 100644 --- a/include/uapi/asm-generic/unistd.h +++ b/include/uapi/asm-generic/unistd.h @@ -705,9 +705,11 @@ __SYSCALL(__NR_seccomp, sys_seccomp) __SYSCALL(__NR_getrandom, sys_getrandom) #define __NR_memfd_create 279 __SYSCALL(__NR_memfd_create, sys_memfd_create) +#define __NR_kexec_file_load 280 +__SYSCALL(__NR_kexec_file_load, sys_kexec_file_load) #undef __NR_syscalls -#define __NR_syscalls 280 +#define __NR_syscalls 281 /* * All syscalls below here should go away really,