users

users@lists.genode.org

7 participants
2332 discussions

Re: Side-channel attacks (Meltdown, Spectre)
by Udo Steinberg 08 Jan '18

08 Jan '18

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-1vSMrwkaoSUBAFc6Fjd19F18c1O9pudk… 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

5 8

Help : booting genode with nova: kernel not found
by jony jony 08 Jan '18

08 Jan '18

So i did the following : i build genode with nova kernel on the / directory, i was able to start the demo even though it got blocked probably lack of free memory, mucomp:/genode$ ls build build.lx demo doc *nova_d*ir repos VERSION build1.lx contrib depot LICENSE README tool then i created another genode directory in the boot directory where i copied the whole /genode folder , and then i entered the /boot directory and created a symbolic link as follow: ln -s /genode /genode/nova_build_dir/var/run/demo i also tried copying in another scenario only the content of /genode/nova_build_dir/var/run/demo which contains drwxr-xr-x 3 root root 4096 Jan 7 06:24 ./ drwxr-xr-x 3 root root 4096 Jan 7 06:24 ../ drwxr-xr-x 3 root root 4096 Jan 7 06:24 boot/ lrwxrwxrwx 1 root root 7 Jan 7 06:24 genode -> /genode/ -rwxr-xr-x 1 root root 125676 Jan 7 06:24 hypervisor* -rwxr-xr-x 1 root root 2878008 Jan 7 06:24 image.elf.gz* then i created a file in /etc/grub.d/49_genode1 cat 49_genode1 #!/bin/sh -e echo "Genode@...153..." cat << EOF menuentry "Genode@...153..." { insmod ext2 multiboot /genode/hypervisor module /genode/core module /genode/config config module /genode/init init module /genode/timer timer module /genode/nitpicker nitpicker module /genode/liquid_fb liquid_fb module /genode/launchpad launchpad module /genode/scout scout module /genode/testnit testnit module /genode/nitlog nitlog module /genode/pci_drv pci_drv module /genode/vesa_drv vesa_drv module /genode/ps2_drv ps2_drv } Genode@...153... appears on the grub once i try to load it , but i get the error file '/genode/hypervisor' not found and for the other module i get the message : you need to load the kernel first I tried different possibilities but none of them is working , can i get some help please; thanks

3 2

Increased C++ warning level
by Norman Feske 06 Jan '18

06 Jan '18

Hello, hereby, I'd like to give you a little heads-up warning about a change recently added to our staging branch: The compiler flags -Wextra, -Weffc++, and -Werror are now enabled in addition to -Wall for compiling C++ components. If this strict warning level is inapplicable for a given component or library, it is possible to explicitly disable the strictness in the respective build-description file by adding following line: CC_CXX_WARN_STRICT = I adjusted almost all the code of the base, base-<kernel>, os, and demo repositories to comply with the new warning level. For most components hosted in the higher-level repositories (libports, ports, dde_*, gems), I disabled the strictness. My goal is to remove the 'CC_CXX_WARN_STRICT' declarations from those components, wherever feasible. But this is not for now. While adjusting our code base, I identified the following patterns worth reporting (the items below are cited from my commit message): * A class with virtual functions can no longer publicly inherit base classes without a vtable. The inherited object may either be moved to a member variable, or inherited privately. The latter would be used for classes that inherit 'List::Element' or 'Avl_node'. In order to enable the 'List' and 'Avl_tree' to access the meta data, the 'List' must become a friend. * Instead of adding a virtual destructor to abstract base classes, we inherit the new 'Interface' class, which contains a virtual destructor. This way, single-line abstract base classes can stay as compact as they are now. The 'Interface' utility resides in base/include/util/interface.h. * With the new warnings enabled, all member variables must be explicitly initialized. Basic types may be initialized with '='. All other types are initialized with braces '{ ... }' or as class initializers. If basic types and non-basic types appear in a row, it is nice to only use the brace syntax (also for basic types) and align the braces. * If a class contains pointers as members, it must now also provide a copy constructor and assignment operator. In the most cases, one would make them private, effectively disallowing the objects to be copied. Unfortunately, this warning cannot be fixed be inheriting our existing 'Noncopyable' class (the compiler fails to detect that the inheriting class cannot be copied and still gives the error). For now, we have to manually add declarations for both the copy constructor and assignment operator as private class members. Those declarations should be prepended with a comment like this: /* * Noncopyable */ Thread(Thread const &); Thread &operator = (Thread const &); In the future, we should revisit these places and try to replace the pointers with references. In the presence of at least one reference member, the compiler would no longer implicitly generate a copy constructor. So we could remove the manual declaration. Even though at times, the strict warning level seems like a nuisance (like the need to explicitly call default constructors of all member variables even if they are objects), it rules out certain classes of bugs (like uninitialized member variables) and gently pushes us to better software design. In particular, I found that Weffc++ forces one to think more carefully about the role of a struct/class. In D, 'class' and 'struct' are two different things. A struct is essentially a record of data (it has no vtable). A class implements an interface (it always has a vtable). In regular C++, the line is blurry. Weffc++ points out the blurriness, which is good. Should you encounter problems with compiling your components with the new Genode version, please consider commenting in the corresponding issue [1]. [1] https://github.com/genodelabs/genode/issues/465 The following caveats are expected, even if you disable the strictness in your component: * If your component has a class called 'Interface', it may collide with the new 'Genode::Interface' class. You may have to disambiguate the names. * The 'Genode::Rpc_client' is no longer a 'Genode::Capability'. Hence, classes inherited from 'Genode::Rpc_client' cannot refer to 'Capability' but must refer to 'Genode::Capability'. * The 'Surface' class is no longer copyable, which led to API changes of users of this class. E.g., the 'Nitpicker_buffer' utility does no longer offer accessors for the contained surfaces but a new 'apply_to_surface' method that takes a lambda function as argument. 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

