Release notes for the Genode OS Framework 18.05

The driver behind the release 18.05 is the rapid evolution of the Sculpt general-purpose OS. Following the initial version from February, which was targeted at early adopters, the new Sculpt for The Curious (TC) introduces a much more welcoming and empowering user experience (Section Sculpt for The Curious).

It goes without saying that the interactive and dynamic nature of the Sculpt scenario puts a lot more pressure on Genode's components compared to static workloads. For example, Sculpt calls for the dynamic adjustment of user-level network routing, the dynamic detection and management of partitions and file systems, the support of USB storage devices from diverse vendors, and a way to adapt the visual appearance to a great variety of screen resolutions. Most improvements described below are our responses to these challenges.

That said, the release is not short of new features either. E.g., it features the initial port of OpenJDK's HotSpot VM for executing Java programs on Genode directly (Section Java language support), improves the support for the NXP i.MX family of SoCs (Section NXP i.MX SoC), and enhances the VFS with new plugins for copy-on-write and the auditing of file accesses (Section New VFS plugins).

The release is complemented by the annual update of the Genode Foundations book (PDF), which covers the fundamentals of the framework in great detail (Section New revision of the Genode Foundations book).

Sculpt for The Curious New revision of the Genode Foundations book Storage infrastructure   VFS library and plugin interface   New VFS plugins   Improved disk-partition discovery and access   Creating and modifying GUID partition tables User-level networking   NIC router   NIC dump GUI stack   UTF-8 support and improved text rendering   Terminal enhancements   Text rendering   Font-format support   Modernized API for input-event processing   Improved keyboard-focus handling Device drivers   NVMe storage devices   NXP i.MX SoC   Improved USB-storage driver Libraries and applications   Packaged Qt5 framework   Java language support   Ada language support   Seoul VMM on NOVA   Ported software Platforms   Accessing PCI via ECAM/MMCONF   Kernel-agnostic platform-information handling   Updated seL4 kernel to version 9.0.1   Updated Muen separation kernel Build system and tools   Validating 3rd-party code downloads via SHA256   Creating GPT-based disk images by default

Sculpt for The Curious

With Sculpt for The Curious (TC), Genode 18.05 features the second revision of the Sculpt general-purpose OS. Compared to the initial version for Early Adopters (EA), it features a new interactive system-management component that streamlines common tasks like the management of storage devices, or configuring the network connectivity. The highlights of the new version of the base system image are:

• Live-customization of almost all aspects of the system,

• The ability to install and run software in memory only,

• Hotplugging of USB storage devices,

• New support for NVMe storage devices in addition to SATA disks,

• Interactive network configuration including Wifi connectivity,

• Interactive management and inspection of storage devices and partitions,

• The option to host a complete and customized Sculpt installation on a USB stick,

• Automated on-demand installation of software packages with visual feedback,

• Scalable fonts that are automatically adjusted to the screen resolution, and

• UEFI boot supported by default.

The base image is extensible by downloadable software packages that may originate from different sources, safeguarded by cryptographic signatures. It contains several example subsystems as a starting point:

• Basic GUI components like a window manager, a scalable backdrop, a font server, and a simple software-rendering demo,

• A light-weight noux runtime for executing command-line-based software such as GNU coreutils, bash, and vim.

• A package for downloading the installer and a suitable virtual-machine configuration for Debian Linux,

• VirtualBox running Debian Linux,

• An example for running libretro-based games,

• A disposable VM that runs Firefox on TinyCore Linux, executed either in VirtualBox or the light-weight Seoul virtual-machine monitor,

• A Qt5-based text editor.

Please refer to the updated Sculpt documentation to explore Sculpt TC.

The Sculpt version included with the current release requires the user to build a boot image by hand. Following the steps described in the documentation, this procedure takes a few minutes. We plan to provide downloadable boot images a few weeks down the road once Sculpt TC received intensive day-to-day testing by the early adopters. Your feedback is very welcome!

New revision of the Genode Foundations book

