Side-channel attacks (Meltdown, Spectre)

[Norman F. <nor...@ge...>]

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-side.html

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-systems-security-exploits/

Best regards
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth