Meltdown and Spectre mitigations — a February update [LWN.net]

Meltdown and Spectre mitigations — a February update

Posted Feb 6, 2018 7:04 UTC (Tue) by mjthayer (guest, #39183)
Parent article: Meltdown and Spectre mitigations — a February update

I asked this in a previous comment section, but - is any work going into expanding the KPTI stub kernel which is still mapped into all processes? There must be enough code and data in the kernel which doesn't leak security-critical information which could safely live there, thereby reducing the performance hit for processes which need to use that code and data. Maybe it would even be possible to map page cache pages which a process has access to in that process's address space.

to post comments

Meltdown and Spectre mitigations — a February update

Posted Feb 6, 2018 14:16 UTC (Tue) by corbet (editor, #1) [Link] (5 responses)

I am not aware of such work. The focus is still very much on dealing with corner cases and ensuring that everybody is protected. In truth, I'd be surprised to see work on expanding the amount of the kernel exposed when running in user mode. The gain would be small (I believe), the security risks would be real, and any benefits would be fleeting since future processors will not, one hopes, have this vulnerability in the first place.

Meltdown and Spectre mitigations — a February update

Posted Feb 6, 2018 16:07 UTC (Tue) by Paf (subscriber, #91811) [Link] (4 responses)

John,

That seems to run counter to something I read - in one of the many Meltdown/Spectre articles here - suggesting that KPTI is a "big hammer" that will deal with many potential speculative execution derived security holes. This seems to imply that the speaker (I believe it was a kernel developer) thinks it's likely KPTI will be needed in the future, even once Meltdown is fixed (as of course it should be in future hardware).

Any thoughts?

Meltdown and Spectre mitigations — a February update

Posted Feb 6, 2018 16:13 UTC (Tue) by corbet (editor, #1) [Link] (3 responses)

KPTI does have the advantage of providing SMEP emulation for free on x86, so that might be a reason to keep it around. I'd still be surprised to see anybody working to move kernel-space memory back into the user-space page tables, though. The ratio of risk to performance gain seems way too high.

Meltdown and Spectre mitigations — a February update

Posted Feb 6, 2018 16:53 UTC (Tue) by corsac (subscriber, #49696) [Link] (2 responses)

But future processors with RDCL_NO (protection against Meltdown) are likely to have SMEP/SMAP support.

And past processors without SMEP are unlikely to have PCID, so the cost of KPTI is huge there.

Meltdown and Spectre mitigations — a February update

Posted Feb 7, 2018 15:19 UTC (Wed) by MarcB (subscriber, #101804) [Link] (1 responses)

The cost is fixed per syscall. So it is marginal for many workloads, even on old CPUs. And, of course, horrible for others, even on modern CPUs.

I am wondering, if it would be possible to lower the cost significantly. There are architectures - like SPARC - where separate address spaces are mandatory, after all. Did they accept the performance penalty or have they put thought - and silicone - into optimizing this? (Likely: both).

From a layman's view, separate address spaces seem like the "cleaner" solution.

Meltdown and Spectre mitigations — a February update

Posted Feb 7, 2018 15:21 UTC (Wed) by MarcB (subscriber, #101804) [Link]

I'd like to retract an 'e' :-)