KInit - Current state and benchmarks

[Alexander Richardson]

On Sat, 22 Jun 2019 at 11:21, David Edmundson
<david at davidedmundson.co.uk> wrote:
>
> Benchmarks of dolphin on a low end ARM laptop:
>  Dolphin via QProcess: 1233ms
>  Dolphin via Kinit: 1144ms
>
> again a consistent saving in the order of ~7%
>
> Initially I had wanted to scrap it, I'm now very conflicted.
>
> I'll try to port all of plasma services to use it properly again and
> see what difference that makes across a broad context over a wider
> range of services.
>
> David

Hi David,

There is also one more thing we might want to take into account:
Kinit mostly breaks ASLR since all libraries will have libc, QtBase,
etc mapped at the same address if we do fork() without execve(). This
makes code reuse attacks a bit easier since the attacker can reuse the
guessed addresses for all base libraries. Only the executable and any
libraries loaded by the executable will have randomized addressed.

However, in my opinion all probabilistic vulnerability mitigation
schemes such as ASLR are not particularly useful since they just make
it more difficult for an attacker rather than actually preventing the
attack.
Moreover, it has been shown that ASLR can be broken due to MMU
side-channels (even from JavaScript running in a browser sandbox!) [1]
or if you have a fork()ing server (which is similar to the kinit
case)[2].
Upcoming CPUs will have more useful features to partially enforce
control flow integrity (Intel Control-flow Enforcement Technology
(CET) or ARM Branch Target Indicators (BTI)) which should be more
effective than ASLR.

Personally, I think it makes sense to keep kinit if it speeds up
start-up by 7% even if it (mostly) breaks ASLR since ASLR is already
pretty much broken. Also we have been doing this for years and I don't
think there has been a CVE because of kinit not randomizing some
library locations.

I am currently working on CHERI [3], an ISA extension that adds
128-bit capabilities (essentially pointers with bounds and
permissions) to the MIPS (and RISC-V) ISAs. We currently run
everything on a 100Mhz FPGA so I'm sure the start-up time would be
quite noticeable there. I have not yet managed to get kinit to compile
but we do have QtBase and QtWebkit working. It shouldn't be too hard
to compile kinit and run the measurements but I doubt I will have time
to do that in the next month or two.

In the past few years I've done quite a lot of work with the FreeBSD
runtime linker. Based on my current measurements of relocation
processing in the runtime linker, it can take a lot of time to resolve
all symbols (especially if lazy binding is disabled by linking with -z
now) and to process all relocations.
I believe LD_BIND_NOW/-z now is becoming the default in some
distributions since it allows mapping the GOT read-only after
relocation processing and therefore slightly reduces the attack
surface.
Kinit allows us to skip those steps for some of the libraries so it
should always be a noticeable performance win.

Alex

[1] https://www.vusec.net/projects/anc/
[2] www.scs.stanford.edu/brop/bittau-brop.pdf
[3] http://chericpu.com