From: Vadim Lobanov <vlobanov@speakeasy.net>
To: Hacksaw <hacksaw@hacksaw.org>
Cc: linux-os@analogic.com, "Theodore Ts'o" <tytso@mit.edu>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Tomko <tomko@haha.com>,
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: Sat, 16 Apr 2005 12:35:59 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.58.0504161226140.6618@shell4.speakeasy.net> (raw)
In-Reply-To: <200504160830.j3G8UH0x031123@hacksaw.org>
On Sat, 16 Apr 2005, Hacksaw wrote:
> >if you want actual concrete examples, let me know.
> I'd love a few, but maybe privately?
>
>
> I can certainly see where always copying is simpler; I certainly consider this
> to be an optimization, which must be looked at carefully, lest you end up with
> that which speed things up a little, but adds a big maintenance headache.
>
> But this strikes me as a potentially big speed up for movement through
> devices. (Or is there already a mechanism for that?)
>
> >It checks if the LAST page belongs to userland, and fails if not;
> I can't claim to know how memory assignment goes. I suppose that this
> statement means that the address space the userland program sees is continuous?
>
> If not I could see a scenario where that would allow someone to get at data
> that isn't theirs, by allocating around until they got an chunk far up in
> memory, then just specified a start address way lower with the right size to
> end up on their chunk.
>
> I'm assuming this isn't a workable scenario, right?
For the copy_from_user() operation, we're still talking about virtual
memory. In virtual memory terms, each userspace program resides in the
lower addresses, while the kernel takes up the higher addresses. The
user program can pass the kernel any virtual memory pointer it feels
like.
The kernel first checks that it won't try to read from itself, simply by
checking that the last page, belonging to the highest virtual address of
the supposed buffer, does not belong to kernel space. So far so good.
Now the only thing that can go wrong is that the user program told the
kernel that the buffer exists, but some or all of the pages are not
mapped in virtual memory. This is taken care of "transparently" during
the copy -- if we try to copy from a page that isn't mapped, the kernel
will catch the exception, realize that the buffer was bogus, and return
an error.
All of this works because virtual memory is much more restrictive than
physical memory in terms of what data resides where.
> --
> You are in a maze of twisty passages, all alike. Again.
> http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD
>
>
-Vadim Lobanov
next prev parent reply other threads:[~2005-04-16 19:36 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
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 [this message]
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.0504161226140.6618@shell4.speakeasy.net \
--to=vlobanov@speakeasy.net \
--cc=benh@kernel.crashing.org \
--cc=hacksaw@hacksaw.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-os@analogic.com \
--cc=tomko@haha.com \
--cc=tytso@mit.edu \
/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®