=============================================== Release notes for the Genode OS Framework 15.11 =============================================== Genode Labs In the [https://genode.org/documentation/release-notes/15.08 - previous release], we proudly reported the initial use of Genode as day-to-day OS. With the current release, we maintained the strong focus on making Genode viable as the foundation of a desktop OS. There are many aspects to be considered, ranging from configuration concepts, over the GUI and audio architectures, to device-driver support. Section [Genode as desktop OS] gives insights into this development and our train of thoughts. Speaking of device drivers, the current release comes with the Intel KMS driver ported from the Linux kernel and running as a user-level component. The driver allows us to drive multiple displays and change screen resolutions on the fly. Since the driver code relies on the Intel GEM infrastructure of the Linux kernel, we had to port those subsystems as well. So the new driver could be taken as starting point for a user-level GPU multiplexer in the future. In addition to those prominent features, the release comes with numerous improvements and additions. For example, we enhanced the support for the USB Armory (a dedicated article about this work will follow soon), added support for Xilinx Zynq-7000, and optimized our version of VirtualBox for NOVA. According to our [https://genode.org/about/road-map - road map], we planned to address package management, a modern web browser, and cross-kernel binary compatibility with the version 15.11. However, we decided to put emphasis on the general usability, robustness, and scalability first, before entering new developments. So those topics are not covered by the current release. That said, package management is a topic of ongoing active development within our community. Most of the file-system improvements featured in the current version were motivated by this line of work. Where do we stand with the use of Genode as desktop OS? Currently, there is a hand full of people using Genode as day-to-day OS. By eating our own dog food, we are able to recognize and remedy all the little issues that stand in our way. Hence, the user experience is steadily evolving. Still, at the current stage, it is not palatable for end users with no background in the development with Genode. For installing a Genode-based desktop OS, one has to compile and configure all components from source, there is no package management, there are no wizards that guide you, and there are no GUI dialogs for configuring the system. However, all the pieces for creating a system that is practically usable are [https://github.com/genodelabs/genode/issues/1552 - available], and putting them together is a lot of fun! Genode as desktop OS #################### The overall theme of the current release is the use of Genode as a desktop operating system. The state of development is best expressed by the screenshot of the Genode/NOVA-based setup used by Norman on his x201 Thinkpad. [image turmvilla_screenshot_small] Under the hood, the new Intel KMS driver (Section [Intel-KMS framebuffer driver]) drives the external '1920x1200' display in addition to the internal LCD display of the laptop. The wireless network has just been configured via the noux session located at the bottom left facilitating the configuration concept explained in Section [Uniform run-time configuration concept]. The windows are decorated with a new window decorator that supports drop shadows and translucent decorations. The decorator can be tweaked and even replaced at runtime. Uniform run-time configuration concept ====================================== For using Genode as a desktop OS, we had to find answers to a number of questions regarding the configuration of both long-living low-level components as well as high-level applications: * How to pass parameters to applications when they are started? Whereas the common approach of argc-argv-based command-line arguments is nice for the interactive use at a shell, it does not scale well: Structured information is hard to express and the syntax varies from application to application. * Where are configurations stored and how do applications obtain them? Traditionally, programs obtain their configuration data from well-known locations at the file system like the _/etc/_ directory or dot files in the home directory. On Genode, however, there is no common file system structure and the notion of a home directory does not even exist. Alternatively, configuration data could be stored at a central "registry" service. But such a database-like mechanism is less transparent to the user and creates a bunch of new problems with respect to management and access control. Furthermore, the impact of such a nontrivial central component on the system's trusted computing base cannot be neglected. * Is it possible to cover the configuration needs of low-level components like device drivers and file systems with the same mechanism as used by high-level applications? * How can the configuration of a long-living component be tweaked at runtime without the need to restart it? We attempted to answer these questions with a single mechanism in version [https://genode.org/documentation/release-notes/12.05#System_reconfiguration_at_runtime - 12.05]. But the scalability of the approach remained unproven until now. In short, configuration information is supplied to a component by its immediate parent component in the form of a ROM session with the name "config". A ROM session represents a piece of data (ROM module) that can be made visible in the component's address space. Furthermore, the ROM session allows the component to register a signal handler that is notified should a new version of the ROM module become available. The component can - at its discretion - respond to such a signal by requesting the new version. Consequently, a ROM session is a way to transfer information from the ROM server to the ROM client in a transactional manner. When used as configuration mechanism, the server is the parent and the client is the child component. From the child's perspective, it is irrelevant where the information comes from. The parent could have read it from a file system, or obtained it from another ROM service, or could have generated it. By convention, configuration data has an XML-like syntax, which allows us to express arbitrarily structured information. [image backdrop_edit_config] The figure above illustrates an example scenario. The backdrop component obtains a description of the background composition as its "config" ROM module. The init component routes this ROM-session request to the FS-ROM server, which provides a ROM service by reading the content of ROM modules from a file system. The same file system can, of course, also be accessed by other clients. At the right side, a noux instance executes an editor like Vim to edit files in the file system. Each time, the file is saved by the editor, FS-ROM gets notified, which, in turn, notifies the backdrop to update its configuration. This way, a desktop background can be interactively changed using Vim. With the current release, we have incorporated the ability to dynamically respond to configuration changes into many components to make them ready for the use in a desktop environment. To illustrate the flexibility of the mechanism, we can perform the following operations by merely editing text files as explained in the backdrop example above. * Letting our new Intel KMS driver (Section [Intel-KMS framebuffer driver]) change screen resolutions or enable/disable connectors. * Changing the volume of audio channels per application or the master volume. * Changing the colors, style, and the placement of window controls of the window system. * Changing the policy of the nitpicker GUI server such as the tinting of screen regions depending on the labels of the visible applications. * Connecting to a wireless network by editing the configuration of the Intel wireless driver. * Replacing an entire subsystem by a new one by replacing the configuration of a nested instance of the init component. * Assigning a USB device to a subsystem by editing the USB driver's configuration. All these use cases are covered by the same mechanism. Because configurations have a textual form with a uniform syntax (XML), the approach implicitly gives us the following benefits: * Configurations can be annotated with comments, managed via a revision-control system like Git, and compared to older versions via diff tools. * Because the mechanism is based on a textual representation, accessibility of all configuration-related operations is built-in into Genode by default. * The response of components to configuration changes can be subjected to automated tests, which merely need to present varying ROM modules to components (as done by the _dynamic_rom_ server). Combined with the report-session facility that allows components to report state to its parent, the configuration concept makes the creation of graphical front ends a straight forward experience. For example, a hypothetical display-settings dialog would obtain the framebuffer driver's report about the available connectors and supported resolutions, present a dialog of options, and, in turn, generate new configurations for the framebuffer driver. If a new display gets connected, the driver would update its report, triggering the dialog to present the new options. Section [Audio stack] presents a similar scenario for mixing audio. GUI stack ========= Since the first release in 2008, Genode is equipped with a GUI server called nitpicker, which plays the role of a secure "hypervisor for graphics". With less than 2000 lines of code, it multiplexes the framebuffer and routes input events in a secure way. Its low complexity stems from the fact that it does contain almost no policy. In particular, it has no notion of "windows" or similar common GUI elements. These parts of the GUI must be implemented at the client side. In [https://genode.org/documentation/release-notes/14.08#New_GUI_architecture - version 14.08], we laid the foundation for a scalable GUI architecture that further reduced the functional scope of nitpicker and complements nitpicker with higher-level components for managing windows. Thanks to this architecture, most of nitpicker's formerly built-in policies such as the pointer shape could be moved to separate components that are easy to replace and customize. We were ultimately able to incorporate the notion of windows into the architecture without introducing a new interface. Instead, the window manager implements the same interface as the nitpicker GUI server. Applications are unaware whether they talk to nitpicker or the window manager. [image nitpicker_wm] Both nitpicker and the window manager provide the same (nitpicker session) interface. With the current release, we push this architecture even further. By eliminating the notion of the X-ray mode from nitpicker as explained in Section [Rigid separation of policy and mechanism], we further reduce nitpicker's responsibilities and greatly improve its flexibility. We managed to completely decouple the components for painting window decorations and managing window layouts from the window manager to the point where we can dynamically replace those components at runtime. Furthermore, we introduce a new window decorator (Section [Enhanced window-decorator and window-layouter flexibility]) that can be styled in a very easy way. Rigid separation of policy and mechanism ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nitpicker's X-ray mode is a distinctive feature of the GUI server. It allows the user to reveal the identity of applications by pushing a special button at any time. The following picture shows the effect. In contrast to the original version of nitpicker, the new GUI stack allows the window decorator to properly respond to X-ray mode changes. Whereas nitpicker is responsible for tinting the window content and painting the client's labels as a watermark, the window decorator applies the color change to the window decorations. [image decorator_xray] Normal (left) and X-ray mode (right). While X-ray mode is enabled, the user is able to validate the authenticity of the presented applications and thereby uncover Trojan Horses. Nitpicker actually does no longer have an X-ray mode. Instead, the individual features of the former X-ray mode can be configured for specific client labels. Those features are input-focus policy, the tinting with a session color, the labeling, and the hovering policy. Behind the scenes, nitpicker is reconfigured each time the X-ray mode is enabled or disabled. The following diagram shows the scenario: [image nitpicker_xray_trigger] Interplay of the nitpicker GUI server with externalized policy components. The X-ray trigger component is a nitpicker client that receives certain global key sequences according to nitpicker's configuration. It is thereby able to exclusively respond to the X-ray key. Furthermore, it is able to incorporate any number of other conditions to decide whether to enable or disable the X-ray mode. For example, by making nitpicker's hover reports available to the X-ray trigger, X-ray could be automatically enabled while the pointer hovers over a panel or the window decorations. The X-ray trigger, in turn, reports its decision via an "xray" report. This report is routed as input to the ROM filter. The ROM filter responds by generating a new configuration for nitpicker. In addition to the flexibility of making X-ray trigger policy and the actual X-ray effect easily customizable, the new approach allows other components outside of nitpicker to respond to the X-ray mode, most particularly the window decorator. Loose coupling of policy components ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Genode's window manager is not a single program but a composition of several components with different responsibilities: [image window_manager] The window manager merely acts as a low-complexity mediator of potentially complex and policy-rich components like the window decorator and the window layouter. Both the decorator and the layouter are mere clients of the window manager. Window-related information is exchanged between these components via the report-ROM component, which provides a publisher-subscriber mechanism by implementing Genode's report and ROM session interfaces. Because state information is always kept at the report-ROM server outside the decorator and the layouter, it is possible to replace those components at runtime without losing any information about the state of the present windows. The following screenshot shows how the classical window decorator gets replaced by the new themed window decorator introduced in the next section. [image switching_decorators] Enhanced window-decorator and window-layouter flexibility ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Handling of window controls* We added support for the common window controls _close_ and _maximize_ to the window layouter and decorator. The order of those controls in the window title can be configured, and can even be changed at runtime. When activating the window closer, the window manager sends a resize request for the size 0x0 to the corresponding client. It is up to the client to implement a meaningful response such as exiting the application. *Tinting of window controls* Thanks to the separation of the X-ray policy from nitpicker as explained in Section [Rigid separation of policy and mechanism], components other than nitpicker have become able to respond to the X-ray mode. This is particularly useful for the window decorator, which can now take the X-ray mode into account for tinting window decorations according to the session colors. We enhanced the existing window decorator by a configurable assignment of colors for different windows depending on the window labels. Similar to nitpicker, the decorator is able to respond to configuration updates at runtime. Even though the decorator has no notion of an X-ray mode, it can respond to the X-ray mode when combined with a ROM filter, analogously to the configuration depicted for nitpicker in Figure [nitpicker_xray_trigger]. *New themed decorator* We created a second decorator to illustrate the versatility of the GUI architecture, and to give users a modern-looking alternative to the original Motif-inspired decorator. The new themed decorator is located at _gems/src/app/themed_decorator/_. In contrast to the original decorator that has a built-in style, the new decorator obtains the style information from a few PNG images, a font, and a bit of metadata. Those files need to be mounted into the VFS of the decorator at the _/theme/_ directory. The following Figure [theme] shows the three images _default.png_, _closer.png_, and _maximizer.png_ of the default theme. [image theme] The corresponding _metadata_ has the following content: ! ! ! ! ! <closer xpos="36" ypos="10"/> ! <maximizer xpos="10" ypos="10"/> ! </theme> The '<aura>' node contains the margins for the area around the decorations, which gives us room for drop shadows. The '<decor>' node contains the margins of the actual decorations. The '<title>', '<closer>', and '<maximizer>' nodes contain the positions of the corresponding window controls with the coordinates referring to the coordinates in the _default.png_ image. Audio stack =========== While working on the audio stack and improving the support for audio applications in VirtualBox, we took the chance to modernize the mixer component and applied Genode's dynamic configuration concept to the mixer. Like all other configurable components, the mixer obtains its configuration via a ROM module from its parent. The following configuration snippet illustrates its structure: ! <config> ! <default out_volume="75" volume="25" muted="0"/> ! <channel_list> ! <channel type="input" label="client" number="0" volume="75" muted="1"/> ! <channel type="input" label="client" number="1" volume="15" muted="1"/> ! <channel type="output" label="master" number="0" volume="100" muted="0"/> ! <channel type="output" label="master" number="1" volume="100" muted="0"/> ! </channel_list> ! </config> The '<default>' node is used to set up the initial settings for new clients. According to this configuration, every new client will start with a volume level set to 25 and is not muted. The initial output volume level is set to 75 (the volume level ranges from 0 to 100). The '<channel_list>' node contains all (pre-)configured channels. Each '<channel>' node has several mandatory attributes: * 'type' is either 'input' or 'output', * 'label' contains the label of a client for an input node and the value 'master' for an output node, * 'number' specifies the channel number (0 for left and 1 for right), * 'volume' sets the volume level, * 'muted' marks the channel as muted. In addition, there are optional read-only channel attributes, which are mainly used by the channel-list report. The mixer reports all available channels in its 'channel_list' report. The report contains a `<channel_list>' node that is similar to the one used in the mixer configuration: ! <channel_list> ! <channel type="input" label="client0" name="left" number="0" active="1" volume="100" muted="0"/> ! <channel type="input" label="client0" name="right" number="1" active="1" volume="100" muted="0"/> ! <channel type="input" label="client1" name="left" number="0" active="0" volume="25" muted="0"/> ! <channel type="input" label="client1" name="right" number="1" active="0" volume="25" muted="0"/> ! <channel type="output" label="master" name="left" number="0" active="1" volume="100" muted="0"/> ! <channel type="output" label="master" name="right" number="1" active="1" volume="100" muted="0"/> ! </channel_list> Each channel node features all mandatory attributes as well as a few optional ones. The 'name' attribute contains the name of the channel. It is the alphanumeric description of the numeric 'number' attribute. The 'active' attribute indicates whether a channel is currently playing or not. A channel-list report may be used to create a new configuration for the mixer. Each time the available channels change, e.g., when a new client appears, a new report is generated by the mixer. This report can then be used to configure the volume level of the new client. A new report is also generated after a new configuration has been applied to the mixer. Thereby, a mixer agent becomes able to adapt itself to recent changes. As an example, there is an experimental mixer agent based on Qt5 _repos/gems/src/app/mixer_gui_qt_ that processes the mixer generated channel-list reports. It takes the report and writes a new configuration to the file 'mixer.config' that can then be used by the mixer. A basic scenario that uses the mixer as well as the experimental mixer agent looks like this: [image mixer_agent] Interplay of the graphical mixer front end (mixer agent) with the audio mixer. This scenario is available in the form of the run script at _gems/run/mixer_gui_qt_test.run_. In addition to the mixer and mixer agent, it features a few more components. We therefore also discuss their roles here. The mixer component receives its configuration from the _FS-ROM_ component and reports a list of its channels to the report-ROM component. The mixer agent accesses the channel-list report as ROM module provided by the report-ROM component. It writes the configuration to the file _/config/mixer.config_, which is stored by the _config-file-system_ component. The FS-ROM component exports each file as ROM module. One of those modules is the _mixer.config_ that is, in turn, presented as configuration to the mixer component. Each time the _mixer.config_ file is altered, the mixer receives a signal, reloads the new version of the configuration, and adapts itself accordingly. In return, the mixer sends a new report every time its channel list changes. This report is consumed by the mixer agent to adjust itself, i.e., to display or remove a client widget. All this mechanics is hidden behind a simple GUI dialog. By moving a slider, the user generates a new mixer configuration. Copy and paste ============== When using Genode as a desktop OS, users need to be able to copy and paste text between different subsystems such as guest OSes running in VirtualBox and Qt5 applications running directly on Genode. This integration feature requires two ingredients. First, the respective subsystems need to interface their internal clipboard mechanisms (like the clipboard of the guest OS) with the Genode world. Second, we need a clipboard component that manages the information flows between the subsystems. *Import/export of clipboard data of subsystems* From the subsystem's perspective, Genode's clipboard protocol looks as follows: * A subsystem propagates new clipboard content to the Genode world via a report session with the label "clipboard". Each time its internal clipboard content changes, it issues a report with the new content. * For importing clipboard content from the Genode world, the subsystem opens a ROM session with the label "clipboard" and registers a signal handler for ROM-changed signals. Upon the reception of such a signal, the subsystem requests the updated ROM content and forwards it to its internal clipboard. The session labels for the ROM and report sessions are merely a convention that should be followed to enable the session routing in a uniform way. A clipboard report has the following format: ! <clipboard> ! ... UFT8-encoded and XML-sanitized text ... ! </clipboard> *Clipboard component* The clipboard component is similar to the existing report-ROM server in that it provides both a report service and a ROM service. In contrast to the report-ROM server, however, all report sessions refer to the same (clipboard) report. Reports by different clients override each other. Each time the report changes, all ROM clients are notified, which can respond to the notification by requesting the updated version of their clipboard ROM module. *Security considerations* Given the principle design, the clipboard component could be used to let information flow between arbitrary clients. However, in multi-level scenarios, we need to constrain the flow of information between different domains. For example, we want to prevent a crypto domain from leaking credentials to a domain that is connected to the network. To express an information-flow policy, the clipboard component has the notion of "domains", which correspond to the domains already present in the nitpicker GUI server. Clipboard clients are associated with domains via the clipboard configuration: ! <config> ! ... ! <policy label="vbox_linux" domain="hobby"/> ! <policy label="vbox_win7" domain="work/> ! <policy label="noux" domain="admin"/> ! ... ! </config> By default, a clipboard report is propagated solely to clients of the same domain as the originator. All other clients will receive an empty clipboard ROM module (this enables those subsystems to clear their local clipboard selection). To propagate clipboard data across domains, a white list of information-flow policies must be defined as follows: ! <config> ! ... ! <flow from="work" to="admin"/> ! <flow from="hobby" to="admin"/> ! <flow from="hobby" to="work"/> ! ... ! </config> This example defines a policy where data can flow from the work and hobby domains to the admin domain but not in the other direction. Furthermore, data copied in the hobby domain can be pasted in the work domain but not vice versa. Even though the transport of the actual clipboard content can be subjected to the stated information-flow policy, two conspiring clipboard clients can still misuse the clipboard to establish a covert channel: Because each time a report is generated, a clipboard ROM update is propagated to all clients (some receive the actual content whereas some receive an empty clipboard), two presumably isolated clients can use those notifications to send bits of information. For this reason, we need to limit the bandwidth of those notifications. The biggest problem is that the clipboard reports are generated by the (untrusted) subsystem software, which can issue reports at an arbitrary rate. Ideally, we wish to let the user give its consent for each generated clipboard report. But this would interfere with the work flow universally expected by users. The clipboard component addresses the problem by dynamically incorporating status information of the nitpicker GUI server into the information-flow policy: * The clipboard server accepts reports only when they originate from the domain that is focused by nitpicker. Nitpicker already provides "focus" reports that contain this information. Conveniently, the focus reports already contain the name of the focused domain (in addition to the client's session label). With the correspondence of the clipboard's domains to nitpicker's domains, the clipboard is able to take nitpicker's focus reports into account for the information-flow policy. * To further limit the rate of artificial clipboard reports, the clipboard component accepts reports only from a domain where a corresponding nitpicker client received user input recently. The term "recently" refers to a reasonable upper bound of the time needed by a guest OS or an application to respond to Control-C or a similar key sequence, i.e., 500 milliseconds. This way, a subsystem can submit new clipboard content only shortly after the user interacted with the subsystem, which is always the case when the user triggers the copy operation. To accommodate this mechanism, nitpicker's focus reports had to be slightly enhanced by a new attribute "active" that is set to "yes" if the user interacted with the domain recently. As another measure to limit the bandwidth of the covert channel, the clipboard server notifies its ROM clients only if their ROM module actually changed. This way, not each report from an unrelated domain results in a ROM-changed signal but only the one that invalidated the formerly visible clipboard content. So the active help of the user is required to transfer bits of information. *Clipboard supporting subsystems* With the current release, the clipboard protocol has been implemented into Qt5 applications and VirtualBox. On VirtualBox, we leverage the shared clipboard mechanism provided by the VirtualBox guest additions. Graceful exiting of subsystems ============================== In dynamic scenarios like desktop computing, subsystems should be able to gracefully exit. For applications manually started via a panel or a shell-like command interface (CLI monitor), the user expects the system to free the application's resources after the exit of the application. Originally most of Genode's runtime environments used to respond to the exit of a child by merely printing a message to the log. It was up to the user to manually regain the resources by explicitly killing the subsystem afterwards. To make the CLI monitor and the graphical launcher more pleasant to use, we enhanced them to perform the kill operation automatically once a child exits gracefully. In many cases, subsystems are assembled out of several components using a nested instance of init. E.g., such subsystems are a composition of protocol stacks like nit_fb, terminal, ram_fs in addition to the actual application. The lifetime of such a composed subsystem mostly depends on one of those components (e.g., the noux runtime or VirtualBox VMM). To enable the CLI monitor (or the launcher) to automatically respond to an exiting noux instance, we need to propagate the exit of the noux component through the intermediate init runtime to the CLI monitor. To do that, we extended the configuration concept of init with an additional sub node for the '<start>' node: ! <start name="noux"> ! <exit propagate="yes"/> ! ... ! </start> If the propagate attribute is set to yes, the exit of the respective child will result in the exit of the entire init component, including all siblings of the exited component. The approach gives us the freedom to define even multiple children that may trigger the exit condition of init (by specifying an '<exit>' node at several '<start>' nodes. Base framework and low-level OS infrastructure ############################################## Changes at the system-integration level ======================================= Label-dependent session routing ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Access-control policies in Genode systems are based on session labels. When a server receives a new session request, the session label is passed along with the request. A session label is a string that is assembled by the components that are involved with routing the session request from the client along the branches of the component tree to the server. The client may specify the least significant part of the label by itself. This part gives the parent a hint for routing the request. For example, a client may create two file-system sessions, one labeled with "home" and one labeled with "bin". The parent may take this information into account and route the individual requests to different file-system servers. The label is successively superseded (prefixed) by additional parts along the chain of components on the route of the session request. The first part of the label is the most significant part as it is imposed by the component in the intermediate proximity of the server. The last part is the least trusted part of the label because it originated from the client. Once the session request arrives at the server, the server takes the session label as the key to select a server-side policy. Whereas the use of session labels for selecting server-side policies has been a common practice for a long time, label-dependent session routing was rarely needed. In most cases, routing decisions were simply based on the type of the requested sessions. However, as Genode's system scenarios get more sophisticated, label-dependent routing becomes increasingly important. As we wished to express the criterion of routing decisions and the server-side policy selection in a uniform way, we introduced the following common label-matching rules. Both a '<service>' node in init's routing configuration as well as a '<policy>' node in the server's configuration can be equipped with the following attributes to match session labels: :'label="<string>"': The session label must perfectly match the specified string. :'label_prefix="<string>"': The first part of the label must match the specified string. :'label_suffix="<string>"': The last part of the label must match the specified string. If no attributes are present, the route/policy matches. The attributes can be combined. If any of the specified attributes mismatch, the route/policy is neglected. If multiple '<service>' nodes match in init's routing configuration, the first matching rule is taken. So the order of the nodes is important. If multiple '<policy>' nodes match at the server side, the most specific policy is selected. Exact matches are considered as most specific, prefixes as less specific, and suffixes as least specific. If multiple prefixes or suffixes match, the longest is considered as the most specific. *Note* This change requires slight adaptations of existing configurations because the semantics of the original 'label' attribute of server-side policy nodes has changed. Originally, the attribute value was taken as a prefix for matching the session label. Now, the attribute would be taken as a perfect match. The adaptation of existing configurations is as simple as replacing "label" by "label_prefix". Since the change tightens the semantics of the label attribute, it will not weaken the security of existing policies. In the worst case, a server will reject sessions that formerly passed the label checks, but not vice versa. New VFS server component ~~~~~~~~~~~~~~~~~~~~~~~~ Genode has traditionally featured a number of file system servers, each designed for a specific storage back end. The implementation of new servers and features came with the additional effort of maintaining consistent code and behavior between server varieties. The VFS server is a solution to this redundancy. By building a server around the VFS library, new storage back ends need to implement the VFS plugin interface only. This unification is not without runtime benefit, as it leads the way to more discretion in component composition. The server allows clients to share the burden of plug-ins that come with a large consumption of resources, but this potentially reduces privacy and can act as covert communication medium. From another perspective, clients may host plug-ins to reduce context switches between the file system and raw storage, or the VFS server may host high complexity plug-ins to maintain low complexity in a security sensitive address space. For the time being, the VFS server should be considered a resource multiplexer without strong client isolation. The following two configurations contrast the traditional ram_fs with the VFS server. ! <start name="ram_fs"> ! <config> ! <content> ! <dir name="data"> ! <tar name="data.tar"/> ! </dir> ! <dir name="tmp"/> ! </content> ! ... ! </config> ! ... ! </start> ! <start name="vfs"> ! <config> ! <vfs> ! <dir name="data"> ! <tar name="data.tar"/> ! </dir> ! <dir name="tmp"> <ram/> </dir> ! <ram/> ! </vfs> ! ... ! </config> ! ... ! </start> New VFS-local symlink file system ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A goal of the VFS library is to provide declarative file system composition. This release adds a symlink built-in to the library, which allows the configuration to populate file systems with symlinks. ! <vfs> ! ... ! <dir name="usr"> ! <tar name="bash.tar"/> ! </dir> ! <dir name="bin"> ! <symlink name="sh" target="/usr/bin/bash"/> ! </dir> ! ... ! </vfs> New server for aggregating LOG data to file-system storage ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The fs_log component has been refactored to better express the source of logging streams as well as to operate at lower complexity. For each client session, the session label is converted to a directory tree with the trailing element being the file, to which log messages are written. Logs may also be merged using session-policy selectors with a label prefix. See _os/src/server/fs_log/README_ for details. New ROM logger component ~~~~~~~~~~~~~~~~~~~~~~~~ The new ROM logger component located at _os/src/app/rom_logger/_ is a simple utility to monitor the content of a ROM module. It is meant to be used for test automation and during debugging. Each time, the monitored ROM module changes, the ROM logger prints its content to the LOG. New ROM filter component ~~~~~~~~~~~~~~~~~~~~~~~~ The new ROM filter component located at _os/src/server/rom_filter/_ provides a ROM module that depends on the content of other ROM modules. Its designated use is the dynamic switching between configuration variants dependent on the state of the system. For example, the configuration of the window decorator may be toggled depending on whether nitpicker's X-ray mode is active or not. *Configuration* The configuration consists of two parts. The first part is the declaration of input values that are taken into account. The input values are obtained from ROM modules that contain XML-formatted data. Each input value is represented by an '<input>' node with a unique 'name' attribute. The 'rom' attribute specifies the ROM module to take the input from. If not specified, the value of 'name' is used as the ROM name. The type of the top-level XML node can be specified via the 'node' attribute. If not present, the top-level XML node is expected to correspond to the 'name' attribute. The second part of the configuration defines the output via an '<output>' node. The type of the top-level XML node must be specified via the 'node' attribute. The '<output>' node can contain the following sub nodes: :'<inline>': Contains content to be written to the output. :'<if>': Produces output depending on a condition (see below). If the condition is satisfied, the '<then>' sub node is evaluated. Otherwise, the '<else>' sub node is evaluated. Each of those sub nodes can contain the same nodes as the '<output>' node. *Conditions* The '<has_value>' condition compares an input value (specified as 'input' attribute) with a predefined value (specified as 'value' attribute). The condition is satisfied if both values are equal. *Example* For an example that illustrates the use of the component, please refer to the _os/run/rom_filter.run_ script. Source-code reorganization ========================== By broadening the diversity of hardware and kernels that Genode supports, the file structure of some subdirectories of the source tree became increasingly confusing. Although our build system already provides a mechanism - the so called _spec values_ - to choose between different aspects like kernels or devices, source codes depending on certain spec values were not always easily recognizable as such. Moreover, some of the spec values used the prefix "platform", or were grouped in "platform" subdirectories, others did not use that term. Thereby, the semantics of "platform" became more and more blurry over the years, describing either a board, processor architecture, SoC, or kernel-hardware amalgam. To achieve a consistent view on all aspects, whose compilation is dependent on spec values, code has been moved into _spec/_ subdirectories instead of holding them inline within the repository structure. At each directory level of the source tree, a _spec/_ directory can be found when different aspects make this necessary, for example: ! repos/base/include/spec/ ! repos/base/mk/spec/ ! repos/base/lib/mk/spec/ ! repos/base/src/core/spec/ ! ... Automatically added _include_ paths of sub-repositories, which are dependent on spec values and which formerly resided in _repos/*/include/platform/_, were moved to _repos/*/spec/_. Library descriptions that depend on spec values now reside in _repos/*/lib/mk/spec/_. The "platform" names mainly vanished from the source tree. It is strongly recommended to clean-up older build directories completely before compiling the new release because of the significant changes of the directory structure. API-level changes ================= String and XML-handling utilities ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *String parsing* The new overloads of the 'ascii_to' function for 'bool' and 'uint64_t' allow the easy extraction of such values from XML nodes and session-argument strings. *XML node-content sanitizing* The introduction of the clipboard component called for a way to embed and extract data (like clipboard content) from untrusted sources into an XML node without breaking the XML structure. The embedding of such data is accommodated by the new 'append_sanitized' method of the 'Xml_generator'. For the extraction of such data from XML nodes, we added corresponding accessor methods ('decoded_content') to the 'Xml_node'. *Generalized session-label and session-policy utilities* The utilities provided by _os/session_policy.h_ used to be tailored for the matching of session arguments against a server-side policy configuration. However, the policy-matching part is useful in other situations, too. Hence, we removed the tight coupling with the session-argument parsing (via 'Arg_string') and the hard-wired use of 'Genode::config()'. To make the utilities more versatile, the 'Session_label' has become a 'Genode::String' (at the time when we originally introduced the 'Session_label', there was no 'Genode::String'). The parsing of session arguments is performed by the constructor of this special 'String'. The constructor of 'Session_policy' now takes a 'Genode::String' as argument. So it can be used with the 'Session_label' but also with other 'String' types. Furthermore, the implicit use of 'Genode::config()' can be overridden by explicitly specifying the compound XML node as an argument. The common problem of scoring XML nodes against a given label, label prefix, and label suffix as explained in Section [Label-dependent session routing] is addressed by the new 'Xml_node_label_score' utility. It is used by the init component to take routing decisions and by servers to select policies dependent on session labels. VFS and file-system API ~~~~~~~~~~~~~~~~~~~~~~~ The file system APIs received a few simple amendments. New error codes were added to broaden error handling, and session arguments were added to the file-system service. File-system session requests now carry a _writeable_ and _root_ argument. The latter enables clients to request a root offset when connecting to the service that is appended to the root policy of the server. The _writeable_ argument gives the client a way to express its intention to never write. If _writeable_ is set to true, the ability to perform write operations can still be overridden by a server-side policy. Object-pool redesign ~~~~~~~~~~~~~~~~~~~~ The object pool is one of the eldest abstractions in Genode. It is in particular used for thread-safe RPC-object lookup. However, with the increasing number of requirements over the years, its API and semantics became difficult to understand. Moreover, the synchronization primitives had to be handled by the user of the interface appropriately. So it was possible to access an object without holding its lock. We observed some corner cases where the object pool's insufficiencies led to inconsistencies within the RPC server framework. Therefore, we decided to rework the object pool's API and implementation. Now, instead of returning pointers to objects via a look-up function, one has to provide a functor that should be applied to the object of interest. In general, the object's locking primitives are transparent to the developer and are only used within the object pool's implementation internally. The look-up function looks as follows: ! template <typename FUNC> auto apply(Untyped_capability cap, FUNC func) The functor that is provided must have one argument, which is a pointer to the expected object's type. The object pool implementation will search for the object with the designated capability and will dynamically cast it to the type given by the functor. If the object could not be found, or if the cast fails, the functor gets called with a null-pointer as argument. Thereby, the user is able to handle mismatches explicitly. Caution has still to be taken when destroying objects. Deleting an object during a look-up leads to a deadlock situation. As the object pool will unlock an object again after applying the functor to it, the object must not be deleted in the scope of the functor. Users of the object pool should use the 'apply' function to remove an object from the pool instead, and afterwards delete it. To raise the convenience here, we will possibly enrich the object pool's API in one of the upcoming releases by appropriated factory/deletion methods so that the entire object's lifetime is handled safely via the object pool. Handling sub-page resources in 'Attached_io_mem_dataspace' ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On some hardware platforms, memory-mapped registers of different devices happen to be co-located at the same physical memory page. Since memory-mapped I/O resource can be handed out to drivers at the granularity of 4K pages only, drivers had to deal with sub-page register offsets as special cases. To remove this burden from the driver developers, the 'Attached_io_mem_dataspace' has been changed to accept physical addresses at byte granularity and hands out the corresponding virtual addresses including the sub-page offset transparently for the driver. Libraries, applications, and runtime environments ################################################# Qt5 improvements ================ We enhanced our version of Qt5 with the support for *key repeat* and the ability to use the new *clipboard* mechanism presented in Section [Copy and paste]. Clipboard support must be explicitly enabled by setting the attribute 'clipboard' in the application's '<config>' to "yes". VirtualBox ========== *Improved support for large guest-memory allocations* We changed the allocation of guest VM memory from a few large contiguous memory dataspaces to more and smaller dataspaces. The change enables us to start VMs even if there is no contiguous memory chunk available for a VM. *VM shutdown detection* Additionally, we implemented the detection of VM shutdowns. If the VM finally powers off, our Virtualbox virtual-machine monitor (VMM) notifies its parent via the exit operation of the parent interface. The parent may respond to such a signal, e.g., by destructing the entire VMM subsystem including the virtual machine. *Clipboard support* In order to exchange clipboard data of a guest OS with Genode, we enabled the VirtualBox guest-addition support to receive and transfer clipboard data. Depending on the configured clipboard mode in the _.vbox_ file of the VM, clipboard data may get exchanged - bidirectional, host-to-guest only, or guest-to-host only. In the bidirectional and host-to-guest cases, a dataspace with the name "clipboard" will be requested and evaluated each time the content changes. In the bidirectional and guest-to-host cases, the VMM acts as Genode ROM reporter. *Omitting the overhead of rdtsc emulation* While debugging load problems within VirtualBox, we observed that a running Windows 8 guest VM did generate a lot of VM exits by using the 'rdtsc' instruction at a high rate. Since this instruction traps into the VMM, it can impose a huge load in the VMM that - amongst other - severely influences audio playback/recording (e.g., distorted sounds and the like). As an interim solution, we have disabled the virtualization of the 'rdtsc' instruction completely. This works well as long as each guest VM runs on its own CPU core. However, when sharing one CPU by multiple VMs, time-stamp-counter (TSC) warping occurs. Building a more robust solution regarding TSC warping and drifting requires further evaluations, which we will conduct in the future. *Safe VM shutdown when closing the framebuffer window* When using VirtualBox with the window manager, clicking the window-close button initiates an ACPI shutdown of the VM, which allows the guest operating system to quit safely. *64-bit guest operating system support* VirtualBox can now run 64-bit guest operating systems. For Windows guests, only one guest CPU is supported at the moment. Seoul VMM ========= In the context of using Genode as a desktop OS, we extended our Seoul VMM port to be able to start lightweight VMs for specific use-cases, such as web-browsing, more easily. One step into this direction was to enable, extend, and stress test the AHCI and IDE disk-device models of Seoul. Based on our improvements, we were able to come up with a user-friendly reproducible work-flow to setup customized Tinycore VMs. Device drivers ############## Intel-KMS framebuffer driver ============================ With the current release, we proudly present a port of the Intel i915 driver from Linux kernel 3.14.5 to Genode. We successfully tested it on machines containing Intel GPUs from generation five up to generation eight. With the port of the Intel driver to Genode, we followed the approach that we already used to enable the USB stack on Genode described in [https://genode.org/documentation/release-notes/12.05#Re-approaching_the_Linux_device-driver_environment - release 12.05], to enable the Linux TCP/IP stack in [https://genode.org/documentation/release-notes/13.11#Gigabit_networking_using_the_Linux_TCP_IP_stack - release 13.11], and more recently to enable the Intel wireless stack in [https://genode.org/documentation/release-notes/14.11#Intel_wireless_stack - release 14.11]. The driver can be configured dynamically at run-time via the config ROM-mechanism. Each connector of the graphics card can be configured separately using the following syntax: ! <config> ! <connector name="LVDS-11" width="1280" height="800" enabled="true"/> ! </config> The driver adapts to every change of its configuration immediately. Thereby users can enable or disable display devices, or change their resolution by simply editing the configuration file of the driver at run time. Moreover, to alleviate tearing effects, the driver supports buffering. That means, instead of providing the framebuffer memory directly to the client, it exports a simple RAM dataspace to the client and copies over changes from it to the actual framebuffer memory during dedicated refresh operations. This behavior can be enabled within the driver's configuration as follows: ! <config buffered="yes"/> The driver distributes all available connectors of the graphics card and their supported resolutions via a report that looks as follows: ! <connectors> ! <connector name="LVDS-11" connected="1"> ! <mode width="1280" height="800" hz="60"/> ! ... ! </connector> ! ... ! </connectors> To generate such reports, the driver configuration needs to contain a corresponding '<report>' node: ! <config> ! <report connectors="yes"/> ! </config> Framebuffer support for Exynos 4 ================================ The existing framebuffer driver for the Samsung Exynos 5 SoC has been generalized to also cover the Exynos 4 SoC, specifically the ODROID-x2 platform. Thanks to Alexy Gallardo Segura for this contribution. AHCI support for ATA devices w/o native command queuing ======================================================= Up to now Genode's AHCI driver supported hard disks that offered the native command queuing feature (NCQ) only. While NCQ vastly improves the performance of a hard disk, some drives simply do not support this feature. Therefore, we extended the AHCI driver and enabled NCQ detection during device initialization. If a device does not support NCQ, the driver programs the controller accordingly during block requests. Intel wireless stack ==================== As an artefact from our initial porting effort, the WLAN driver used a device white list because it would scan the PCI bus in a suboptimal way. To reduce the time it takes to iterate over all possible matches in the driver's ID table, we reduced the list to only those few devices we explicitly wished to support. With this release we finally addressed this issue and got rid of the device white list. The driver is now expected to work on a broader range of machines out of the box. We also refined the driver with respect to the way it searches for networks. Prior to the change it was not possible to connect to a network with a hidden SSID. ACPI driver improvements ======================== During the development of the Intel framebuffer driver, we encountered several DMA remapping faults caused by the IOMMU (Intel terminology: DMA remapping units). It turned out that the faults happened in a region, which the Intel GPU uses. Those regions get reported via an ACPI structure called "Reserved Memory Region Reporting Structure" (RMRR), which is defined by the documentation "Intel ® Virtualization Technology for Directed I/O Architecture Specification" in the chapter "BIOS Considerations". For PCI devices, the RMRR regions report information about physical ranges, which the device implicitly uses for DMA operations to work flawlessly. An operating system using the IOMMU feature must therefore take precautions to make such RMRR regions accessible for DMA operations of a specific PCI device. Our ACPI driver already detected such RMRR regions and printed the information. Until now, however, we had no need to actually make use of it. We extended our ACPI driver to propagate the RMRR region information via Genode's Report-ROM mechanism. The platform driver as the consumer of the report got extended to store the RMRR region information until a device driver for a specific PCI device gets started. As soon as the device driver gets assigned to the PCI device via the platform driver, the RMRR regions are added to the device PD of the driver. This enables the device to operate on the RMRR regions with DMA operations. SD-card driver for i.MX53 ========================= In the context of our work on the USB Armory, we improved the robustness of our SD-card driver for the i.MX53 eSDHC. The new version has become able to deal with bogus transfer state information on multi-block writes, and copes well with the weak memory-ordering of ADMA-table accesses. Additionally, the driver was re-factored. A more detailed explanation and the background story are provided in Section [Improved TrustZone support on USB Armory]. Network driver for Zynq-7000 platform ===================================== Thanks to the contribution of Johannes Schlatow and Timo Wischer (TU Braunschweig, Germany), Genode has received support for the network controller on the Xilinx Zynq-7000 platform. With a Qemu version greater or equal than 2.3, you can test this feature via: ! make run/lwip Platforms ######### Execution on bare hardware (base-hw) ==================================== Xilinx Zynq-7000 ~~~~~~~~~~~~~~~~ The increasing interest in the combination of Genode and the Xilinx Zynq-7000 board motivated us to add official support to our custom kernel. The platform features a Cortex-A9 CPU. Thus, our existing kernel drivers for the Cortex-A9 private peripherals, namely the core-local timer and the ARM Generic Interrupt Controller, could be reused. The steps to enable the new platform included the creation of a new UART driver (UARTPS), the generalization of the PL310 L2-cache-controller driver, and the addition of board-specific declarations. Furthermore, support for the user-land timer driver was implemented using the Triple Timer Counter (TTC) on Zynq platforms. Although the board even supports SMP and a Xilinx FPGA, we don't make use of these features yet. However, the port is intended to serve as a starting point for further development in these directions. To create a build directory for Genode running on Xilinx Zynq-7000, use the following command: ! ./tool/create_builddir hw_zynq Thanks to Johannes Schlatow, Timo Wischer, and Mark Albers (TU Braunschweig, Germany) who contributed their work on Xilinx Zynq-7000! Physical memory detection on the 64-bit x86 architecture ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The x86 version of our custom kernel has been enhanced to evaluate the multiboot structure of the boot loader to detect all available physical memory. The core-physical allocator gets populated with this information enabling Genode to use all available memory instead of a preconfigured amount. Improved TrustZone support on USB Armory ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ With Genode 15.02, we introduced basic support for the USB Armory through our custom kernel in the _base-hw_ repository. Alongside this, we also announced the support for the TrustZone VMM demo - a scenario that demonstrates a guest OS being monitored by a Genode hypervisor leveraging the protection mechanism of ARM TrustZone. The guest OS was a Linux 3.18 with a BusyBox RAM disk. This setting was sufficient to showcase the physical separation of software but it lacks the full feature set of the native Linux setup delivered with the board and promoted in the [https://github.com/inversepath/usbarmory/wiki - online documentation]. Most significant was the missing USB support and CDC Ethernet that enable the USB Armory to communicate via TCP/IP with its host. With this line of work, we have the goal to reach feature parity with the original USB Armory setup while putting Linux ("normal" world) under the supervision of Genode ("secure" world). We will explain those developments in a separate article. The current state of the tz_vmm scenario provides the following features: * A fully-featured USB-Armory Linux as TrustZone-encapsulated guest OS requiring only slight source-code modifications, * A light-weight Genode as TrustZone monitor, * Protection of the eSDHC and UART against direct access by the guest OS, * Selective export of SD-card partitions into the guest OS using a para-virtualized block driver while the other partitions remain trusted, * A para-virtualized serial driver in the guest OS to capture its log output and distinguishably incorporate it into the UART output of the monitor, * Bringing the scenario to your own USB Armory by using a fully documented and widely automated reproducible process, * And switching the on-board LED from within the monitor in order to signal trusted/untrusted code execution. But there are still open issues that can be taken as motivation for further development: * The GPIO and clock controls are accessible by both the monitor and the guest. The guest OS cooperates by making no changes to the settings that would affect the monitor functionality. As a solution to this, guest access to the GPIO control should be para-virtualized. Please note, that one aspect of this is that the on-board LED is currently not trusted. Another consequence is the current lack of power management as the guest doesn't disable clocks in favour of Genode, and Genode, on the other hand, lacks support. * The Genode driver for the USB-Armory eSDHC currently does not aim for maximum performance. The bus width and frequency are set statically to low values, aiming for broad support rather than getting the best out of each SD card. * The on-board LED is currently switched on and off by the so-called TZ-VMM, a user-land component of the Genode system. For a more comprehensive indication of trusted execution, it would have to be controlled from within the Genode kernel. You can build the demo by executing ! ./tool/create_build_dir hw_usb_armory ! cd build/hw_usb_armory ! make run/tz_vmm A tutorial on how to create a bootable SD card can be found in the corresponding run script _os/tz_vmm.run_. A tutorial on how to reproduce the pre-built Linux image, Rootfs and DTB - used by the run script - can be found at [https://genode.org/files/release-15.11/usb_armory_tz_vmm/README]. NOVA ==== With the release 15.08, we [https://genode.org/documentation/release-notes/15.08#NOVA_kernel-resource_management - extended the kernel] to handle memory quota per Genode component. The line of work for the current release built upon those new mechanisms and simplifies the memory management within Genode's core component. In the original version of NOVA, all the memory used by user-level components had to be present in core's protection domain. This was needed to allow core to revoke the memory mappings from the components, e.g., when a dataspace is destructed or detached from the address space of a component. When revoking memory mappings core had to present evidence authorizing it to revoke those mappings to the kernel. Hence, the core-local mappings served as some kind of authorization token. Core would actually not use the core-local mappings except for the rare case of clearing a dataspace. Still, even though core was not expected to access the mapped memory that belongs to non-core components, it could still accidentally do so. For example, a dangling-pointer bug within core could read or overwrite memory in non-core components. The *remote revoke* extension of the kernel that we introduced in the previous release paved the ground to eventually remove core-local mappings for non-core memory. In the new version, core installs memory mappings directly into the user-level components. To revoke mappings, core specifies the PD selector of the targeted component and a component-virtual address range to the remote revoke operation of the kernel. This practice, which we also employ on our custom base-hw kernel, improves the fail-security of the system. In the unexpected case that something goes wrong within core (which should never happen, but still could), information between components can no longer accidentally cross address-space boundaries. Tools and build system ====================== Run-tool support for booting via the iPXE boot loader ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [https://ipxe.org - iPXE] is an open source network boot firmware, which supports booting from a web server [https://ipxe.org/howto/chainloading#breaking_the_loop_with_an_embedded_script - via HTTP]. With the new load module at _tool/run/load/ipxe_, Genode's run tool has become able to load images via iPXE/HTTP to the test hardware. The following two parameters can be used to specify the iPXE/HTTP setup: :--load-ipxe-base-dir: This parameter specifies the base directory of the HTTP server, from which the target machine downloads the files. :--load-ipxe-boot-dir: The directory which contains the iPXE chainload configuration and all necessary files given relative to the iPXE base directory. The target machine is expected to request the following iPXE configuration via HTTP: ! http://${HOST_URL}/${ipxe-boot-dir}/boot.cfg This can be achieved by building iPXE with the following embedded script: ! #!ipxe ! dhcp ! chain http://${HOST_URL}/${ipxe-boot-dir}/boot.cfg In addition to loading an image, an iPXE boot configuration is required to boot the loaded image on the target machine. The run-tool back ends for NOVA, Fiasco.OC, and L4/Fiasco have been enhanced to automatically generate such configurations, which use the [https://ipxe.org/cmd/sanboot - sanboot command] to download and boot an ISO image via HTTP. To use this boot method, your RUN_OPT configuration must specify both the ISO-image and the iPXE-load modules: ! RUN_OPT += --include image/iso --include load/ipxe Note that the webserver serving the ISO image must support [https://forum.ipxe.org/showthread.php?tid=7295&pid=10482#pid10482 - ranged requests]. Thanks to Adrian-Ken Rueegsegger for these improvements! Tool for creating U-Boot images for Genode's supported platforms ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ With the support for the Wandboard Quad in base-hw and the implied integration of such a board into our testing arsenal, we felt once more motivated to provide an easy way to reproduce the boot loader images we use for the different ARM platforms. The new _tool/create_uboot_ tool is the result of our first investigation into this direction. Called without a parameter, it offers a short documentation on how to use it. Apart from that, the only parameter is the targeted platform: ! ./tool/create_uboot <PLATFORM> The platforms are named similar to the _tool/create_builddir_ tool. Currently, the platforms _hw_usb_armory_ and _hw_wand_quad_ are supported by create_uboot but further platforms shall be enabled in the future. The output of the tool can be copied to the SD card via tools like 'dd' using an offset of 1024 bytes to save the partition table if existent: ! sudo dd if=<IMAGE> of=/dev/<YOUR_MMC> bs=1K seek=1 conv=fsync Removal of deprecated features ############################## The development of the *Codezero* kernel came to a halt several years ago, its supported hardware platforms are outdated, and there is no active community of users. We still kept the platform on life by the means of nightly build tests and sporadic runtime tests. However, because each non-trivial change of kernel-dependent code required us to spend energy on the kernel to no apparent benefit, we finally dropped it. We originally introduced the so-called *lx_hybrid* base platform to ease the building of Genode completely with the Linux host tools and linked to the host libc. With this feature, we tried to accommodate the use of Genode as component middleware on top of regular Linux distributions. For quite some time, however, this feature remained unused. So we removed the lx_hybrid special case and the corresponding 'always_hybrid' spec value.