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.
GCC warns about uninitialized local variables in cases where no
initialization is needed, in particular in the overloads of the
'Capability::call()' function. Prior this patch, we dealt with those
warnings by using an (unreliable) GCC pragma or by disabling the
particular warning altogether (which is a bad idea). This patch removes
the superfluous warnings by telling the compiler that the variable in
question is volatile.
Without limiting the size of the launchpad window, the application
prepares itself for the worst case, taking the screen size as maximum
size to allocate its pixel buffers. Limiting the maximum width to a
reasonable value reduces the memory footprint.
This patch makes use of the recently added support for const RPC
functions by turning 'Framebuffer::Session::mode()' and
'Input::Session::is_pending()' into const functions.
The 'mode_sigh' function allows the client to receive notifications
about server-side display-mode changes. To respond to such a signal, the
client can use the new 'release' function, which acknowledges the mode
change at the server and frees the original framebuffer dataspace. Via a
subsequent call of 'dataspace', a framebuffer dataspace corresponding to
the new mode can be obtained. Related to issue #11.
As a preliminary step for working on issue #11, this patch revisits the
'Framebuffer::info' RPC call. Instead of using C-style out paramters,
the new 'mode()' RPC call returns the mode information as an object of
type 'Mode'. Consequently, mode-specific functions such as
'bytes_per_pixel' have been moved to the new 'Framebuffer::Mode' class.
Norman Feske
Sebastian Sumpf
Genode Labs