Side-channel attacks (Meltdown, Spectre)

[Norman Feske]

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

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.genode.org/pipermail/users/attachments/20180106/5b19a332/attachment.sig>