Hacker News Reader

Comment by mkup | Hacker News Reader

Microkernels are interesting approach to resist Spectre and Meltdown attacks. Computational costs of KPTI + retpoline patches are already higher than computational costs of microkernel IPC. And properly implemented microkernel may never let privileged system code run on the same physical core(s) as user code, so microarchitectural leaks (cache state, branch prediction stats etc) which enable Spectre and Meltdown attacks are not possible in this design.

View on HN

Intel's L3 cache is inclusive. Spectre most definitely also applies across different cores.

Spectre attack relies on microarchitectural leaks of branch prediction statistics, which (according to my understanding) is not shared between cores in multi-core CPU.

If privileged system code never runs on the same physical core(s) as user code, and so we leave out branch prediction leaks, we are dealing only with cache timing leaks via L3 cache (Meltdown attack). But in the data segment of pure microkernel (which only does IPC and task switching) there's not much to hunt for.

No no no, you can easily train the branch predictor by sending a bunch of valid requests followed by an invalid request with a payload that redirects the ensuing speculative load into your desired address range.

Yes, but to do that, your code needs to use the same branch predictor as the victim code. If the branch prediction buffer is per-core and not shared among multiple cores, then that means you have to run on hte same core as the kernel. If the kernel always runs on a different core, you cannot do anything.

Spectre works across address spaces, user->user so how does a microkernel help?

It works across address spaces only if OS scheduler runs affected processes on the same CPU core, so hardware state of branch predictor is shared.

Reply on news.ycombinator.com