The effect of Meltdown and Spectre in our communities

Posted Feb 5, 2018 4:55 UTC (Mon) by immibis (subscriber, #105511)
In reply to: The effect of Meltdown and Spectre in our communities by hansendc
Parent article: The effect of Meltdown and Spectre in our communities

You can go even further in the performance vs. security tradeoff: I wonder if anyone's tried adding an option to disable all memory protection. A syscall is then just a call.

The effect of Meltdown and Spectre in our communities

Posted Feb 7, 2018 2:09 UTC (Wed) by nix (subscriber, #2304) [Link] (3 responses)

Ah, but that's also performance versus *stability*: every wild pointer bug can murder you. Spectre and Meltdown are unlikely to be triggered by accident. :)

The effect of Meltdown and Spectre in our communities

Posted Feb 8, 2018 6:18 UTC (Thu) by immibis (subscriber, #105511) [Link] (2 responses)

Well then here's an option in-between "no memory protection" and "normal pre-meltdown memory protection" - use a memory protection key for kernel space.

User-space code then can unlock the key at any time, but needs to use a special instruction to do so, so it's unlikely to happen by accident.

The effect of Meltdown and Spectre in our communities

Posted Feb 9, 2018 1:54 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

I'm fairly sure memory protection keys are for fairly small amounts of memory, and they protect *physical* memory, not chunks of the virtual address space and definitely not chunks of the virtual address space under specific privilege levels, magically autodecrypting at zero cost as you switch privilege levels: i.e. either kernel memory is encrypted, or it is not. If it's encrypted, kernel operations aren't exactly going to be very fast.

The effect of Meltdown and Spectre in our communities

Posted Feb 9, 2018 5:31 UTC (Fri) by immibis (subscriber, #105511) [Link]

Not those kinds of keys.
MPKs are tag bits associated with each page-table entry, which indirectly look up permissions in another processor register. See https://lwn.net/Articles/667156/

So you leave all user-space pages set to 0, for example, and set kernel pages to 1 (except for one containing the kernel entry point). Then you set the "MPK 1 permissions" register to write-disable, read-disable, execute-disable. Then when entering the kernel you clear those flags, and set them again when leaving. The "MPK 1 permissions" register is global, it's not part of the page-table entry.

Normally you wouldn't do this because the "set permissions register" instruction is not privileged, meaning any code can run it. But if you were trying to run a high-performance minimal-security still-somewhat-robust system, you might!