Hi,
On 2018-0105 at 20:24:19 +0100, Alexander Boettcher wrote:
Hi Udo,
On 05.01.2018 17:36, Udo Steinberg wrote:
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.
before starting to dig/read through all our supported kernels (I'm not all familiar with the internals) - can you please elaborate a bit about which microkernels, according to your knowledge, have all physical memory mapped in the kernel ?
The currently supported microkernels for Genode are Pistachio, OKL4, L4/Fiasco, Fiasco.OC, Nova, seL4 and our own hw kernel.
I would like to give a comment on Fiasco.OC. Fiasco.OC / L4Re is vulnerable to Meltdown-like attacks because the kernel is mapped into each task. However, the kernel does not map all physical memory but only memory it requires for its own data structures + kernel-user memory required for e.g. UTCBs and vCPU state save areas. Depending on the amount of physical memory and the available page sizes, Fiasco.OC may map it little bit more than that to save TLB entries. That means there can be a slight overlap of user memory that is visible to the kernel. But it is not possible for a thread to read _all_ memory.
Because we think that no thread should read information from other threads (pagetables, capability arrays, UTCBs etc.) we will change Fiasco.OC to execute in its own address space on Intel CPUs.
Against Spectre we do not plan to implement anything right now. We think the attack surface of the kernel is very little (if any) and may be even further reduced with Intel's microcode updates and future compiler/tool mitigations. However, we will observe future discussions and developments and may reassess this in the future.
Thank you and regards, Matthias.