Side-channel attacks (Meltdown, Spectre)

[Udo Steinberg]

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-1vSMrwkaoSUBAFc6Fjd19F18c1O9pudkfAY-7lGYGOTN8mc9ul-J6pWadcAaBJZcVA7W_3jlLKRtKRbd/pub

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 163 bytes
Desc: OpenPGP digital signature
URL: <http://lists.genode.org/pipermail/users/attachments/20180105/5780eebb/attachment.sig>