The parent-service registry is populated on demand by the
'Loader::Child' whenever a prior unknown service is requested. Since the
number of parent services is limited, we expect the registry to settle
after a while. However, each loader session has a private instance of
a parent-service registry. So when creating and destroying loader
sessions, parent registries will be populated again and again. We
have to make sure to discard the entries along with the destruction
of a loader session to avoid the leakage of memory.
Issue #717
Add functionality to lookup an object and lock it. Additional the case is
handled that a object may be already in-destruction and the lookup will deny
returning the object.
The object_pool generalize the lookup and lock functionality of the rpc_server
and serve as base for following up patches to fix dangling pointer issues.
With this patch, the loader installs an optional client-provided fault
handler as default CPU exception handler and RM fault handler for all
CPU and RM sessions of the loaded subsystem. This way, loader clients
become able to respond to failures occuring within the subsystem.
The new feature is provided via the added 'Loader::fault_handler' RPC
function.
The 'run/failsafe' test covers two cases related to the loader, which
are faults produced by the immediate child of the loader and faults
produced by indirect children.
On Linux, we want to attach additional attributes to processes, i.e.,
the chroot location, the designated UID, and GID. Instead of polluting
the generic code with such Linux-specific platform details, I introduced
the new 'Native_pd_args' type, which can be customized for each
platform. The platform-dependent policy of init is factored out in the
new 'pd_args' library.
The new 'base-linux/run/lx_pd_args.run' script can be used to validate
the propagation of those attributes into core.
Note that this patch does not add the interpretation of the new UID and
PID attributes by core. This will be subject of a follow-up patch.
Related to #510.
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.
The original loader service was primarily motivated by the
browser-plugin scenario presented on our live CD. The new version
implements a more general session interface, which widens the
application scope of the service and, at the same time, reduces its
implementation complexity.
The complexity reduction is achieved by removing the original limitation
of supplying the new sub system as a single binary blob only. The server
used to implement heuristics and functionality for dealing with
different kinds of blobs such as ELF images or TAR archives. This has
been replaced by a session-local ROM service, which can be equipped with
an arbitrary number of ROM modules supplied by the loader client prior
starting the new sub system. Even though the TAR support has been
removed, a separate instance of the 'tar_rom' service can be used within
the subsystem to provide the formerly built-in functionality.
