From: Vadim Lobanov <vlobanov@speakeasy.net>
To: Tomko <tomko@haha.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Why system call need to copy the date from the userspace before using it
Date: Tue, 12 Apr 2005 22:30:22 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.58.0504122207280.30548@shell2.speakeasy.net> (raw)
In-Reply-To: <425C9E55.6010607@haha.com>
On Wed, 13 Apr 2005, 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 ?
>
> Thx a lot,
>
> TOM
> -
The quick and simple answer to this question is: data integrity.
The main thing to understand is that, from the perspective of the
kernel, any user input provided in the form of system calls must have
immutable data. Only if the data is immutable can the kernel code parse
it and decide what to do, without getting into really hairy race
conditions. And, for that matter, it's much simpler and less error-prone
to program code where you don't have to worry about the inputs changing
around you all the time.
So, you might say, what's wrong with the user code giving the kernel a
pointer to a userland buffer? After all, the calling task will be
blocked while the system call is being executed on its behalf. The
biggest problem is that the buffer can still be modified, while the
system call is executing, by another userland thread running in the same
virtual memory context. Or, for that matter, by another process that has
this chunk of memory shared with the original task. There are
innumerable ways for the data to potentially change in the middle of the
system call, and the simplest solution ends up being to copy the data to
kernelspace before working with it. That way, no userland tasks can
change it on you.
I'm sure there are other reasons for doing the copy, that someone will
be able to chime in with. Other input is always welcome. :-)
-Vadim Lobanov
next prev parent reply other threads:[~2005-04-13 5:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-13 4:21 Tomko
2005-04-13 5:30 ` Vadim Lobanov [this message]
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
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
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=Pine.LNX.4.58.0504122207280.30548@shell2.speakeasy.net \
--to=vlobanov@speakeasy.net \
--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
all inboxes | Powered by JetHome®