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.