genode/doc/release_notes/15-11.txt

              ===============================================
              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:

! <theme>
!   <aura  top="8"  bottom="8" left="8" right="8"/>
!   <decor top="20" bottom="8" left="1" right="1"/>
!   <title xpos="16" ypos="9" width="32" height="20"/>
!   <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.