copy_from_user, copy_to_user in kernel

copy_from_user, copy_to_user in kernel

[KrnlUsr]

Hi

Why does copy_from/to_user routines fail if both
source and destination are in kernel space. I have a
kernel module that:

1. takes some parameters from user space via ioctl
(kernel copies arguments with copy_from_user)

2. processes command(s) from user and 

3. returns output to user with copy_to_user

now i have a kernel thread that wants to talk to same 
kernel module. basically user space programs will talk
to my kernel module with ioctl but kernel threads will
call EXPORTed routines. i'll have another set of
routines to work with these two interfaces. but can i 
have the core routines copy processed data back to
kernel thread or user space with copy_to_user. or do i
have to have some check saying if called from ioctl
call copy_to_user otherwise call memcpy?


                       user space interface
                                  ^
                   ---------------|---------------
                                  V
     kernel      <-->         kernel module
     thread


thanks

Re: copy_from_user, copy_to_user in kernel

[John W. Linville]

On Fri, Aug 12, 2005 at 11:16:23AM -0700, KrnlUsr wrote:

> have the core routines copy processed data back to
> kernel thread or user space with copy_to_user. or do i
> have to have some check saying if called from ioctl
> call copy_to_user otherwise call memcpy?

Why wouldn't you just let the core routines deal only w/ kernel memory
and only have your ioctl handler deal w/ copy_{to,from}_user?

John
-- 
John W. Linville
linville@tuxdriver.com

Re: copy_from_user, copy_to_user in kernel

[Martijn van Oosterhout]

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]

On Fri, Aug 12, 2005 at 11:16:23AM -0700, KrnlUsr wrote:
> Hi
> 
> Why does copy_from/to_user routines fail if both
> source and destination are in kernel space. I have a
> kernel module that:

I had this problem when writing a kernel module that was using a UDP
socket to send and receive stuff. It would work fine in UML but fail in
the real kernel. I never worked it out but someone later patched it by
using the [gs]et_[df]s() functions. If you grep the kernel source you
can see a lot of places use it. The problem is I still have no idea why
it works...

Hope this helps,
-- 
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: copy_from_user, copy_to_user in kernel

[Steven Rostedt]

On Fri, 2005-08-12 at 22:35 +0200, Martijn van Oosterhout wrote:
> I had this problem when writing a kernel module that was using a UDP
> socket to send and receive stuff. It would work fine in UML but fail in
> the real kernel. I never worked it out but someone later patched it by
> using the [gs]et_[df]s() functions. If you grep the kernel source you
> can see a lot of places use it. The problem is I still have no idea why
> it works...
> 

These work because you are changing the access area of the user. Well,
not really the user, but user copying macros.  Normally a
copy_(from|to)_user would fail if it were to try to access kernel area.
Otherwise, a user process could fool a system call to use kernel memory
as an output. This would be horrible for security.

Imagine:

fd=open("my_nano_kernel",O_RDONLY);
read(fd,0xc0000000,MY_NANO_KERNEL_SIZE);

If anything, on some architectures, this could rewrite the interrupt
handlers. Or with the access to System.map, you could put in your own
values to different functions. Or read from the kernel's view of memory,
to find passwords, and the list goes on. Just plain bad!

The setting of set_fs changes this area to allow system calls to be done
from the kernel, where it is ok to access kernel memory.  But these are
always done temporarily, and then changed back to limited access. Thus
you have save the old value of the get_fs, change it to use the
KERNEL_DS version, then set it back to what it was.  (don't blindly set
it back to USER_DS, since it could have been in KERNEL_DS from the start
for some reason, like kernel threads).

Although the naming of these macros are horrible, as mentioned in the
file that declares them:

/*
 * The fs value determines whether argument validity checking should be
 * performed or not.  If get_fs() == USER_DS, checking is performed, with
 * get_fs() == KERNEL_DS, checking is bypassed.
 *
 * For historical reasons, these macros are grossly misnamed.
 */

The macros are used to make things easier across architectuers.

-- Steve