On ARM, when machine instructions get written into the data cache
(for example by a JIT compiler), one needs to make sure that the
instructions get written out to memory and read from memory into
the instruction cache before they get executed. This functionality
is usually provided by a kernel syscall and this patch adds a generic
interface for Genode applications to use it.
Fixes#1153.
Using 'upvar' instead of 'global' in the 'append_if' and 'lappend_if'
functions makes it possible to use these functions with local variables
of the calling function.
Fixes#1137.
The 'rump_cgd' server provides block level encryption for a block
session by employing the 'cgd(4)' device provided by the rumpkernel.
'rump_cgd' uses a Block_session to get access to an existing block
device and provides another Block_session to its clients. Each block
written or read by the client is transperently encrypted or decrypted
by the server.
For now 'rump_cgd' may only _configure_ a 'cgd' device but is unable
to generate a configuration. The used cipher is hardcoded to
_aes-cbc_ with a keysize of 256 bit. Furthermore the server is able to
serve one client only.
To ease the usage, its interface is modelled after the interface of
'cgdconfig(8)'. As implications thereof the key must have the same
format as used by 'cgdconfig'. That means the key is a base 64 encoded
string in which the first 4 bytes denote the actual length of the key
in bits (these 4 bytes are stored in big endian order).
Preparing a raw (e.g. without partition table) encrypted Ext2 disk
image is done by executing 'tool/rump':
! dd if=/dev/urandom of=/path/to/disk_image
! rump -c /path/to/disk_image # key is printed to stdout
! rump -c -k <key> -F ext2fs /path/to/disk_image
To use this disk image the following config snippet can be used:
! <start name="rump_cgd">
! <resource name="RAM" quantum="8M" />
! <provides><service name="Block"/></provides>
! <config action="configure">
! <params>
! <method>key</method>}
! <key>AAABAJhpB2Y2UvVjkFdlP4m44449Pi3A/uW211mkanSulJo8</key>
! </params>
! </config>
! <route>
! <service name="Block"> <child name="ahci"/> </service>
! <any-service> <parent/> <any-child/> </any-service>
! </route>
! </start>
the Block service provided by rump_cgd may be used by a file system
server in return:
! <start name="rump_fs">
! <resource name="RAM" quantum="16M"/>
! <provides><service name="File_system"/></provides>
! <config fs="ext2fs">
! <policy label="" root="/" writeable="yes"/>
! </config>
! <route>
! <service name="Block"> <child name="rump_cgd"/> </service>
! <any-service> <parent/> <any-child/> </any-service>
! </route>
! </start>
Since 'tool/rump' just utilizes the rumpkernel running on the host
system to do its duty there is a script called 'tool/cgdconf' that
extracts the key from a 'cgdconfig(8)' generated configuration file
and also is able to generade such a file from a given key. Thereby
the interoperabilty between 'rump_cgd' and the general rumpkernel
based tools is secured.
The rumpkernel based tools are intended to be used by executing
'tool/rump'. Since it covers the most common use cases for these
tools, this script is comparatively extensive, hence giving a short
tutorial seems reasonable:
* Format a disk image with Ext2:
To format a disk image with the Ext2 file system, first prepare the
actual image by executing dd:
! dd if=/dev/zero of=/path/to/disk_image bs=1M count=128
Second, use 'tool/rump' to format the disk image:
! rump -f -F ext2fs /path/to/disk_image
Afterwards the just created file system may be populated with the
content of another directory by executing
! rump -F ext2fs -p /path/to/another_dir /path/to/disk_image
The content of the file system image can be listed by executing
! rump -F ext2fs -l /path/to/disk_image
* Create a encrypted disk image:
Creating a cryptographic disk image based on cgd(4) is done by
executing the following command:
! rump -c /path/to/disk_image
This will generate a key that may be used to decrypt the image
later on. Since this command will _only_ generate a key and NOT
initialize the disk image, it is highly advised to prepare the disk
image by using '/dev/urandom' instead of '/dev/zero' (only new blocks
that will be written to the disk image are encrypted). In addition
while generating the key a temporary configuration file will be
created. Although this file has proper permissions, it may leak the
generated key if it is created on persistent storage. To specify a more
secure directory the '-t' option should be used:
! rump -c -t /path/to/secure/directory /path/to/disk_image
Decrypting the disk image requires the key generated in the previous
step:
! rump -c -k <key> /path/to/disk_image
For now this key has to specified as command line argument. This is
an issue if the shell, which is used, is maintaing a history of
executed commands.
For completness sake let us put all examples together by creating a
encrypted Ext2 image that will contain all files of Genode's _demo_
scenario:
! dd if=/dev/urandom of=/tmp/demo.img bs=1M count=16
! $(GENODE_DIR)/tool/rump -c -t /ramfs -F ext2fs /tmp/demo.img > \
! /ramfs/key # key is printed out to stdout
! $(GENODE_DIR)/tool/rump -c -t /ramfs -F ext2fs -k <key> \
! -p $(BUILD_DIR)/var/run/demo /tmp/demo.img
To check if the image was populated succesfully, execute the
following:
! $(GENODE_DIR)/tool/rump -c -t /ramfs -F ext2fs -k <key> -l \
! /tmp/demo.img
The rumpkernel tools are used within the Genode OS Framework tool chain
for preparing and populating disk images as well as creating cgd(4)
based cryptographic disk devices.
Execute 'tool/tool_chain_rump build' to build the tools and afterwards
'tool/tool_chain_rump install' to install the binaries. The default
install location is _/usr/local/genode-rump_.
On ARM in one way or another 'string.h' prototypes will be used. Move
the definitions from rump_fs to the rump library because it is needed
by all rump based servers running on ARM.
Issue #1141.
Use _italic_ for path names rather than 'verbatim'. Because path names
tend to be quite long, the overly use of verbatim makes paragraphs hard
to read.
The new 'select_from_ports' function allows a target description file to
query the path to an installed port. All ports are stored in a central
location specified as CONTRIB_DIR. By default, CONTRIB_DIR is defined
as '<genode-dir>/contrib'. Ports of 3rd-party source code are managed
using the tools at '<genode-dir>/tool/ports/'.
Issue #1082
This patch changes the top-level directory layout as a preparatory
step for improving the tools for managing 3rd-party source codes.
The rationale is described in the issue referenced below.
Issue #1082
This patch avoids the construction of the Genode::Config object in Noux
processes. The construction of this object would populate the Noux
process with additional capabilities, which cannot be handled by
'fork()'.
The old implementation of sleep_forever() used a local Ipc_server
object, which is not announced (i.e., known) outside of the blocking
process/thread, to infinitely wait for incoming messages. In past and
present, this leads to problems (e.g., issues #538 and #1032).
Fixes#1135.
Fixes#538.
Fixes#1032.
Use the libc Mem_alloc implementation per MMTYP of virtualbox. With this the
invariant that all memory allocation of a MMTYP are dense located.
Fixes#1130
