Hi Udo,
thank you for joining the discussion. Nice to see a life sign of you after so long time! ;-)
While it is true that a microkernel stores significantly fewer secrets than a monolithic kernel, like Linux, most microkernels actually have a full mapping of the entire physical memory in the kernel portion of each address space, which allows an attacker to peek anywhere into physical memory. This includes peeking at all page tables, followed by reading the memory pages of the desired user process via their physical backing store.
As confirmed by Stefan, Alexander, and you, both NOVA and our base-hw kernel do not have this problem. For seL4, let us see how the kernel developers respond to the issue. The other microkernels (OKL4, L4/Fiasco, Fiasco.OC, Pistachio) are not of much interest as we support them for nostalgic reasons only.
NF> There are in-kernel data structures like page tables and thread NF> control blocks. Hence, Meltdown may allow untrusted user code to NF> fingerprint the kernel or gather other information about those NF> in-kernel data structures. E.g., detect the presence of threads and NF> protection domains. It is currently unclear to me, in which ways an NF> attacker may exploit this meta data.
If an attacker can read the thread control block of other processes in the kernel, then he gets full access to the register state of preempted threads. The value of the instruction pointer and GPRs can be very valuable, for example when other processes are in the middle of crypto operations. The TCBs may actually be a lot more valuable than other kernel metadata.
True, it is bad. But let us acknowledge that the problem is at a different magnitude. With a monolithic kernel, an attacker can read secrets from the kernel at a rate of multiple KiB/sec. In contrast, the attack you sketched samples CPU registers of a remote thread at a rate of 100 times/sec (when the crypto-computing thread is preempted at the default time-slice length of 10ms, disregarding interrupts). Given that the secrets processed by the remote thread must be in CPU registers when the thread was preempted, information about crypto keys can leak only if they are currently in use. The economy of the attack is vastly different - it becomes similar to the cache-based side-channel attacks we already know and accept to exist.
Intuitively, I'd argue that if crypto material is valuable enough to justify the costs of such an attack, it should never be in reach of an Intel CPU that executes untrusted code to begin with. Instead it should stay on a dedicated smartcard, security token, trustzone-like enclave, or another form of HSM.
Please don't take my stance as an attempt to downplay the issue. Of course, I want to see it mitigated as it complicates our argumentation for co-hosting trusted and untrusted components side by side. If left unmitigated, we'd ultimately need to assess the possible impact of leaked in-kernel thread state, which is not a discussion I want to enter.
NF> Considering that a microkernel has a fairly low cache footprint and NF> only cached information can be leaked via Meltdown, it might be NF> interesting to get hold of the actual scope of information.
Meltdown can leak any information that is marked as "present" in the page tables of the current process. What's not currently cached can result in speculative cache fills, as long as the page is marked cacheable. So it's not just cached information that can leak, it's more.
...
Intel ucode adds IBRS.
Thank you for the clarification and the valuable pointers!
Since only Intel seems to be affected by Meltdown, the big question will be whether to use different page-table layouts for different vendors or to use the same layout for all. Would you be willing to degrade AMD IPC performance in favor of having one x86 kernel that works the same way everywhere rather than having multiple different implementations or different code paths that need independent testing/verification?
Given the scarcity of NOVA experts and maintainers, I would prefer to avoid special cases, even if it means that AMD performance unjustly suffers for the time being. I have to acknowledge that most of Genode's funding comes from users of Intel platforms.
Do you have a feeling how invasive such a change of NOVA would be?
Cheers Norman