On Tue, Jun 21, 2016 at 12:47 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Tue, Jun 21, 2016 at 12:47 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >> On Tuesday, June 21, 2016 10:16:21 AM CEST Kees Cook wrote: >>> On Tue, Jun 21, 2016 at 2:24 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >>> > On Monday, June 20, 2016 4:43:30 PM CEST Andy Lutomirski wrote: >>> >> >>> >> On my laptop, this adds about 1.5µs of overhead to task creation, >>> >> which seems to be mainly caused by vmalloc inefficiently allocating >>> >> individual pages even when a higher-order page is available on the >>> >> freelist. >>> > >>> > Would it help to have a fixed virtual address for the stack instead >>> > and map the current stack to that during a task switch, similar to >>> > how we handle fixmap pages? >>> > >>> > That would of course trade the allocation overhead for a task switch >>> > overhead, which may be better or worse. It would also give "current" >>> > a constant address, which may give a small performance advantage >>> > but may also introduce a new attack vector unless we randomize it >>> > again. >>> >>> Right: we don't want a fixed address. That makes attacks WAY easier. >> >> Do we care about making the address more random then? When I look >> at /proc/vmallocinfo, I see that allocations are all using >> consecutive addresses, so if you can figure out the virtual >> address of the stack for one process that would give you a good >> chance of guessing the address for the next pid. > > Quite possibly. We should seriously consider at least randomizing the > *start* of the vmalloc area, at least on 64-bit architectures. Yup, this is already under way for x86. Thomas Garnier has a series that he's been working on: http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/log/?h=kaslr/memory I'd love to see similar for other architectures too. Thomas just sent me an updated series I'll be putting up for review later today. -Kees -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
