users January 2018

users@lists.genode.org

24 participants
27 discussions

Problem with running sel4 on Genode
by Subhadeep Sarkar 23 Jan '18

23 Jan '18

Hi, I am facing some trouble while launching Sel4 on top of Genode. I am trying to do it by the document at https://genode.org/documentation/articles/sel4_part_1 . When I run the command: sudo ./tool/ports/prepare_port sel4, I get the following error, which I am unable to bypass. subhadeep@...554...:~/Git/genode$ sudo ./tool/ports/prepare_port sel4 sel4 update src/kernel/sel4 sel4 apply /home/subhadeep/Git/genode/repos/base-sel4/patches/arm_cache.patch 1 out of 1 hunk FAILED -- saving rejects to file src/kernel/sel4/libsel4/arch_include/arm/sel4/arch/types.h.rej /home/subhadeep/Git/genode/tool/ports/mk/install.mk:129: recipe for target 'phony/patches//home/subhadeep/Git/genode/repos/base-sel4/patches/arm_cache.patch' failed make[2]: *** [phony/patches//home/subhadeep/Git/genode/repos/base-sel4/patches/arm_cache.patch] Error 1 /home/subhadeep/Git/genode/tool/ports/mk/prepare_single_port.mk:38: recipe for target '_install_in_port_dir' failed make[1]: *** [_install_in_port_dir] Error 2 tool/ports/prepare_port:33: recipe for target 'sel4' failed make: *** [sel4] Error 2 I would really appreciated any help with this, as I am unable to decode the error. Thank you for your help! Yours sincerely, Subhadeep ------------------------------------------------------------------------------------------- Subhadeep Sarkar, PhD Postdoctoral researcher, Univ Rennes, Inria, CNRS, IRISA Inria Rennes - Bretagne Atlantique Campus universitaire de Beaulieu 35042 Rennes cedex, France Website: subhadeep.cf E-mail: subhadeep.sarkar@...552... ; subhadeepsarkarybs@...54... Phone: +33 2 99 84 73 52

2 3

Re: Roadmap 2018
by unknown＠example.com 23 Jan '18

23 Jan '18

2 1

Genode region mapper
by Valery V. Sedletski 21 Jan '18

21 Jan '18

Hi, I'm now trying to port my L4Env-based program to Genode. It is a runtime environment to run OS/2 programs on a L4 family microkernel (Inspired by OS/2 Warp, PowerPC edition/IBM Workplace OS). Currently, the working version (actually, some proof-of-concept) is running under L4Env, but I plan to port it to Genode and L4Re (and maybe, to WinNT native/ReactOS in the future). For porting purposes, I need to have some region-mapper functionality, like 1) reserve a virtual memory region in the region map, so that it will avoid attaching dataspaces over this region, unless an explicit attachment address is specified; 2) lookup an address in the region mapper, i.e., determine, is this address free, reserved, or some dataspace is attached here, and if so, at which address/offset and which size. For implementing the memory management functions, this is needed to reserve a virtual memory block, for subsequent committing pages/attaching dataspaces in that region, step by step. As I looked at the Genode::Region_map interface, I don't see such functions in that class. Though, I found some memory-range allocation routines in the Genode::Range_allocator class, but I'm not sure if this is what I need. Is there some functionality related to reserving regions/looking up addresses implemented elsewhere, or I need to implement such functionality myself? Also, a required feature is multiple memory areas support in the region mapper. I need at least, two memory areas, a private one, and a shared one. A private area start at the beginning of the address space. It is private to any user-mode program. A shared area starts at some higher address, and it is common for all usermode programs (using my runtime environment). So, it is a global shared memory started at the same address, and each shared memory region is mapped at the same address in all client address spaces. It is used for shared memory IPC,Â as well as for loading DLL's. DLL's are shared between different usermode programs, unlike Windows DLL's or Unix SO's. So, I need to allocate memory ranges in specific (private or shared) areas. This could be implemented via my own memory manager with its own accounting. But maybe, there is an already implemented functionality, like this? L4Env region mapper has support for multiple memory areas, as well as a possibility to lookup an address, or to attach a pointer to a user-defined structure, to an address. So, I can attach my own data related to that address/region. Is there a functionality like this implemented in Genode? I also know, that there is a support for managed dataspaces, or nested region maps, which could be useful here (at least, for implementing a shared memory area), but I also know, that nested region maps are not supported on all platforms (like Genode/Linux). So, it would be, possibly, better to avoid using them, unless really needed. WBR, valery

