Re: [PATCH v8 00/14] Function Granular KASLR

[Alexander Lobakin <alexandr.lobakin@intel.com>]

From: Peter Zijlstra <peterz@infradead.org>
Date: Fri, 3 Dec 2021 11:38:30 +0100

> On Thu, Dec 02, 2021 at 11:32:00PM +0100, Alexander Lobakin wrote:
> 
> > feat        make -j65 boot    vmlinux.o vmlinux  bzImage  bogoops/s
> > Relocatable 4m38.478s 24.440s 72014208  58579520  9396192 57640.39
> > KASLR       4m39.344s 24.204s 72020624  87805776  9740352 57393.80
> > FG-K 16 fps 6m16.493s 25.429s 83759856  87194160 10885632 57784.76
> > FG-K 8 fps  6m20.190s 25.094s 83759856  88741328 10985248 56625.84
> > FG-K 1 fps  7m09.611s 25.922s 83759856  95681128 11352192 56953.99
> 
> :sadface: so at best it makes my kernel compiles ~50% slower. Who would
> ever consider doing that? It's like retpolines weren't bad enough; lets
> heap on the fail?

I was waiting for that :D

I know it's horrible for now, but there are some points to consider:
 - folks who are placing hardening over everything don't mind
   compile times most likely;
 - linkers choking on huge LD scripts is actually a bug in their
   code. They process 40k sections as orphans (without a generated
   LD script) for a split second, so they're likely able to do the
   same with it. Our position here is that after FG-KASLR landing
   we'll report it and probably look into linkers' code to see if
   that can be addressed (Kees et al are on this AFAIU);
 - ClangLTO (at least "Fat", not sure about Thin as I didn't used
   it) thinks on vmlinux.o for ~5 minutes on 8-core Skylake. Still,
   it is here in mainline and is widely (relatively) used.
   I know FG-KASLR stuff is way more exotic, but anyways.
 - And the last one: I wouldn't consider FG-KASLR production ready
   as Kees would like to see it. Apart from compilation time, you
   get random performance {in,de}creases here-and-there all over
   the kernel and modules you can't predict at all.
   I guess it would become better later on when/if we introduce
   profiling-based function placement (there are some discussions
   around that and one related article is referred in the orig
   cover letter), but dunno for now.
   There's one issue in the current code as well -- PTI switching
   code is in .entry.text which doesn't currently get randomized.
   So it can probably be hunted using gadget collectors I guess?

Ok, so here's a summary of TODOs (not including sadfaces
unfortunately):
 * generate vmlinux.symbols and the corresponding variables
   on-the-go;
 * unify comparison and adjustment functions, probably reuse
   some of the already existing ones;
 * don't introduce new macros in linkage.h, just use fancy
   'section == .text' to decide in-place;
 * change new macros' names (those which shouldn' be wiped out)
   to make them more consistent;
 * look over for several code dups.

Am I missing anything else?

One more quest, what could I do with this infinitely long regexp
in gen_text_sections.pl script? Just try to wrap over or it can
be simplified somehow?

Al