users January 2018

users@lists.genode.org

24 participants
27 discussions

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 04 Jan '18

04 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users January 2018