Hello,

I am sure that most of you have seen the seismic effects of the Meltdown and Spectre attacks [1] that were made public two days ago. Since both attacks target the hardware rather than a particular software vulnerability, all operating systems and hypervisors are affected - more or less. I do not want to repeat the technical details of the attacks here. The security advisories listed on the bottom of the website [1] do an excellent job with explaining the problem (e.g., the issue description of Xen's advisory [2] is concise and easy to understand).

The mind-bending technical work behind these attacks is described in detail at Google's Project Zero website [3]. It's truly fascinating!

[1] https://meltdownattack.com/ [2] https://xenbits.xen.org/xsa/advisory-254.html [3] https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with...

The attacks question our universal assumptions about the effectiveness of hardware-based protection mechanisms present in modern CPUs. They leverage CPU caches to leak information between protection boundaries. Since caches are a shared physical resources, it is hardly surprising that they are prone to crosstalk between protection boundaries, e.g., as demonstrated before by covert timing channels that use the 2nd-level cache as communication channel.

However, the attacks are spectacular because they trick the CPU's mechanics for speculative execution to deliberately leak protected information into the caches. The Meltdown attack allows user-level code to obtain information that are normally private to the kernel. The Spectre attack allows a sandboxed program running in a JIT-based VM (like Javascript) to obtain information about the sandbox (e.g., the browser that executes the Javascript code).

Given the structure of today's commodity operating systems and hypervisors, the implications of the attacks are near to impossible to grasp. E.g., the Linux kernel is entrusted with cryptographic keys and passwords assuming that user-level programs cannot access this information without authorization. This premise is broken by the Meltdown attack. To uphold it, kernel developers are accepting mitigation measures that come with significant performance penalties. The IT industry has to collectively suffer under either the attacks or the mitigations.

Impact on Genode ----------------

It is too early to give a detailed assessment. My initial knee-jerk reaction was that we'd have to follow Linux with completely separating the virtual address spaces of the kernel and the user land. The irony is that our custom base-hw kernel actually used to keep the kernel in a dedicated virtual address space - until three months ago when we reworked the kernel to follow the main stream where the kernel is mapped in each user-level address space as privileged pages. In principle, we could revert this optimization. For NOVA, this change would require more significant effort. According to seL4 mailing list [4], there is work in progress to address the Meltdown attack on seL4.

[4] http://sel4.systems/pipermail/devel/2018-January/001809.html

Before going forward with implementing costly mitigations, however, we should get a clearer picture of risks of the attacks for Genode. My current thoughts are as follows:

* In contrast to monolithic kernels, a microkernel like base-hw, NOVA, or seL4 does not deal with any user-level content like cryptographic secrets, or the content of files. There is hardly any credential to leak to begin with. User content stays outside the microkernel.

* The only memory pages accessed by both kernel and user land are the so-called user-level thread-control blocks (UTCB, on seL4 they are called IPC buffer). The Meltdown attack could in principle allow two conspiring user-level components to create a covert timing channel via UTCBs. However, since both components share the 2nd-level cache anyway, they could create a covert timing channel even without Meltdown. Covert timing channels between Genode components are not addressed by any of Genode's underlying kernels so far.

* There are in-kernel data structures like page tables and thread control blocks. Hence, Meltdown may allow untrusted user code to fingerprint the kernel or gather other information about those in-kernel data structures. E.g., detect the presence of threads and protection domains. It is currently unclear to me, in which ways an attacker may exploit this meta data. But given the creativity of attackers, we should be pessimistic. To get a better picture, it might be a good idea to execute the Meltdown attack on different kernels to see the actual information that can be leaked. Considering that a microkernel has a fairly low cache footprint and only cached information can be leaked via Meltdown, it might be interesting to get hold of the actual scope of information.

* Even though the Spectre attack affects components on top of Genode that use a JIT-based VM, the microkernel cannot be easily targeted. In contrast to the Linux kernel, which contains a JIT-based VM in the form of the Berkeley Packet Filter, there is no way to deliberately inject certain code patterns into a microkernel. In the worst case, however, the kernel may already contain a code sequence to exploit as a gadget. So it might be sensible to analyze the kernel code in the light of the Spectre attack. Fortunately - in contrast to a monolithic kernel - a microkernel is not a rapidly moving target.

It is far too early to draw definite conclusions. E.g., it is unclear to me if and how Intel's microcode updates [5] address parts of the attacks. It is obvious how badly our today's commodity OSes suffer from these attacks. Fortunately for Genode, our OS architecture that sandboxes code and information at a fine granularity (and outside the kernel), the impact for Genode users is far less dramatic for sure, but still uncertain.

Since implementing mitigation measures will require significant effort, and performance penalties are to be expected, we won't eagerly go forward on our own right now. The scope and time frame of possible mitigations come down to the priorities of Genode's commercial users.

[5] https://newsroom.intel.com/news-releases/intel-issues-updates-protect-system...

Best regards Norman