| 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
| ||
|
Message-ID: <Pine.LNX.4.64.0911091031460.15199@sister.anvils> Date: Mon, 9 Nov 2009 10:32:52 +0000 (GMT) From: Hugh Dickins <hugh.dickins@...cali.co.uk> To: Andi Kleen <andi@...stfloor.org> cc: Mark Veltzer <mark.veltzer@...il.com>, linux-kernel@...r.kernel.org Subject: Re: get_user_pages question On Mon, 9 Nov 2009, Andi Kleen wrote: > Mark Veltzer <mark.veltzer@...il.com> writes: > > > > I am testing this kernel module with several buffers from user space allocated > > in several different ways. heap, data segment, static variable in function and > > stack. All scenarious work EXCEPT the stack one. When passing the stack buffer > > the kernel sees one thing while user space sees another. > > In theory it should work, stack is no different from any other pages. > First thought was that you used some platform with incoherent caches, > but that doesn't seem to be the case if it's standard x86. It may be irrelevant to Mark's stack case, but it is worth mentioning the fork problem: how a process does get_user_pages to pin down a buffer somewhere in anonymous memory, a thread forks (write protecting anonymous memory shared between parent and child), child userspace writes to a location in the same page as that buffer, causing copy-on-write which breaks the connection between the get_user_pages buffer and what child userspace sees there afterwards. Hugh -- 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