On Thu, Mar 29, 2018 at 02:46:44PM +0000, David Laight wrote:

From: Dominik Brodowski

quoted

Sent: 29 March 2018 15:42
On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote:

quoted

On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote:

quoted

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