8 ms·

Sandboxing is a mitigation but a very limited one. The library itself can contain a malicious payload -- rust code most often ends up as native code executed on

Sandboxing is a mitigation but a very limited one. The library itself can contain a malicious payload -- rust code most often ends up as native code executed on the host. I think we may need to enter a world where there are fewer, heavily audited, libraries and dependency depth is limited. Allowing unvetted dependencies to be installed by default is not a good way forward. App stores have a similar problem and I think a lot of lessons have been learned there that can be applied.

7373737373 1mo ago
That's why languages need sandboxing at runtime as well
- josephg 1mo ago
  Yes, or the compile time equivalents. Rust’s safety gets you most of the way there. We just need a capability model in the language, a more limited std and a way to ban untrusted 3rd party libraries from using unsafe code without explicit permission. I dream of a world where a function with the signature of add(u32, u32) -> u32 can’t burn my house down and steal my wife. Functions should only have access to their arguments. Nothing more. We need to end ambient authority.
  - nh2 1mo ago
    You have just reinvented "Safe Haskell" from 2012. It guarantees that pure functions are pure. https://www.microsoft.com/en-us/research/publication/safe-haskell/ https://www.microsoft.com/en-us/research/publication/safe-ha... https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/safe_haskell.html https://downloads.haskell.org/ghc/latest/docs/users_guide/ex...
    - josephg 1mo ago
      Oooh I didn't know that was a thing! Yes, I want this but in a fast, compiled systems language like rust.
      - tome 1mo ago
        Haskell is a fast, compiled systems language like Rust (or rather, Rust is like Haskell).
        josephg 1mo ago
        Are you sure about that? My understanding is that Haskell programs generally run much more slowly than their C counterparts because of all of Haskell’s magic. Like lazy evaluation and memoisation and however Haskell manages memory. Rust certainly borrows from Haskell. Like all good languages. But I’m not aware of Haskell beating rust in program performance & memory usage benchmarks. SeL4 was first written in Haskell and proven correct in Haskell. Then, with a great many years of effort, ported to C and proven correct there. If Haskell were a viable systems language, I suspect the kernel would not have been converted to C.
        tome 1mo ago
        Yes, I'm sure about that. I said that it is a systems language, not that it is as fast as C! I don't mind if your terminology excludes Haskell from being a systems language, as long as it also excludes Go. They are both managed, garbage collected, fast languages. > Like lazy evaluation and memoisation Yes, that causes performance impact. If you don't want the performance impact then don't write code that uses those behaviors. Sure, that rules out large parts of the ecosystem, but I said Haskell was a systems language not that its ecosystem was generally suitable for systems programming. > however Haskell manages memory No, Haskell's memory manager is world class, with two (at least) tunable garbage collectors. > But I’m not aware of Haskell beating rust in program performance & memory usage benchmarks Nor am I! > If Haskell were a viable systems language, I suspect the kernel would not have been converted to C. I suspect they converted it to C because you can't write a kernel in a managed language with a garbage collector.
k_roy 1mo ago
That world can’t exist unfortunately, because the minute someone wants a feature that isn’t in your core libraries, you just create a new library and we’re back to now.

7373737373 1mo ago

That's why languages need sandboxing at runtime as well

josephg 1mo ago
Yes, or the compile time equivalents. Rust’s safety gets you most of the way there. We just need a capability model in the language, a more limited std and a way to ban untrusted 3rd party libraries from using unsafe code without explicit permission. I dream of a world where a function with the signature of add(u32, u32) -> u32 can’t burn my house down and steal my wife. Functions should only have access to their arguments. Nothing more. We need to end ambient authority.
- nh2 1mo ago
  You have just reinvented "Safe Haskell" from 2012. It guarantees that pure functions are pure. https://www.microsoft.com/en-us/research/publication/safe-haskell/ https://www.microsoft.com/en-us/research/publication/safe-ha... https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/safe_haskell.html https://downloads.haskell.org/ghc/latest/docs/users_guide/ex...
  - josephg 1mo ago
    Oooh I didn't know that was a thing! Yes, I want this but in a fast, compiled systems language like rust.
    - tome 1mo ago
      Haskell is a fast, compiled systems language like Rust (or rather, Rust is like Haskell).
      - josephg 1mo ago
        Are you sure about that? My understanding is that Haskell programs generally run much more slowly than their C counterparts because of all of Haskell’s magic. Like lazy evaluation and memoisation and however Haskell manages memory. Rust certainly borrows from Haskell. Like all good languages. But I’m not aware of Haskell beating rust in program performance & memory usage benchmarks. SeL4 was first written in Haskell and proven correct in Haskell. Then, with a great many years of effort, ported to C and proven correct there. If Haskell were a viable systems language, I suspect the kernel would not have been converted to C.
        tome 1mo ago
        Yes, I'm sure about that. I said that it is a systems language, not that it is as fast as C! I don't mind if your terminology excludes Haskell from being a systems language, as long as it also excludes Go. They are both managed, garbage collected, fast languages. > Like lazy evaluation and memoisation Yes, that causes performance impact. If you don't want the performance impact then don't write code that uses those behaviors. Sure, that rules out large parts of the ecosystem, but I said Haskell was a systems language not that its ecosystem was generally suitable for systems programming. > however Haskell manages memory No, Haskell's memory manager is world class, with two (at least) tunable garbage collectors. > But I’m not aware of Haskell beating rust in program performance & memory usage benchmarks Nor am I! > If Haskell were a viable systems language, I suspect the kernel would not have been converted to C. I suspect they converted it to C because you can't write a kernel in a managed language with a garbage collector.

k_roy 1mo ago

That world can’t exist unfortunately, because the minute someone wants a feature that isn’t in your core libraries, you just create a new library and we’re back to now.