e777165090
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. |
||
|---|---|---|
| doc | ||
| repos | ||
| tool | ||
| .gitignore | ||
| LICENSE | ||
| README | ||
| VERSION | ||
README
=================================
Genode Operating System Framework
=================================
This is the source tree of the reference implementation of the Genode OS
architecture. For a general overview about the architecture, please refer to
the project's official website:
:Official project website for the Genode OS Framework:
[http://genode.org/documentation/general-overview]
The current implementation can be compiled for 8 different kernels: Linux,
L4ka::Pistachio, L4/Fiasco, OKL4, NOVA, Fiasco.OC, Codezero, and a custom
kernel for running Genode directly on ARM-based hardware. Whereas the Linux
version serves us as development vehicle and enables us to rapidly develop the
generic parts of the system, the actual target platforms of the framework are
microkernels. There is no "perfect" microkernel - and neither should there be
one. If a microkernel pretended to be fit for all use cases, it wouldn't be
"micro". Hence, all microkernels differ in terms of their respective features,
complexity, and supported hardware architectures.
Genode allows the use of each of the kernels listed above with a rich set of
device drivers, protocol stacks, libraries, and applications in a uniform way.
For developers, the framework provides an easy way to target multiple different
kernels instead of tying the development to a particular kernel technology. For
kernel developers, Genode contributes advanced workloads, stress-testing their
kernel, and enabling a variety of application use cases that would not be
possible otherwise. For users and system integrators, it enables the choice of
the kernel that fits best with the requirements at hand for the particular
usage scenario.
Directory overview
##################
The source tree is composed of the following subdirectories:
:'doc':
This directory contains general documentation. Please consider the following
document for a quick guide to get started with the framework:
! doc/getting_started.txt
If you are curious about the ready-to-use components that come with the
framework, please review the components overview:
! doc/components.txt
:'repos':
This directory contains the so-called source-code repositories of Genode.
Please refer to the README file in the 'repos' directory to learn more
about the roles of the individual repositories.
:'tool':
Source-code management tools and scripts. Please refer to the README file
contained in the directory.
Contact
#######
The best way to get in touch with Genode developers and users is the project's
mailing list. Please feel welcome to join in!
:Genode Mailing Lists:
[http://genode.org/community/mailing-lists]