On Tue, Jun 21, 2016 at 11:02 AM, Rik van Riel [off-list ref] wrote:

On Tue, 2016-06-21 at 10:16 -0700, Kees Cook wrote:

quoted

On Tue, Jun 21, 2016 at 2:24 AM, Arnd Bergmann [off-list ref] wrote:

quoted

On Monday, June 20, 2016 4:43:30 PM CEST Andy Lutomirski wrote:

quoted

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.

Does that imply we might want the per-cpu cache of
these stacks to be larger than one, in order to
introduce some more randomness after an attacker
crashed an ASLRed program looking for ROP gadgets,
and the next one is spawned? :)

This is the kernel stack, so this only really matters if there's some
attack in which you OOPS but learn the kernel stack address in the
process and then reuse that stack.  So... maybe?

--Andy