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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|