L4 is family of microkernels. There are several versions of the L4 specification (covering both API and ABI), each of them having one or more implementation. The Hurd will be based, at first, on the Pistachio version (the reference implementation of the newest L4 specifications, X.2).
The philosophy behind the whole project can be summarized in a few points:
To achieve that, one of the main focus of the L4Ka work was to provide very fast IPCs:
Very few things are still inside the kernel (the whole Pistachio provides 11 system calls):
With L4, every delicate operation is performed using RPCs. Therefore, controlling the IPCs an application can do, allows the system (or a specific application like a debugger) to control the application completely, from a security point of view at least.
This was the security model of Hazelnut. In this model, a clan is composed of all the tasks created by the same one task. The creator is the chief of the clan. In the Clans & Chiefs model, an IPC is only allowed from a task to:
All other IPCs are directed through the shortest path of chiefs. Each chief can drop or modify the message.
The new security model is called IPC redirect: with each thread is associated a redirector (another thread of the same task, or more often another task) controling incoming and/or outgoing IPCs. Redirectors can be changed at run-time, and can be stacked (setting a redirector to a thread already acting as a redirector).
This new system was designed for two reasons: first Clans & Chiefs was too complex and too slow (the chain could be long, and even if a single IPC is fast, a huge amount of them will take some time); but mostly it was a decision upon the OS policy, and in the L4Ka philosophy such decisions must be kept outside of the kernel.
It is possible to implement Clans & Chiefs on top of IPC redirect with the proper redirectors.
The IPC redirect mechanism can be very useful, for example to monitor applications (for debugging, for profiling, for security, just to keep logs of what the program did, ...); or to allow sand-boxing. Sand-boxing is running untrusted code inside a sand-box, the sand-box preventing the code to interact directly with the operating system. With sand-boxing, you could even run untrusted binary code directly on the main CPU without any need of virtual machine, and without taking any risk from the security point of view. This can be very useful for interactive web, or even to run the rendering engine of a web browser (and this way protect the system from a security flaw inside the browser).