2 6

Roadmap 2018
by Norman Feske 21 Jan '18

21 Jan '18

Hello everyone, like every year in December, I'd like to kick off the discussion of Genode's road map for the upcoming twelve months. It goes without saying that your feedback and suggestions are very welcome. Should you have any plans related to Genode, please do not hesitate to chime in! Before I present my rough plans, let me take a minute to review the past year. Review of 2017 -------------- As Johannes Schlatow's team put it so nicely in their Christmas card (thanks a lot!), the "Turmvilla" era lies behind us. So let the "Sculpt" era begin! Whereas Turmvilla allowed me to work on a Genode-based system since mid of 2015, the scenario was quite rigid and required significant manual labour for any customization. Although it was not really inviting for potential users, it illustrated well that all the basic building blocks - in particular the driver stacks - were in place. But it would have been be quite a stretch to call Turmvilla a general-purpose OS at that point. The new Sculpt scenario that I started to put together this autumn leverages two key features of 2017 to ultimately enter the realms of general-purpose computing. Those features are the dynamic init and the package management. The combination of Genode's recursive architecture with the dynamic reconfigurability of the init component allows me to interactive shape the running Genode system including any subsystem or even configurations of individual components. The system structure is at my fingertips and I can change it instantly using my favorite text editor. This excites me to no end! :-) At the same time, the new package management greatly helps to keep the complexity at a manageable level. Whereas I rarely updated my Turmvilla installation out of hesitance to break my work environment, I routinely update Sculpt on a weekly basis. Not only do I but also all my team mates at Genode Labs! The switch of the entire Genode-Labs team to Genode full time was certainly our biggest milestone of the year. At the technical level, the use of the gained cross-kernel binary compatibility or the VFS infrastructure have already become a second nature. Regarding the latter, remodelling this infrastructure to an asynchronous mode of operation was certainly a long and stony way. I am extremely grateful to Emery and Christian for having taken a big share of this labor-intensive work! Now, we can start to reap the fruits of this development. How to proceed in 2018? ----------------------- Personally, I'm to eager to take Genode in two main directions. First, the Sculpt scenario will for sure spawn manifold developments to the benefit of end users. Those developments will include documentation to make Sculpt palatable to users, the further cultivation of Genode's package-management concept, the composition of new subsystems, and the optimization of daily work flows. The progress in this direction will be quite organic and primarily motivated to make our daily computing experience more effective and fun. The second direction is the application of Genode for real-time graphics and sound processing - in a way reigniting my past passion of programming demo effects on the Atari Falcon. ;-) The path for this activity was paved this year by Josef and Sebastian who created our driver infrastructure for Intel GPUs. By actively using this infrastructure along with the audio stack, I am eager to push Genode towards low-latency multimedia performance. In order to do that, I will have to improve the tools for gathering runtime data (e.g., putting our tracing infrastructure to good use), gain a profound understanding of the behavior of complex scenarios, and optimize. Aside these playful activities, I also want to focus on the quality and resilience of our software. The modernized framework API introduced last year is an important stepping stone. But there is much more we can (and should) do, I.e., learning from the high-integrity computing community (e.g., implementing critical components in SPARK), leveling-up the scope and intensity of our automated tests, facilitating static code analysis, and employing software-hardening techniques. Of course, this scope goes far beyond the time frame of one year. The immediate priorization of these topics will largely depend on the focus of commerical users funding the work. The aspirations outlined above are my personal perspective. Please do not hesitate to share yours! Any comments and suggestions are appreciated. Maybe you even have tangible or less tangible Genode-related plans as well? I would be happy to learn about them! The outcome of the discussion will eventually become the official road map for 2018, which I am going to announce in mid of January. 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

8 21

FOSDEM 2018
by Norman Feske 16 Jan '18

16 Jan '18

