On Thu, Mar 29, 2018 at 02:46:44PM +0000, David Laight wrote: > From: Dominik Brodowski > > Sent: 29 March 2018 15:42 > > On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote: > > > On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote: > > > > At least on 64-bit x86, it will likely be a hard requirement from v4.17 > > > > onwards to not call system call functions in the kernel: It is better to > > > > use use a different calling convention for system calls there, where > > > > struct pt_regs is decoded on-the-fly in a syscall wrapper which then hands > > > > processing over to the actual syscall function. This means that only those > > > > parameters which are actually needed for a specific syscall are passed on > > > > during syscall entry, instead of filling in six CPU registers with random > > > > user space content all the time (which may cause serious trouble down the > > > > call chain).[*] > > > > > > How do we stop new ones from springing up? Some kind of linker trick > > > like was used to, er, "dissuade" people from using gets()? > > > > Once the patches which modify the syscall calling convention are merged, > > it won't compile on 64-bit x86, but bark loudly. That should frighten anyone. > > Meow. > > Should be pretty easy to ensure the prototypes aren't in any normal header. That's exactly why the compile will fail. > Renaming the global symbols (to not match the function name) will make it > much harder to call them as well. That still depends on the exact design of the patchset, which is still under review. Thanks, Dominik
