Re: [patch 0/5] Support for sanitization flag in low-level page allocator

Ingo Molnar
2009-05-30T17:49:25Z

* pageexec@freemail.hu <pageexec@freemail.hu> wrote:

> On 28 May 2009 at 11:08, Ingo Molnar wrote:
>
> >
> > * Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >
> > > > > As for being swapped out - I do not believe that kernel stacks can
> > > > > ever be swapped out in Linux.
> > > >
> > > > yes, i referred to that as an undesirable option - because it slows
> > > > down pthread_create() quite substantially.
> > > >
> > > > This needs before/after pthread_create() benchmark results.
> > >
> > > kernel stacks can end up places you don't expect on hypervisor
> > > based systems.
> > >
> > > In most respects the benchmarks are pretty irrelevant - wiping
> > > stuff has a performance cost, but its the sort of thing you only
> > > want to do when you have a security requirement that needs it. At
> > > that point the performance is secondary.
> >
> > Bechmarks, of course, are not irrelevant _at all_.
> >
> > So i'm asking for this "clear kernel stacks on freeing" aspect to be
> > benchmarked thoroughly, as i expect it to have a negative impact -
> > otherwise i'm NAK-ing this. Please Cc: me to measurements results.
>
> last year while developing/debugging something else i also ran some kernel
> compilation tests and managed to dig out this one for you ('all' refers to
> all of PaX):
>
> ------------------------------------------------------------------------------------------
> make -j4 2.6.24-rc7-i386-pax compiling 2.6.24-rc7-i386-pax (all with SANITIZE, no PARAVIRT)
> 565.63user 68.52system 5:25.52elapsed 194%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (1major+12486066minor)pagefaults 0swaps
>
> 565.10user 68.28system 5:24.72elapsed 195%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+12485742minor)pagefaults 0swaps
> ------------------------------------------------------------------------------------------
> make -j4 2.6.24-rc5-i386-pax compiling 2.6.24-rc5-i386-pax (all but SANITIZE, no PARAVIRT)
> 559.74user 50.29system 5:12.79elapsed 195%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+12397482minor)pagefaults 0swaps
>
> 561.41user 51.91system 5:14.55elapsed 194%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+12396877minor)pagefaults 0swaps
> ------------------------------------------------------------------------------------------
>
> for the kernel times the overhead is about 68s vs. 51s, or 40% in
> this particular case. while i don't know where this workload (the
> kernel part) falls in the spectrum of real life workloads, it
> definitely shows that if you're kernel bound, you should think
> twice before using this in production (and there's the real-time
> latency issue too).

Yes, clearing memory causes quite brutal overhead - as expected.

If only kernel stacks are cleared before reuse that will be less
overhead - but still it has to be benchmarked (and the overhead has
to be justified).

Ingo