linux-kernel - Re: Kernel vs user memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Thu, 18 Mar 2010 20:28:34 -0400
From:	Bryan Donlan <bdonlan@...il.com>
To:	Siddhartha Chhabra <siddhartha.chhabra@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Kernel vs user memory

On Thu, Mar 18, 2010 at 20:10, Siddhartha Chhabra
<siddhartha.chhabra@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/