Context: linux-5.0/Documentation/process/adding-syscalls.rst#do-not-call-system-calls-in-the-kernel

Firstly, kernel code cannot call functions like "sys_xyzzy()" anymore, because they have the wrong calling convention.

But secondly, "rules on how data may be accessed may differ between kernel data and user data."

There are now some functions which are direct replacements for the old "sys_xyzzy()" calls. For example: ksys_mount().

ksys_mount() takes pointers to __user memory, just like calls to sys_mount() did. Therefore it should fail if you pass it a pointer to kernel memory. Specifically, it will fail when it calls copy_from_user(), unless you play games with set_fs().

So... why do we have a couple of calls to ksys_mount() in various places inside the kernel? How can these possibly work? They are not wrapped with calls to set_fs().


  • drivers/base/devtmpfs.c
  • init/do_mounts.c
  • ...

devtmpfs currently runs in a kernel thread. In a kernel thread, addr_limit is effectively disabled. At least that's how this works for x86 - it is architecture-specific code.

init/do_mounts.c is similar. The kernel init process must start like a kernel thread, with addr_limit effectively disabled. Later, it calls do_execve() to start executing the userspace init program. The kernel makes sure to call "set_fs(USER_DS)", before executing the userspace program.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.