The "Genode Foundations" book received its annual revision, which reflects the evolution of the framework over the past year. Specifically, the changes since the last year's edition are:

• Changed boot-loader infrastructure on PC hardware

• Package management

• Structural changes of Genode's custom base-hw kernel

• API improvements: Unicode handling, support for XML-based data models, timeout-handling API

To examine the changes in detail, please refer to the book's revision history.

Storage infrastructure

VFS library and plugin interface

The VFS (Virtual-File-System) library was expanded to meet new requirements for the Sculpt scenario. The traditional file-system medium for component state and configuration sculpting is the ram_fs server, but with the limitation that files stored in the server are ephemeral. Any changes to the initial state are lost when a system is shut down or the ram_fs server is restarted. Now that persistent storage is usually served by a VFS plugin hosted by the VFS server, it was a natural progression to introduce a means for indicating VFS changes with File_system session notifications. To this end the VFS server was amended to send session notifications, and notification support was added to the Rump and FatFs VFS plugins, allowing Ext2 and FAT file-systems to host dynamic component state and configuration information.

Using the VFS for serving font data produced from files stored in the VFS made it practical to allow VFS plugins to introspect the file system. Plugins now have the means to access arbitrary paths from the file-system root or they may host and expose their own internal file systems.

While the core of the VFS library is small compared to contemporaries in other operating systems, the moment came to promote the VFS from a static to a shared library. Components that use the C runtime have always loaded the VFS dynamically as a subsystem of libc.lib.so, but native components carried the bulk of its implementation. The VFS library is now provided as a shared library and is included with the front-end server in the src/vfs depot archive. This change affects components that have been rebuilt against the shared library but do not have their ROM policies updated to allow access to the vfs.lib.so ROM.

New VFS plugins

File-system introspection has made two additional plugins possible, the audit and cow plugins.

The audit plugin logs VFS paths as they are accessed to a dedicated LOG session. This is useful for finding the files required by third-party components without relying on documentation or auditing source code.

The cow plugin emulates copy-on-write behavior by copying the contents of files lying in a read-only path to a read-write path as they are opened. This plugin is considered a proof-of-concept and under-performing, but opens a way of experimenting with seeding user-managed file-systems from immutable file-system archives.

Plugins of this kind are most appropriately instantiated in the VFS server with policies to restrict the intended components into paths provided by the plugins. This prevents a component from escaping the effect of the plugin. An example of "auditing" a libc component follows:

 <start name="audit_fs">
   <binary name="vfs"/>
   <config>
     <vfs>
       <dir name="data"> <!-- source files -->
         <tar "data.tar"/>
         <ram/>
       </dir>
       <dir name="audit"> <!-- virtual path that captures /data -->
         <audit path="/data"/>
       </dir>
     </vfs>
     <!-- route into virtual audit path -->
     <policy label_suffix="audit" root="/audit" writeable="yes"/>
   </config>
 </start>

 <start name="app">
   <config>
     <libc stdout="/log" stderr="/log"/>
     <vfs>
       <log/>
       <fs label="audit"/>
     </vfs>
   </config>
 </start>

Improved disk-partition discovery and access

The part_blk component, which parses the partition table on a block device and provides access to each partition through a block session, was extended to make it easier to implement a management component on top of it. It now features additional attributes in its report. For one the block size of each partition as well as the type of the file system on the partition are reported. The file system probing implementation is minimal and only contains file systems that are commonly used on Genode systems, i.e., FAT32 and Ext2. Furthermore, on GPT formatted disks, each partition has an expandable attribute that contains the number of blocks by which the partition can be grown. The following exemplary report illustrates the adjustments:

<partitions type="gpt" total_blocks="500118192" gpt_total="500118125" gpt_used="302254080">
  <partition number="1" name="BIOS boot partition"
   type="21686148-6449-6e6f-744e-656564454649" guid="db0701aa-02ae-474d-92d0-82738bfce5d2"
   start="2048" length="2048" block_size="512"/>
  <partition number="2" name="EFI System"
   type="c12a7328-f81f-11d2-ba4b-00a0c93ec93b" guid="74e43226-2afb-4575-bdda-83bf72f5a6e7"
   start="4096" length="262144" block_size="512" file_system="FAT32"/>
  <partition number="3" name="GENODE"
   type="0fc63daf-8483-4772-8e79-3d69d8477de4" guid="a950091d-87ba-4800-85bf-7b6a58abe6d5"
   start="235147264" length="67108864" block_size="512" file_system="Ext2"
   expandable="197862064"/>
</partitions>

The heuristics of how the component probes the partition table were also loosened. Instead of explicitly enabling support for GPT, the component will now always try to parse the MBR as well as the GPT. It will bail out if both are considered valid since using GPT/MBR hybrid tables is not supported and it should be up to the user to make an educated decision. In cases where there is no partition table, a partitions report of type="disk" will be generated in which the complete disk is presented as partition number 0. This is needed as compatibility fallback for Sculpt EA installations.

Creating and modifying GUID partition tables

Part of the enhancements of Sculpt TC is the ability to manipulate the block device used by Sculpt. We implemented a component called gpt_write, which can create and modify a GPT and its entries. It considers alignment constraints to make better use of 512e devices. It will, however, not perform any boundary checking. It does not handle overlapping partitions and only when applying a partition, it makes sure that the partition will fit. The following configuration illustrates its operation:

<start name="gpt_write">
  <resource name="RAM" quantum="2M"/>
  <config verbose="yes" initialize="yes" align="4K">
    <actions>
      <add entry="1" type="BIOS"  label="GRUB BIOS"  start="2048"  size="1M"/>
      <add entry="2" type="EFI"   label="EFI System" start="4096"  size="16M"/>
      <add entry="3" type="Linux" label="GENODE"     start="36864" size="128M"/>
      <add           type="BDP"   label="FAT32 Data" size="max"/>
      <delete entry="1"/>
      <delete label="FAT32 Data"/>
      <modify label="GENODE" new_label="GENODE*" new_size="max"/>
    </actions>
  </config>
</start>

Please read repos/gems/src/app/gpt_write/README for more detailed information on how to use the component and feel free to check out the run script repos/gems/run/gpt_write.run.

User-level networking

NIC router

The NIC router has received major improvements that were mainly motivated by our daily experience with the Sculpt scenario where the router serves as NAPT component in front of the virtual machines that host our work OS's. In this role, it is subject to a permanent load driven by real-world tasks. Furthermore, it has to have a user interface that makes it a pleasant experience to deploy in a dynamic environment. This led to our primary goal: We had to overcome the need to restart the NIC router, and thereby all components that depend on it, whenever its configuration changes and while doing so, not to interrupt the communication of its client unnecessarily.

We managed to make the NIC router fully re-configurable at runtime in a way that it always tries to keep as much state information as possible throughout the process. This means that network communication going through the NIC router is not affected by a configuration update unless the configuration change affects parts that were involved in an existing communication channel.

One prerequisite for this feature was that NIC session clients can connect at any time to the NIC router regardless of whether there is a matching domain for the session or not. As long as a session has no domain, the NIC router does not send any packet to it and drops all packets coming from it. But, at least, the session and the corresponding client component stay alive, even if their already assigned domain disappears with a new configuration.

At the uplink, in contrast, the lifetime of the session remains bound to the lifetime of the domain. The uplink domain-tag received a new attribute named label (only considered at the domain-tag of the uplink). It denotes the label of the uplink session. With these two particularities of the uplink domain, one can now easily switch between different NIC session servers. The NIC router will close and request the corresponding NIC session with the current label value if the domain node is removed/added or the label changes. Thereby, the NIC router can now be used to dynamically switch between network interfaces like wireless and wired adapters.