Hello everyone, just in case you are not monitoring the news items at genode.org, let me make you aware of the upcoming FOSDEM (https://fosdem.org/2018/) held on 3rd and 4th of February. The microkernel developer room at FOSDEM is the melting pot of the open-source microkernel world where projects and users meet to present their work and experience with microkernel-based operating systems. Like every year, we will take the chance to present the recent achievements of Genode to the audience. There will be three presentations from our team, covering our recent work on hardware-accelerated graphics, user-level networking, and the dynamic sculpting of a Genode-based system. If you are curious about the topics, or interested in meeting the people behind the various projects, please do not hesitate to join us! The microkernel developer room will take place on Saturday in room AW1.126. The schedule for the Genode-related talks is as follows: 11:05 GPU resource multiplexing in component-based systems by Sebastian Sumpf 12:25 Live sculpting a Genode-based operating system by Norman Feske 17:30 User-level networking on Genode by Martin Stein For the complete schedule along with abstracts for the talks, please refer to: https://fosdem.org/2018/schedule/track/microkernels/ 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

blocking canceled in entrypoint constructor
by Johannes Kliemann 16 Jan '18

16 Jan '18

Hi all, When running Genode on Linux as PID 1 I get the warning `blocking canceled in entrypoint constructor`. This seems to happen only when running as init process. When I run the same configuration on Linux with the usual user land this doesn't happen. I have also applied the patch to [1] (I have tested this on 17.11 where it is applied anyway). Changing the underlying Linux kernel did not help. I could trace the issue to repos/base-linux/src/lib/base/ipc.cc:421 [2] where lx_recvmsg returns -EINTR. The proposed way to handle this error according to the GNU reference [3] is to retry the syscall. Yet Genode does not and throws an exception. Is there any signal that only the init process receives that isn't handled properly in Genode (sorry if this is slightly off-topic)? Why does Genode handle -EINTR with an exception and not the way proposed in the GNU manual? Regards, Johannes Kliemann [1]: https://github.com/genodelabs/genode/issues/2521 [2]: https://github.com/genodelabs/genode/blob/f44edd407bf674bfad11accad8319d5f6… [3]: https://www.gnu.org/software/libc/manual/html_node/Interrupted-Primitives.h…

2 2

Beginner : VMM with genode
by jony jony 15 Jan '18

15 Jan '18

I'm new at genode , i just booted genode 17.11 with a nova kernel based on the demo from the hard disk, i was wondering how can i run a seoul or xbox vmm on top of genode since genode only has the launchpad in the demo and i don't think i can do much with that. I want to be able to use genode freely as i would use any other machine . I guess that starts with creating a virtual machine on top of it , how can i install a VMM on top of it , thank you

2 1

Building genode 17.11 for Raspberry Pi
by Davide Pippa 10 Jan '18

10 Jan '18

Hello everybody! I'm trying to build demo scenario to test genode on raspberry pi (trying model 1 B+), but I'm facing some build problems. I'm a newbie in genode so maybe it's something silly, but here's what I've done: - download genode source code; - preparing some useful ports with: tool/ports/prepare_port dde_linux libc (looks like those have been correctly been downloaded) - create a build directory with: tool/create_builddir rpi - build some things (inside build/rpi directory) with: make (this correctly builds many things without error) - try building demo things (inside build/rpi directory) with: make run/demo here things suddently stop, because "target drivers/usb is missing"; from my understanding, this target should be provided by dde_linux port, isn't it? but inside dde_linux directory (contrib/dde_linux-6e4a3643875613612c2cc788938aadae5ce7ec7f/src/drivers) i only see the "framebuffer" sub-directory; also in repos/os/src/drivers I cannot see "usb" directory; Is there anything obviuos I'm missing? Sorry if my question is silly, I'm just trying to get started :) but I see things changed on the way (I read release notes from 13.11 on and some messages in mailing list and see things are in a flux) Thanks! Davide

2 2

Beginner question
by Stefan 09 Jan '18

09 Jan '18

Hi all, Iâm new to Genode and was trying to build the Hello World sample. I succeeded building the component (Genode book Genode foudations, 2.5.3) but when I try to define the system scenario (2.5.4) and to âmake run/helloâ Iâm getting the error: make run/hello #including /home/genodeuser/genode/repos/genode_lab_01/run/hello.run building targets: core init app/hello spawn make core init app/hello make[1]: Verzeichnis â/home/genodeuser/genode/build/x86_64â wird betreten Error: target 'core' does not exist Makefile:214: die Regel fÃ¼r Ziel âerror_missing_targetsâ scheiterte make[1]: *** [error_missing_targets] Fehler 1 make[1]: Verzeichnis â/home/genodeuser/genode/build/x86_64â wird verlassen Error: Genode build failed Makefile:312: die Regel fÃ¼r Ziel ârun/helloâ scheiterte make: *** [run/hello] Fehler 252 Please excuse the german output. The system seems not to be able to build the "core" component(target?). Any ideas? Thanks in advance! Stefan

2 1

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users January 2018