Hi Norman,
I would like to comment on a few things...
Norman Feske (NF) wrote:
NF> In contrast to monolithic kernels, a microkernel like base-hw, NOVA, NF> or seL4 does not deal with any user-level content like cryptographic NF> secrets, or the content of files. There is hardly any credential to NF> leak to begin with. User content stays outside the microkernel.
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.
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.
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.
NF> Even though the Spectre attack affects components on top of Genode NF> that use a JIT-based VM, the microkernel cannot be easily targeted. NF> In contrast to the Linux kernel, which contains a JIT-based VM in NF> the form of the Berkeley Packet Filter, there is no way to NF> deliberately inject certain code patterns into a microkernel. In the NF> worst case, however, the kernel may already contain a code sequence NF> to exploit as a gadget. So it might be sensible to analyze the NF> kernel code in the light of the Spectre attack. Fortunately - in NF> contrast to a monolithic kernel - a microkernel is not a rapidly NF> moving target.
Indirect branch restricted speculation (IBRS) is a new x86 architecture extension to mitigate the effects of Spectre. It requires microcode patches that are rolling out right now. Retpolines is another (software-only) approach. Which one to use when gets messy very quickly: https://docs.google.com/document/d/e/2PACX-1vSMrwkaoSUBAFc6Fjd19F18c1O9pudkf...
NF> It is far too early to draw definite conclusions. E.g., it is unclear to NF> me if and how Intel's microcode updates [5] address parts of the NF> attacks.
Intel ucode adds IBRS.
NF> Since implementing mitigation measures will require significant effort, NF> and performance penalties are to be expected, we won't eagerly go NF> forward on our own right now. The scope and time frame of possible NF> mitigations come down to the priorities of Genode's commercial users.
IPC will definitely become slower as a result.
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?
Cheers, Udo