From: Steven Rostedt <rostedt@goodmis.org>
To: Martijn van Oosterhout <kleptog@svana.org>
Cc: linux-net@vger.kernel.org, linux-kernel@vger.kernel.org,
KrnlUsr <kdp102@yahoo.com>
Subject: Re: copy_from_user, copy_to_user in kernel
Date: Fri, 12 Aug 2005 19:50:28 -0400 [thread overview]
Message-ID: <1123890628.5296.44.camel@localhost.localdomain> (raw)
In-Reply-To: <20050812203552.GG4305@svana.org>
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
prev parent reply other threads:[~2005-08-12 23:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-12 18:16 KrnlUsr
2005-08-12 18:29 ` John W. Linville
2005-08-12 20:35 ` Martijn van Oosterhout
2005-08-12 23:50 ` Steven Rostedt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1123890628.5296.44.camel@localhost.localdomain \
--to=rostedt@goodmis.org \
--cc=kdp102@yahoo.com \
--cc=kleptog@svana.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome