aaf0454956
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 |
||
|---|---|---|
| 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]