From: Bryan Donlan <bdonlan@gmail.com>
To: Siddhartha Chhabra <siddhartha.chhabra@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: Kernel vs user memory
Date: Thu, 18 Mar 2010 20:28:34 -0400 [thread overview]
Message-ID: <3e8340491003181728r766245edo91ecc1db75f3a6df@mail.gmail.com> (raw)
In-Reply-To: <49f90a801003181710v5e08ccc8jdd26ec899e75bdb9@mail.gmail.com>
On Thu, Mar 18, 2010 at 20:10, Siddhartha Chhabra
<siddhartha.chhabra@gmail.com> wrote:
> When the kernel tries to access user space pages, for example, for copying
> on a copy on write, in order to do so, does it need to get the page mapped
> to its address space, that is, will a page fault happen for the kernel when
> it first tries to access the user space page that it needs to copy ?
>
> I read a paper that provides security to the OS based on the assumption that
> every time, the OS tries to access the user space, it will page fault and by
> intercepting this page fault, they can check whether the kernel should be
> accessing the page or not ? But based on the discussion below, I guess, the
> kernel is free to access all the pages in memory (or atleast the first 700MB
> on a 32-bit system) without causing a page fault in the kernel space ?
>
> Am I right on this? I greatly appreciate you taking time to answer this
> question
It depends.
If the kernel's doing a copy_from_user or copy_to_user family of calls
(ie, the calls used in system call handlers when accessing user space
buffers referenced in the arguments), this will trigger a page fault
exactly like the userspace process would, and the PF handler will then
deal with any copy on write or whatever may be needed. Of course, if a
userspace access wouldn't trigger a PF, the kernel access won't
either.
For the actual copy-on-write process itself, it would be a Bad Thing
to trigger a recursive page fault, so instead the kernel will directly
access the page via the direct mapped section of the address space -
this will never cause a PF (on x86, this may require creating a
temporary mapping for memory at a high physical address, but this
still won't be a PF as it will be set up before the first access).
Additionally, memory mapped IO involves direct DMA to/from pages that
are simultaneously in use by userspace - this won't cause a PF in
kernel mode either. Same with swap.
In short, some kernel accesses to user space do go through normal
channels which may or may not PF; other accesses will never PF. So
it's a bad idea to rely on all kernel accesses triggering a page
fault.
Hope this helps,
Bryan
next prev parent reply other threads:[~2010-03-19 0:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-17 2:56 sidc7
2009-01-17 4:16 ` Bryan Donlan
2009-01-17 4:21 ` sidc7
2009-01-17 5:26 ` Bryan Donlan
[not found] ` <49f90a801003181710v5e08ccc8jdd26ec899e75bdb9@mail.gmail.com>
2010-03-19 0:28 ` Bryan Donlan [this message]
[not found] ` <49f90a801003181747m5078d9c2y3cc8421203a7b1e6@mail.gmail.com>
2010-03-19 1:06 ` Bryan Donlan
2010-03-19 1:29 ` Siddhartha Chhabra
2009-01-17 6:26 ` H. Peter Anvin
2009-01-17 6:34 ` sidc7
2009-01-17 6:38 ` H. Peter Anvin
2009-01-17 6:42 ` sidc7
2009-01-17 7:27 ` H. Peter Anvin
2009-01-19 20:03 ` sidc7
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=3e8340491003181728r766245edo91ecc1db75f3a6df@mail.gmail.com \
--to=bdonlan@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=siddhartha.chhabra@gmail.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®