From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
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