Furthermore, we improved the NIC router's ability to handle DNS server information. Domains can wait for the DNS server info of the DHCP client of another domain. This is done with the new attribute dns_server_from in the <dhcp_server> tag. Each time the DNS server info of the remote domain changes, the DHCP server with the dns_server_from attribute will toggle the link state of each session at its domain. This can be used by clients as a hint to request their DHCP info anew from the NIC router and thereby receive the updated DNS server information.

When it comes to protocols, the most notable change is that the NIC router now also supports routing and NAPT for ICMP. With the new <icmp> sub node of the <domain> tag, ICMP routes to other domains can be created. Instead of ports, the ICMP IDs are used for NAPT. Similar to the udp-ports and tcp-ports attributes, the size of the ID space for each NAPT client is configured via the new icmp-ids attribute in the <nat> tag.

Last but not least, the following small features were also added to the NIC router:

For more information, have a look at the os/src/server/nic_router/README file. Examples can be found in the run scripts dde_linux/run/nic_router_uplinks.run, libports/run/nic_router_dyn_config.run, and os/run/ping_nic_router.run.

NIC dump

The output level of the NIC dump component can now be configured per protocol by using the protocol names as attributes: eth, arp, ipv4, dhcp, udp, icmp, and tcp.

The available debug levels are:

Additionally, you can set a default debug level for protocols that are not configured using the default attribute.

For more information, please refer to os/src/server/nic_dump/README.

GUI stack

With Sculpt becoming more and more end-user oriented, Genode's GUI stack came into focus. It was time to reconsider several interim solutions that worked well in the past but would not scale up to a modern general-purpose OS. Two concrete examples are the support of scalable fonts and Unicode characters. In the past, Genode used to restrict textual output to the Latin-1 character set and employed pixel-based fonts only. The current release overcomes these limitations by featuring completely new text-output facilities.

UTF-8 support and improved text rendering

The UTF-8 text encoding overcomes the severely limited code-point range of the ASCII and Latin-1 character sets by representing characters by a varying number of bytes. Today, UTF-8 is generally considered as the standard encoding for text. The new UTF-8 decoder at os/util/utf8.h clears the path for Genode's native GUI components to follow suit. The first beneficiary is Genode's graphical terminal, which has become able to display Unicode characters and pass user input as UTF-8-encoded data to its terminal-session client.

Terminal enhancements

Speaking of the graphical terminal, the current incarnation got a welcome overhaul. First, we reduced its complexity by removing obsolete features like built-in keyboard-layout handling, which are no longer needed when combining the terminal with our modern input-filter component. Furthermore, the terminal has become dynamically resizeable, forwarding screen-size changes to the terminal client. Should the client be a Noux runtime, such a change is reflected to the running application as a SIG_WINCH signal. The application - e.g., Vim - responds to the signal by requesting the new terminal size. Finally, the terminal protocol was changed from linux escape sequences to screen escape sequences in the anticipation of making the terminal more flexible in the future.

Text rendering

Throughout Genode, many GUI components reused the text-output utilities of the nitpicker GUI server. These utilities, however, relied on a simple pixel font format. To make the text output more flexible, nitpicker's text painter located at nitpicker_gfx/text_painter.h has been replaced by a completely new implementation that decouples the font format from the glyph rendering and takes UTF-8 strings as input. In the process, the glyph rendering got a lot more sophisticated, supporting horizontal sub-pixel positioning and filtering.

Font-format support

To remove the omnipresent use of fixed-size pixel fonts throughout Genode, the following new components entered the picture:

First, the new ttf_font library implements nitpicker's font interface by using the TrueType renderer of the STB single-header library.

Second, the new vfs_ttf VFS plugin uses the ttf_font library to export a rendered TrueType font as a virtual file system. The various font properties as well as the actual glyph images become accessible as regular files. This way, an application that needs to draw text can read the glyph data directly from its VFS instead of depending on a font-rendering library.

Third, the new Vfs_font utility located at gems/include/gems/vfs_font.h implements nitpicker's font interface by obtaining the glyphs from the component-local VFS. It is complemented by the Cached_font utility, which implements an LRU glyph cache.

