PowerPC Memory Protection Keys In For Linux 4.16, Power Has Meltdown Mitigation In 4.15

[phoronix]

Phoronix: PowerPC Memory Protection Keys In For Linux 4.16, Power Has Meltdown Mitigation In 4.15

Linux's POWER code with the upcoming Linux 4.16 cycle will introduce support for PowerPC Memory Protection Keys. With the current Linux 4.15 cycle is also initial Meltdown mitigation for these CPUs too...

http://www.phoronix.com/scan.php?page=news_item&px=PowerPC-Mem-Protection-Keys

[hiryu]

Michael,

Hopefully you can get access. I'm very interested in see what the impact is.

[phoron]

Indeed, some performance hints would be interesting (either from IBM themselves, phoronix or anyone else more neutral than IBM). In the commit message I read

In order for that [vulnerability] to happen, the first load must hit in the L1, because before the load is sent to the L2 the permission check is performed. Therefore if no kernel addresses hit in the L1 the vulnerability can not occur. We can ensure that is the case by flushing the L1 whenever we return to userspace. Similarly for hypervisor vs guest.

I get mixed feelings on whether flushing the L1 cache should impact performance a lot or a little:

• Flushing caches kills performance in general.
• The L1 cache is smallish, so it is not as severe as flushing a bigger cache.
• But the L1 cache is fast, so loses there are very slow compared to hits.
• The contents in the cache from kernelspace should not be needed in userspace and vice versa. Flushing just in the context switch should not cause many misses, I would only expect misses after the next switch returns to the original context (whenever the process without the flush would still have cache lines from the original context). So high performance impact would only come if there are very rapid user-kernel-user-kernel... switches. Not really fast, more like little enough code so as to not access a lot of memory, which might be more or less code or more or less time depending on what the code does.
• I assume the flushing itself is fast, the performance degradation comes from any cache misses it causes. This may depend on CPU version (flushing NOP being faster than flushing by a software loop).

On the other hand, avoiding the fix might be more of an option, since it reads as if the vulnerability is not so serious as on Intel. In Intel it sounds like the attack can read arbitrary memory at some speed, but in Power it looks like it can only read whatever is already in the L1 cache, not any address.
I guess tricking the kernel into accessing the memory you want to exfiltrate before you do the attack slows it down further if at all possible.

But what do I know ?