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
| ||
|
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/
Powered by blists - more mailing lists