Am Montag, den 10.03.2014, 10:12 -0700 schrieb Andy Lutomirski: > On Mon, Mar 10, 2014 at 8:11 AM, Linus Torvalds > <torva...@linux-foundation.org> wrote: > > > > On Mar 10, 2014 8:01 AM, "H. Peter Anvin" <h...@linux.intel.com> wrote: > >> > >> I have mentioned in the past wanting to move the fixmap to the low part > >> of the kernel space, because the top isn't really fixed... > > > > How about the high part of the user address space, just above the stack? > > Leave a unmapped page in between, or something. The stack is already > > randomized, isn't it? > > For the !compat_vdso case, I don't like it -- this will put the vdso > (which is executable) at a constant offset from the stack, which will > make it much easier to use the vdso to defeat ASLR. > > For the compat_vdso case, this only works if the address is *not* > random, unless we're going to start giving each process its very own > relocated vdso. > > > > > That would actually be preferable in a few ways, notably not having to mark > > page directories user accessible in the kennel space area. > > Is that where the rabid pte dogs live? > > We can already avoid making fixmap pages user-accessible in the > !compat_vdso case for 32-bit tasks -- the vdso lives in a couple of > more-or-less ordinary vmas. >
What is now the next step? Kick out the compat VDSO? Or should i implement the dual VDSO. And what is now the preferred way to map the VDSO into the user space? Using install_special_mapping() or map it beyond the user stack? The is easiest and fastest way to get a working result is to do the non compat VDSO only mapping using install_special_mapping(). The dual VDSO would take a little bit more time. It would be great to have first a consensus about the design before i start to implement ;-) - Stefani -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
