Benchmarking The Performance Overhead To Linux's Proposed FGKASLR Security Feature

[tildearrow]

Did you use a digital effect to create that picture?

(or did you really put the processor underwater?)

[Space Heater]

I'm surprised KASLR has any impact whatsoever on performance.
I'm curious if this is test variability since KASLR actually does randomize stuff or if it is actually slower all the time?

My first guess would be that randomizing the location of kernel functions impacts locality which could cause additional i-cache misses when running kernel code.

[milkylainen]

My first guess would be that randomizing the location of kernel functions impacts locality which could cause additional i-cache misses when running kernel code.

Not FGKASLR. FGKASLR is fully understandable. You're rewriting the layout of your code.
So performance will most likely suffer, for a bunch of reasons.

I mean just KASLR.
The _entire_ object is relocated to a random base. Why that would matter is not obvious to me.
That's like saying "Your machine will be slower if you relocate with 32G RAM instead of 16G RAM, because you know. Addresses at 32G are bad...."
Err?
I smell something fishy is lurking behind the performance drop of KASLR.

[baka0815]

Probably just in boxes, I don't think anything in the racks anymore. If I see a Bulldozer system still in a rack, will run some tests as I think I have a 3770K still in the racks, but otherwise not worth the time/energy digging them out of boxes.

Sounds like you would need to get convinced to do this - how high does the tip need to be to persuade you?

[GreenReaper]

I mean just KASLR.
The _entire_ object is relocated to a random base. Why that would matter is not obvious to me.
That's like saying "Your machine will be slower if you relocate with 32G RAM instead of 16G RAM, because you know. Addresses at 32G are bad...."
Err?
I smell something fishy is lurking behind the performance drop of KASLR.

You don't know the addresses. So the kernel can't rely on module X being at location Y, etc. This makes things slower. Potentially you could avoid this by compiling everything without modules.

I believe you also have to flush things like the BTB and TLB on context switch to avoid leakage of addresses, which may not be a concern if you don't care about revealing those addresses. (You might have to turn off mitigations more generally to avoid this cost, I doubt that's a factor in the performance graphs here.)