With this infrastructure in place, several existing GUI components could be updated, most prominently the graphical terminal and the menu-view widget-rendering engine. By facilitating the VFS as interface for propagating glyph data, components no longer need to manage fonts and their configuration individually. They just access their VFS. When integrating the component into a scenario, one can decide whether to mount a font-rendering library directly at the component, or - alternatively - route a file-system session to a central font server. The latter is just a regular VFS server with the fonts mounted as pseudo file systems. Since the glyph renderer is a VFS plugin, it could be replaced by another implementation in the future without touching any component.

Modernized API for input-event processing

Genode's input-session interface changed very little over the years. Even though it received evolutionary enhancements from time to time, its design resembled a traditional C-style interface from the medieval era. We found that the interface left too much room for interpretation. In particular, the meta data per event type was defined in a rather ad-hoc way, which raised uncertainties. For example, is a button-press event accompanied with a positional value or not? To remove these uncertainties, the current release replaces the Input::Event, with a new implementation that facilitates a safe way of accessing event meta data. Besides this design change, there is one noteworthy semantic change as well. With the new interface, symbolic character information are provided along with their corresponding press events rather than as distinct events, which - according to our practical findings - greatly simplifies the consumer side of the Input::Event interface.

Improved keyboard-focus handling

The nitpicker GUI server multiplexes one screen among multiple GUI clients in a secure way. One aspect remained underdeveloped so far, which is the keyboard focus handling. Nitpicker's Session:focus call previously triggered a one-off focus change at call time. This focus change did not pass the same code paths as a focus change triggered by a "focus" ROM update, which led to inconsistencies.

The new version changes the implementation of Session::focus such that the relationship of the caller and the focused session is preserved beyond the call time. Whenever the calling session is focused in the future, the specified session will receive the focus instead. So Session::focus no longer represents a single operation but propagates the information about the inter-session relationship. This information is taken into account whenever the focus is evaluated regardless of how the change is triggered. This makes the focus handling in scenarios like the window manager more robust.

Device drivers

NVMe storage devices

Since NVMe devices have become common in contemporary systems, it is time to provide a driver for such devices on Genode. With this release, we introduce a component that is able to drive consumer-grade NVMe storage devices, i.e., there is no support for namespace management or other enterprise-grade features. For now, to keep things simple, the driver uses the device in an old-fashioned way and uses only one I/O queue with at most 128 entries. That is to say it does not exploit the parallelism necessary to unlock the full potential of NVMe storage. Nonetheless, it performs well. The following snippet illustrates its configuration:

<start name="nvme_drv">
  <resource name="ram" quantum="8M"/>
  <provides><service name="Block"/></provides>
  <config>
    <report namespace="yes"/>
    <policy label_prefix="client1" writeable="yes"/>
  </config>
</start>

The component will generate a report, which contains all active namespaces, if reporting is enabled by setting the namespace attribute of the <report> node to yes. A report may look like the following example:

<controller model="QEMU NVMe Ctrl" serial="FNRD">
 <namespace id="1" block_count="32768" block_size="512"/>
</controller>

For an example on how to integrate this component, please have a look at the repos/os/run/nvme.run script.

While implementing the NVMe driver, a new component for testing block-sessions was used. In contrast to the already existing blk_bench and blk_cli components, it features a variety of different test patterns, which can be selected in its configuration and can be used to test a block component more thoroughly. For more information please refer to repos/os/src/app/block_tester/README

NXP i.MX SoC

We extended the Linux kernel driver port for Ethernet cards found in NXP i.MX SoC, which was introduced in the previous release. Now does it not only support i.MX6Q SoC based boards like the Wandboard, but the i.MX53 and i.MX6SX SoC as well. The new driver was successfully tested with the i.MX53 Quick Start Board and the Nitrogen6 SOLOX. The latter board even contains two Ethernet cards. But due to technical limitations of the board design, the same driver instance has to be used for both cards. Currently, the driver is tweaked to run on different boards via its configuration ROM. When no configuration is provided, it appropriates the values for successfully executing on the Wandboard. The following is an example configuration for the i.MX53:

 <config>
   <card name="fec0" type="fsl,imx25-fec" mii="rmii" irq="87" mmio="0x63fec000"/>
 </config>

