mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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 21:06:12 -0400	[thread overview]
Message-ID: <3e8340491003181806t201218acod8ea408d1993cbfc@mail.gmail.com> (raw)
In-Reply-To: <49f90a801003181747m5078d9c2y3cc8421203a7b1e6@mail.gmail.com>

On Thu, Mar 18, 2010 at 20:47, Siddhartha Chhabra
<siddhartha.chhabra@gmail.com> wrote:
> On Thu, Mar 18, 2010 at 8:28 PM, Bryan Donlan <bdonlan@gmail.com> wrote:
>>
>> > 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
>
> In other words, without tying the kernel access to any specific operation
> (like COW, or copy-from/to-user, DMA, Memory mapped IO etc.), is it safe to
> say that a possibly compromised kernel wanting to read application's pages
> can do so without mapping the page to its address space, that is, without
> resulting in a page fault in the kernel mode on an attempt to access a page
> ?
>
> For example:
>
> Lets say for App A frame 5 on physical memory is mapped to its address space
> and its currently using it. The OS does a context switch, however, A's
> frames are still in the main memory. Now can the OS read these page frames
> (frame 5 in main memory) without mapping them to its address space, maybe
> just to read the application's contents and send it out to a potential
> attacker wanting to compromise the system's security ?

That is correct. The kernel can avoid a PF if it wants to by ensuring
the page tables are set up properly from the start; and physical
addresses below a certain value (which varies by architecture) can be
accessed directly without any setup at all.

  parent reply	other threads:[~2010-03-19  1:06 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
     [not found]           ` <49f90a801003181747m5078d9c2y3cc8421203a7b1e6@mail.gmail.com>
2010-03-19  1:06             ` Bryan Donlan [this message]
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=3e8340491003181806t201218acod8ea408d1993cbfc@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

Powered by JetHome