From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Tomko <tomko@haha.com>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: Why system call need to copy the date from the userspace before using it
Date: Wed, 13 Apr 2005 21:33:27 +1000 [thread overview]
Message-ID: <1113392007.5516.26.camel@gaston> (raw)
In-Reply-To: <425C9E55.6010607@haha.com>
On Wed, 2005-04-13 at 12:21 +0800, Tomko wrote:
> Hi all,
>
> I am new to linux , hope someone can help me.
> While i am reading the source code of the linux system call , i find
> that the system call need to call copy_from_user() to copy the data from
> user space to kernel space before using it . Why not use it directly as
> the system call has got the address ? Furthermore , how to distinguish
> between user space and kernel space ?
Well, there are more than one reason. But, in general, you always need
to access user memory using specific accessors, like copy_to/from_user,
get/put_user, etc... Some of these reasons are:
- Userland can give you a bogus pointer. Doing a normal access from the
kernel via a bogus pointer can lead to all sort of funny things, which
you really do not want to happen. What if userland is giving a
destination pointer to the kernel that points to ... the kernel itself
or some of it's data structures ? that would be way to easy for userland
to cause the kernel to crash if the kernel "trusted" pointers from
userland. So one thing those functions do is to check the pointer to see
if it's within valid userland memory bounds
- Even if within valid memory bounds, it may still be bogus, that is
point to a page that is not mapped, or a destination pointer pointing to
a read-only page, or all sort of other fault caused by accessing it.
Those special access functions are designed to "recover" from there
errors. Instead of the kernel crashing/Oops'ing because of the bad
access, the kernel page fault handler will "notice" that the access
comes from one of these special function and will do some black magic so
that instead of crashing, the access function will just return with an
error that can then be passed back to userspace (usually EFAULT).
- Some architectures don't have user and kernel memory mapped at the
same time (think about x86 in 4G/4G mode for example). In that case,
accessing user memory requires some specific memory management tricks
that are architecture specific. Those functions take care of that.
There may even be more I don't have in mind at the moment, but the above
is already enough to justify having specific accessor functions for
kernel code to access userland originated pointers.
Ben.
next prev parent reply other threads:[~2005-04-13 11:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-13 4:21 Why system call need to copy the date from the userspace before using it Tomko
2005-04-13 5:30 ` Vadim Lobanov
2005-04-13 10:29 ` Jan-Benedict Glaw
2005-04-13 10:43 ` Tomko
2005-04-13 11:10 ` Catalin Marinas
2005-04-14 2:10 ` Tomko
2005-04-14 2:18 ` David Schwartz
2005-04-14 14:05 ` Helge Hafting
2005-04-13 11:33 ` Benjamin Herrenschmidt [this message]
2005-04-13 11:59 ` Hacksaw
2005-04-13 12:40 ` Richard B. Johnson
2005-04-13 18:37 ` Theodore Ts'o
2005-04-13 19:20 ` Richard B. Johnson
2005-04-16 4:50 ` Hacksaw
2005-04-16 5:18 ` Vadim Lobanov
2005-04-16 8:30 ` Hacksaw
2005-04-16 19:35 ` Vadim Lobanov
2005-04-16 23:46 ` David Wagner
-- strict thread matches above, loose matches on Subject: below --
2005-04-13 6:48 Vadim Lobanov
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=1113392007.5516.26.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tomko@haha.com \
/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