genode/os
Norman Feske b45242c50f Add chroot support to core
Since the recent move of the process creation into core, the original chroot trampoline
mechanism implemented in 'os/src/app/chroot' does not work anymore. A
process could simply escape the chroot environment by spawning a new
process via core's PD service. Therefore, this patch moves the chroot
support into core. So the chroot policy becomes mandatory part of the
process creation.  For each process created by core, core checks for
'root' argument of the PD session. If a path is present, core takes the
precautions needed to execute the new process in the specified chroot
environment.

This conceptual change implies minor changes with respect to the Genode
API and the configuration of the init process. The API changes are the
enhancement of the 'Genode::Child' and 'Genode::Process' constructors to
take the root path as argument. Init supports the specification of a
chroot per process by specifying the new 'root' attribute to the
'<start>' node of the process. In line with these changes, the
'Loader::Session::start' function has been enhanced with the additional
(optional) root argument.
2012-11-05 17:31:05 +01:00
..
config Imported Genode release 11.11 2011-12-22 16:19:25 +01:00
doc Add chroot support to core 2012-11-05 17:31:05 +01:00
include Add chroot support to core 2012-11-05 17:31:05 +01:00
lib/mk NOVA: Fix ldso test for 64bit 2012-08-14 10:19:54 +02:00
run Add chroot support to core 2012-11-05 17:31:05 +01:00
src Add chroot support to core 2012-11-05 17:31:05 +01:00
tool Imported Genode release 11.11 2011-12-22 16:19:25 +01:00
README Imported Genode release 11.11 2011-12-22 16:19:25 +01:00

This is the example operating system based on the Genode OS framework:

:_Init_: is the first real process in the system. The provided implementation
  uses a very simple XML parser to read its configuration files.

:_Drivers_: The example OS has basic drivers for frame buffer, mouse and
  keyboard input, the PCI bus, the real-time clock, and system-specific timers.

:_Server_: The only server in the example OS is Nitpicker, a
  minimal-complexity GUI server.

:_Test_: are also part of the example OS. You may have a look at the fork
  bomb as a simple system stress test.

:_Ldso_: is the dynamic linker used for loading executables that are linked
  against shared libraries.

:_Lib_: contains libraries used by the components of the OS repository,
  in particular the device-driver kit, the alarm framework, and support
  for dynamic linking.