As a side effect of enabling networking on the Nitrogen6 SOLOX, support for GPIO based signals has been added to the framework too. The existing GPIO driver for i.MX53 SoC got extended to additionally support the i.MX6 family.

There are some known limitations when using different drivers like Ethernet and SD-card drivers on the Wandboard right now. At the moment, those drivers adjust clock parameters and I/O pin configurations independently from each other, which can lead to inconsistencies. We plan to address those issues with the implementation of a platform driver for the i.MX6 SoC family.

Improved USB-storage driver

We improved the stability of the USB-storage driver (usb_block_drv) and made it compatible with a lot more devices as the driver has become a pivotal ingredient of the Sculpt scenario. Due to the changes, the way the driver operates has changed. On the one hand, now it first tries to use 10-byte Command Descriptor Blocks (CDB) in its SCSI layer and will only switch to 16-byte CDBs when it encounters a device whose blocks cannot be completely accessed via the former descriptor size. On the other hand, because some tested devices stopped working after issuing a USB device reset, the reset was made optional. By setting the reset_device attribute in the <config> node to yes, the driver is instructed to perform the USB device reset.

Libraries and applications

Packaged Qt5 framework

We created package recipes for all previously ported Qt5 libraries and their dependencies and adapted the run scripts accordingly. Please note that the host tools needed for building Qt applications (moc, rcc, uic) are not built automatically anymore, but need to be built and installed manually with the new tool/tool_chain_qt5 script.

Java language support

Over the course of the past year, we started to look into Java support for Genode with the ultimate goal of porting an existing Java Virtual Machine (JVM), which translates and executes Java byte code, to Genode. After investigating possible JVM candidates, it became obvious that OpenJDK is the only viable option when looking for a functional, maintained, feature complete, and open-source Java SDK. Therefore, we decided upon OpenJDK version 9 and started to port OpenJDK's HotSpot virtual machine.

In the first step, we followed the approach to enable HotSpot's internal Just-in Time (JIT) compiler, which translates byte code into machine code and is the option with the most to offer performance wise. But we also wanted support for ARM platforms and soon realized, there was almost no JIT compiler support for ARM other than for Linux. The Linux version is deeply integrated into the Linux system libraries (e.g., glibc), which makes it very hard to bring the compiler onto Genode. For example, Genode uses FreeBSD's libc and that would now have to offer glibc semantics.

After additional research, we found the so-called interpreter version of the HotSpot VM. This version does not compile byte code, but interprets and emulates the code at runtime. It is of course slower than the JIT compiler version, but also machine-architecture independent, so the same HotSpot VM can be compiled for x86 and ARM platforms. With the JVM running on Genode, we added networking and file-system access support via Genode's VFS layer. Note, there is no graphical toolkit support as of now, but most standard library classes should work. Also, the byte code has to be compiled on a different host system (e.g., Linux, *BSD) as of now, since we did not bring the Java compiler to Genode.

To give Java a spin, a run script can be found under ports/run/java.run.

Ada language support

Support for components and libraries written in the Ada/SPARK programming language experienced a rework with the final goal of seamless integration with the base framework. We added a new ada library, which contains a (currently minimal) runtime taken from the sources of our GCC port and thus is always consistent with the tool chain in use. It is built as a shared library ada.lib.so that needs to be added to the list of boot modules.

The example in libports/src/test/ada showcases the implementation of an Ada component using a custom library test-ada, which is also implemented in Ada.

Seoul VMM on NOVA

