1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
|
# 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?)]
|
