In case the storage-entry point dispatches more then one packet, wait for the
previous command to finish before setting a new request. This has to be done
because the 'queuecommand' does actually *not* queue things, but can only handle
one request at the time.
Fix#1143
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.
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.
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.
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