The Seoul/Vancouver VMM - introduced to Genode with release 11.11 - received some renovations to be able to run recent Linux VMs. Namely the output of the guest during early boot is now visible and the network models got revised. Additionally, the Seoul VMM has been packaged and can be used in Sculpt.

Ported software

The Stubby DNS daemon has been ported to begin experimentations with DNS as a native service. There is a tendency for DNS configuration frameworks to diverge between operating systems and releases, an inconvenience that is magnified when maintaining virtual machines. Name-server configuration via DHCP has been the only constant, so hosting DNS natively and configuring virtual-machines with the nic_router DHCP server presents itself as a viable solution to the guest resolver quagmire. Expect DNS services in later Sculpt releases.

Platforms

Accessing PCI via ECAM/MMCONF

The platform driver on x86 is trusted with guarding access to PCI devices. Up to now, I/O ports have been used to configure the PCI subsystem.

On modern x86 architectures, PCI devices can be configured by using Memory Mapped I/O (MMIO). This method was introduced with PCI Express and is called Enhanced Configuration Access Mechanism (ECAM). For Each PCI device a separate 4 KiB MMIO page exists to serves as the configuration interface between OS and PCI device.

The exact location of all the 4K MMIO pages of the PCI devices is machine specific and must be determined during the bootstrap phase. The ACPI driver on Genode is in charge of this procedure and reports the location of the ECAM/MMCONF region to the platform driver via the acpi ROM.

Besides using a modern PCI interface, switching to ECAM/MMCON served to ease the execution of Genode/hw on top of the Muen separation kernel.

Kernel-agnostic platform-information handling

Up to now, special kernel-specific information was propagated to components such as Virtualbox, the Seoul VMM, and the timer by reusing the kernel-provided data structures. For Genode/NOVA, the hypervisor info page (HIP) was exported as an ordinary Genode ROM. With the rise of Sculpt and the packaging of components in a - as far as possible - kernel-independent way, the propagation of kernel-specific information became a stumbling block.

With this release we abandon the hypervisor_info_page ROM of Genode/NOVA and replace it with a Genode ROM called platform_info. The platform_info ROM is planned to contain solely information about the host hardware, which may not be gathered otherwise by Genode components. In the current state it contains information required by VMMs, namely whether AMD SVM or Intel VMX is available and usable. Additionally, the ROM contains information about the frequency of the time stamp counter.

Updated seL4 kernel to version 9.0.1

Thanks to Hinnerk van Bruinehsen, the seL4 version used by Genode has been updated to 9.0.1.

Updated Muen separation kernel

With the addition of memory-mapped access to the PCI config-space in Genode, base-hw subjects on Muen now only see the effectively assigned physical devices. This makes it possible to run Genode in parallel with other subjects and to pass-through different PCI devices for each instance.

The Muen update also brings a much simplified subject info structure plus some tweaks to the Muen system policy XML format to facilitate easier integration of new hardware platform specifications.

Build system and tools

Validating 3rd-party code downloads via SHA256

This release removes support for verifying source code of third-party ports with the SHA1 hash algorithm. Last year, SHA1 was banished as a credible cryptographic hash function after the demonstration of a full collision attack. Since the 14.05 release, port files have been verified using SHA1, this release replaces all file digests with SHA256 digests. Any port definitions maintained in external repositories are required to make these replacements as well. No collisions have been discovered against source code archives but nonetheless there is an obligation to widen our margin of safety.

Creating GPT-based disk images by default

Up to now Genode's run tool was able to create x86 bootable images in three flavours:

• Either as ISO bootable by BIOS legacy - image/iso, or as

• GPT partitioned disk image only bootable by UEFI - image/uefi, or as

• MBR partitioned disk image only bootable by BIOS legacy - image/disk.

With Sculpt came the demand to have a single image type that is in principle bootable by both UEFI and BIOS legacy. Additionally with Sculpt, we began to prefer working with GPT partitioned devices.

In the light of the new demands, we changed the image/disk run tool support to create a GPT partitioned disk image bootable by a legacy BIOS and by UEFI.