Item — HN Reader

> All the ugly CPU vulnerabilities make context switching very, very slow. A microkernel needs to contest switch more than a monolithic kernel, and the overhead keeps increasing.

In the case of the Zircon microkernel in Fuchsia, unlike Linux, almost all system-calls are asynchronous/non-blocking with a small number that are blocking [0], which is interesting since the OS is also fundamentally optimised for multi-core systems. Combined with both features, it makes it very suitable for real-time based applications, something that Linux is not optimised for and requires fundamental tweaking and changes for Linux or even some other traditional microkernels to achieve.

Thus, I doubt that on a system like Fuchsia/Zircon, the context switch would be notably 'very, very slow', even if Fuchsia was running on modern-hardware optimised for microkernels such as Zircon if that were to happen.

[0] https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master...

3 comments

Reading around, Zircon syscalls are non-blocking at the scheduler level. Each syscall still requires a full context switch into kernel mode, though.

They can probably do some smart stuff with having each syscall just add stuff to a work queue so userspace can resume as quickly as possible, but it's still fundamentally more context switches than e.g. Linux would have, which if side-channel attacks keep coming out might be a problem for them.

My impression on systems from the days before linux/Intel began having real SMP is that if you are willing to go off the rails completely on supporting 1-2 core machines and making every CPU available to every task, then blocking side channel attacks no longer requires all the work..

If mitigation is starting to amount to ~20%, that's roughly a CPU and soon to be 2-3, that can be told to never process directly for Userland and never tell Userland when exactly output queue contents of sensitive tasks become available. All that work essentially being free compared to running with Intel's fixes and full CPU flexibility.

I’m not sure why you think syscalls all being async means that the mitigations don’t have as much of an impact.

They still require a context switch to access the protected memory in order to enqueue the async request.

Can you expand on your reasoning?

Exactly. In fact you'll now need two calls per operation, one to submit it and one to fetch the results.

You might make submission lazy and ond only actually submit all queued operations on the poll call, but it is not much better.

> Fuchsia/Zircon, the context switch would be notably 'very, very slow

The part that the Intel fixes makes slow is the mode switch, since you need to flush caches and trash data that may leak. Making it async doubles (at minimum) the number of mode switches needed to do work.