blob: f70466530a1f40b716f185905630b3ac80655ff0 (
plain)
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
|
System overrides
================
It should be possible to create limited arenas (with allowlisting):
func main(arena System system) -> ExitStatus
{
arena System limited = .some_limited_arena(system)
...
do_stuff(limited)
...
return .success
}
But it might be necessary to add system functionality (and maybe even
outside of the runtime itself?)
This could be done like this:
* Unique identifiers for each "system functionality".
(This needs language support, but can be useful in other cases also).
data uniqueid<System> our_id = .init()
- But how to initialize this?
- Can it be done without initializers?
- Can it be done without hacks in the dynamic loader?
- Function adresses are unique (within a process),
but also large (when used as a key, it would require a
hashmap, rather than an array)
- The runtime could have a function for translating a local code
pointer (maybe not necessarilly a function pointer) + a
module-internally unique ID into a process-wide unique ID.
* Some kind of "sub-arena builder" functionality, where such identifiers
can be passed in (along with more information, e.g. about what should be
allowed and not).
- Maybe the "builder methods" should go into each module that
implements additional "system functionality".
func main(arena System system) -> ExitStatus
{
var TmpFs home = .new(arena)
home.mkdir("user")
arena System limited = .subarena(
.allow_fs_tree("/etc")
.divert_fs_root("/home", home.as_filesystem())
# example of custom "system functionality":
.allow_pkcs11("/usr/lib/somemodule.so", "sometoken", .sign)
)
...
}
|
