Commit Graph

12 Commits

Author SHA1 Message Date
Norman Feske
5a1cef6381 Make label prefixing more strict
This patch unconditionally applies the labeling of sessions and thereby
removes the most common use case of 'Child_policy::filter_session_args'.
Furthermore, the patch removes an ambiguity of the session labels of
sessions created by the parent of behalf of its child, e.g., the PD
session created as part of 'Child' now has the label "<child-name>"
whereas an unlabeled PD-session request originating from the child
has the label "<child-name> -> ". This way, the routing-policy of
'Child_policy::resolve_session_request' can differentiate both cases.

As a consequence, the stricter labeling must now be considered wherever
a precise label was specified as a key for a session route or a server-
side policy selection. The simplest way to adapt those cases is to use a
'label_prefix' instead of the 'label' attribute. Alternatively, the
'label' attribute may used by appending " -> " (note the whitespace).

Fixes #2171
2016-11-30 13:37:07 +01:00
Norman Feske
17c79a9e23 base: avoid use of deprecated base/printf.h
Besides adapting the components to the use of base/log.h, the patch
cleans up a few base headers, i.e., it removes unused includes from
root/component.h, specifically base/heap.h and
ram_session/ram_session.h. Hence, components that relied on the implicit
inclusion of those headers have to manually include those headers now.

While adjusting the log messages, I repeatedly stumbled over the problem
that printing char * arguments is ambiguous. It is unclear whether to
print the argument as pointer or null-terminated string. To overcome
this problem, the patch introduces a new type 'Cstring' that allows the
caller to express that the argument should be handled as null-terminated
string. As a nice side effect, with this type in place, the optional len
argument of the 'String' class could be removed. Instead of supplying a
pair of (char const *, size_t), the constructor accepts a 'Cstring'.
This, in turn, clears the way let the 'String' constructor use the new
output mechanism to assemble a string from multiple arguments (and
thereby getting rid of snprintf within Genode in the near future).

To enforce the explicit resolution of the char * ambiguity, the 'char *'
overload of the 'print' function is marked as deleted.

Issue #1987
2016-08-29 17:27:10 +02:00
Emery Hemingway
51e8f05fb6 Ajdust run scenarios for strict policy matching
Issue #1901
2016-06-22 12:21:41 +02:00
Norman Feske
3bceefc9cf Omit superfluous use of "CAP"/"SIGNAL" services
The functionality of the former "CAP" and "SIGNAL" services is now
provided by core's "PD" service.
2016-05-09 13:24:51 +02:00
Emery Hemingway
20dc750d6a Update run scenarios for policy label matching
Issue #1766
2015-11-29 18:17:06 +01:00
Josef Söntgen
88f62b0988 autopilot: adapt runscripts to new run tool
Related to #1372.
2015-01-26 12:28:41 +01:00
Stefan Kalkowski
28112d1ff9 rump: exclude ARM architectures apart from v7
Ref #1366
2015-01-20 11:23:50 +01:00
Josef Söntgen
f01472b308 dde_rump: Update to current version
Issue #1361
2015-01-20 11:23:49 +01:00
Christian Helmuth
0b5f901e58 Log name of exiting child from Child::exit()
Fixes #1243.
2014-09-11 10:23:39 +02:00
Josef Söntgen
65bdddbbdf dde_rump: rump_iso compare output on 64bit systems
Fixes #1141.
2014-06-06 14:54:30 +02:00
Josef Söntgen
e777165090 dde_rump: block encryption server using cgd(4)
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.
2014-05-27 11:14:45 +02:00
Norman Feske
ca971bbfd8 Move repositories to 'repos/' subdirectory
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
2014-05-14 16:08:00 +02:00