1 0

Side-channel attacks (Meltdown, Spectre)
by Norman Feske 05 Jan '18

05 Jan '18

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-wit… 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-syste… 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

2 1

Constrained file descriptors
by Johannes Kliemann 05 Jan '18

05 Jan '18

Hi Norman, before Christmas we chatted about enabling the MMIO session on Linux. You said that you know a possibility to create constrained file descriptors (in such a way that accesses through this descriptor can only access a part of the file). I've done a second search but I couldn't find any useful information regarding this topic. Do you have any further, more specific, information about how to achieve this goal? Regards, Johannes

3 4

Disk images for ARM based Genode Scenarios
by Baconicsynergy 04 Jan '18

04 Jan '18

Thank you very much for the quick response, Stefan :) I built a simple log Genode scenario for wand_quad for testing purposes, and I am previously used to receiving iso images for x86_32/x86_64. However, there is no iso image! I am left with a log.core file in the var/run directory and I don't know how to construct a bootable microSD card image from these files. Forgive my ignorance, and many thanks for the help!! Joel Desermeau

3 2

Donate to Genode
by Baconicsynergy 03 Jan '18

03 Jan '18

I would love to make a donation to the Genode project! How should I go about doing this? I encourage everyone reading this to donate as well!

1 0

Sabre Lite imx6
by Baconicsynergy 02 Jan '18

02 Jan '18

Hello friends :) I am now the proud owner of the sabre lite imx6 SoC for the purpose of experimenting and running seL4, and am really eager to start building Genode scenarios. Unfortunately, the create_builddir tool only specifies imx53. What can i do to start working with genode on the sabre lite? Best regards, Joel Desermeau

3 2

Decentralized reproducible packages distribution system
by Michael Bideau 29 Dec '17

29 Dec '17

Hi everyone, I'm very new to Genode (discovered last week with seL4), so please forgive my lack of experience. I just wanted to bring you some information that might interest you, may be not today but soon (I hope). I stumble accross CHAINIAC <https://eprint.iacr.org/2017/648.pdf> (Usenix presentation video <https://www.usenix.org/conference/usenixsecurity17/technical-sessions/prese…>), a system to distribute software with many nice properties, that might be used for Debian packages one day. I copy-past Bryan Ford (co-author) description emailed at IEFT <https://www.ietf.org/mail-archive/web/suit/current/msg00154.html> : Abstract: Software-update mechanisms are critical to the security of modern systems, but their typically centralized design presents a lucrative and frequently attacked target. In this work, we propose CHAINIAC, a decentralized software-update framework that eliminates single points of failure, enforces transparency, and provides efficient verifiability of integrity and authenticity for software-release processes. Independent witness servers collectively verify conformance of software updates to release policies, build verifiers validate the source-to-binary correspondence, and a tamper-proof release log stores collectively signed updates, thus ensuring that no release is accepted by clients before being widely disclosed and validated. The release log embodies a skipchain, a novel data structure, enabling arbitrarily out-of-date clients to efficiently validate updates and signing keys. Evaluation of our CHAINIAC prototype on reproducible Debian packages shows that the automated update process takes the average of 5 minutes per release for individual packages, and only 20 seconds for the aggregate timeline. We further evaluate the framework using real-world data from the PyPI package repository and show that it offers clients security comparable to verifying every single update themselves while consuming only one-fifth of the bandwidth and having a minimal computational overhead. It uses blockchain, but it is an optional feature (as discussed in the Q&A at the end of the Usenix Conference <https://youtu.be/xpT6L8htINU?t=24m18s>) as long as you can check servers of the Cothority (if I have understood it well). It is written in Go (github repo <https://github.com/dedis/paper_chainiac>). On the subject of application portability/deployment, I know there is a lot of initiatives trying to normalize application packaging in a Linux kernel context, like OCI <https://www.opencontainers.org/>, Habitat <https://www.habitat.sh/>, Flatpak <https://flatpak.org/>, each targetting a different audience (cloud/desktop). It might be an interesting combination with Chainiac... I don't know. That was my $2 contribution. Hope it was not spam for you. I really want to help. I can start a wiki page if you want? But I will not be able to maintain it. Disclaimer : I'm absolutely not an expert neither about kernel/OS development, software distribution/package management, cyber security or any technology of this topic. But, until recently I've tryed to develop a generic desktop secure OS that isolate every process into a sandbox (using a Linux kernel, tools like firejail/bubblewrap/minijail providing linux-namespace and secomp-bpf, and inspiration from OpenWall for least priviledge policy. I've a prototype runing and working well but really too hacky. I've stopped because of not enought time and resources. Genode is an obviously much better approach! Congrats :-) I cannot wait to see my workstation runing a port of Qubes/SubGraph on Genode+seL4... Best wishes and happy new year. Michael Bideau, from France.

1 0

IPC messaging
by Nobody III 29 Dec '17

29 Dec '17

Currently, Genode has session interfaces for various use cases, but I'm unsure of which one to use for simple "send-and-forget" scenarios. The "Terminal" interface seems to be the best option currently available, but seems a little misleading. Should I use "Terminal" sessions for send-and-forget IPC, or is there a better option?

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users