[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2236FBA76BA1254E88B949DDB74E612BA4BB7580@IRSMSX102.ger.corp.intel.com>
Date: Fri, 8 Feb 2019 13:20:09 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: "kernel-hardening@...ts.openwall.com"
<kernel-hardening@...ts.openwall.com>, "luto@...nel.org" <luto@...nel.org>,
"tglx@...utronix.de" <tglx@...utronix.de>, "mingo@...hat.com"
<mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>, "keescook@...omium.org"
<keescook@...omium.org>, "tytso@....edu" <tytso@....edu>
Subject: RE: [RFC PATCH] x86/entry/64: randomize kernel stack offset upon
system call
> On Fri, Feb 08, 2019 at 02:15:49PM +0200, Elena Reshetova wrote:
> > 1) hackbench -s 4096 -l 2000 -g 15 -f 25 -P
> > base: Time: 12.243
> > random_offset: Time: 13.411
>
> > base:
> > 8.46% time [kernel.kallsyms] [k] crc32c_pcl_intel_update
> > 4.77% time [kernel.kallsyms] [k] ext4_mark_iloc_dirty
> > 4.14% time [kernel.kallsyms] [k] fsnotify
> >
> > random_offset:
> > 8.35% time [kernel.kallsyms] [k] crc32c_pcl_intel_update
> > 5.61% time [kernel.kallsyms] [k] get_random_u64
> > 4.88% time [kernel.kallsyms] [k] ext4_mark_iloc_dirty
>
> *ouch*
>
> > Notable differences from RANDKSTACK:
>
> > - random bits are taken from get_random_long() instead of
> > rdtsc() for a better randomness. This however has a big
> > performance impact (see above the numbers) and additionally
> > if we happen to hit a point when a generator needs to be
> > reseeded, we might have an issue. Alternatives can be to
> > make this feature dependent on CONFIG_RANDOM_TRUST_CPU,
> > which can solve some issues, but I doubt that all of them.
> > Of course rdtsc() can be a fallback if there is no way to
> > make calls for a proper randomness from the trampoline stack.
>
> http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html
Oh, this seems to be a great write up, I will read this carefully,
thank you for the pointer!
Yes, I believe RANDKSTACK was using rdtsc() exactly because of
many issues get_random_* brings in addition to horrid performance.
This patch works with rdtsc() as well just fine, just wanted to show
the *full* randomness option first with the impact it brings.
>
> That would seem to suggest that the low bits of rdtsc would in fact be a
> fairly good source of random.
>
> Still, doing this on sysexit seems painful at best, syscall performance
> matters (and hopefully we'll get rid of meltdown 'soon').
I can measure the impact with rdtsc(), I think it is *very* small.
Btw, what should be the good measurement test?
I am not that happy with just looping on fopen-fclose, too
much noise.
>
> Why can't we change the stack offset periodically from an interrupt or
> so, and then have every later entry use that.
Hm... This sounds more complex conceptually - we cannot touch
stack when it is in use, so we have to periodically probe for a
good time (when process is in userspace I guess) to change it from an interrupt?
IMO trampoline stack provides such a good clean place for doing it and we
have stackleak there doing stack cleanup, so would make sense to keep
these features operating together.
Best Regards,
Elena.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
