Spectre mitigations murder userspace performance

Re:Spectre mitigations murder userspace performance by rbanffy on Saturday June 19, 2021 @04:28PM (#27564163)

If you are pinned to a core, as non burstable instances should be, you are still pretty much vulnerable. Having noisy neighbours will pollute caches and make extracting data harder, but, eventually, everything will leak out.

I’ve been thinking what would happen if cores would be pinned to separate security domains - all kernel processes run on one set of cores and user processes on others. I imagine microkernel OSs could go that way much easier. If kernel and user space communicate only by messages and shared data, there’s no reason they’d need to even share an ISA.

[ Parent | on HN ]

Re:Spectre mitigations murder userspace performance by amelius on Saturday June 19, 2021 @05:25PM (#27564591)

Isn't the entire memory hierarchy (caches) part of the problem?

[ Parent | on HN ]

Re:Spectre mitigations murder userspace performance by rbanffy on Saturday June 19, 2021 @07:04PM (#27565345)

Yes. You’d need to split caches by security context too.

[ Parent | on HN ]

Re:Spectre mitigations murder userspace performance by lanstin on Sunday June 20, 2021 @01:28AM (#27567370)

Maybe each security context needs to be in its own cloud account and own network. Long ago it was an axiom that if you share a call stack in a process you trust each other. Perhaps the current truth is if you share hardware you trust each other.

[ Parent | on HN ]

Re:Spectre mitigations murder userspace performance by rbanffy on Sunday June 20, 2021 @03:36AM (#27567970)

That should work with multiple services, but not in a user/kernel split as we have today.

[ Parent | on HN ]