On Fri, Dec 03, 2021 at 03:41:36PM +0100, Alexander Lobakin wrote:

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

quoted

On Thu, Dec 02, 2021 at 11:32:00PM +0100, Alexander Lobakin wrote:

quoted

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?

Oooh, so those compile times are not, as one would expect the compile
times for a set .config but with different kernel, but instead for a
varying .config on the same kernel?

IOW, they don't represent the run-time overhead of this thing, but
merely the toolchain overhead of all this.

So what is the actual runtime overhead of all this?