Potential applications of object-capability languages

The work discussed is this last part would have fewer immediate benefits for the Hurd project and has more of a research orientation. It is also unlikely that there would be any time remaining to work on it at the end of the summer. (Though it could work as some kind of reward if I somehow managed to do a prefect job of all the rest within the allocated time ). As a consequence, I don't really consider this a part of my application.

This being said, to some extent the project discussed here will informed the way I design the Java bindings, since it depends on them and I intend to work on this at some point in the future. I also believe it touches on some interesting ideas, and a Summer of Code application is probably as good an occasion as any to discuss them.

Justification

The primary advantage of multi-server operating systems is the ability to break what used to be the kernel into small pieces which can be isolated from each others. This makes sense from an engineering perspective, as smaller components can be swapped with different implementations and reduce the impact of bugs. A capability-based approach also ensures that the authority wielded by components is clear and reduced to the minimum required for them to function. These properties are crucial to the Hurd's agenda of user freedom, since in order to allow them to plug their own code into the system [FIXME: développer]

However, this flexibility has a cost. In a system where the isolation of components relies on running them inside different address spaces, communication between them must be done through IPC calls. This introduces a trade-off between the size of the modules and performance as well as practicality, which imposes a limit to the granularity with which the system can be decomposed and the principle of least authority applied (to the code within a given process, a Mach port is ambient authority).

Another issue is that of the threading structure of the system as a whole. In systems based on a monolithic kernel, user threads execute the kernel code themselves, which is then intrinsically concurrent. By contrast, in a system based on a “client-server” paradigm, each server must be explicitly multi-threaded if it is to serve requests concurrently.

Object-capability languages

An object-capability language is an object-oriented language which is restricted enough so that object references are themselves capabilities.

One such language is Joe-E (FIXME: lien), which is an object-capability subset of Java: global state and static methods are mostly forbidden; careful white-listing of the objects and methods provided by the Java standard library ensures that compliant code cannot not access ambient autority. Ways in which object references can be transferred are restricted to the most obvious ones (for instance, exceptions are carefully restricted).

As a result, untrusted Joe-E code can be executed without any further isolation and its autority can be controlled by carefully limiting the object references which are passed to it. This would allow to load and execute translators written in Joe-E in a single address space.

Bundling translators into a single process

[mechanisme pour transmettre le code Joe-E et les port initiaux au serveur] [émulation des différentes tâches]

Challenges and further work

[proof-carrying code / typed assembly, resource accounting (passer en revue la conception de Viengoos?)]