|
| ▲ | yazaddaruvala 2 hours ago | parent | next [-] |
| An extremely verbose effects system can resolve these dependency permissions at compile time. However, balancing ergonomics is a the big challenge. I personally would prefer less ergonomics for more security, but that’s likely not a broadly shared opinion. |
|
| ▲ | amelius 4 hours ago | parent | prev | next [-] |
| This is a nice exercise for compiler researchers. I suppose it can be done on various levels, with various performance trade-offs. |
| |
| ▲ | convolvatron 3 hours ago | parent [-] | | more specifically, one can introduce policies into the runtime, or given rust hoist at least some of them into compiletime that would do things like (a) enforce syscall filtering based on crate or even function (b) support private memory regions for crates or finer grained entities that are only unlocked upon traversing a declared call-gate (c) the converse, where crates can only access memory they themselves have allocated except a whitelist of parameters (d) use even heavier calling conventions that rpc to entirely separate processes |
|
|
| ▲ | 9rx 3 hours ago | parent | prev [-] |
| By using the type system. You define your type constraints at the module interface point and when you try to link the third-party module into that interface the compiler ensures that the constraints are satisfied. Same thing the compiler is already doing in simpler cases. If you specify that a third-party library function must return an integer, the compiler will ensure that function won't unexpectedly return a string. Just like that, except the type system is expanded to enable describing more complex behaviours. |
