3 ms·

How is Fil-C’s wrapper approach different from someone (not necessarily the Rust stdlib) implementing a safe wrapper around a particular syscall? mmap is a bit

by Cyph0n 2mo ago

How is Fil-C’s wrapper approach different from someone (not necessarily the Rust stdlib) implementing a safe wrapper around a particular syscall? mmap is a bit of an outlier because it is not possible to implement a fully featured safe wrapper (MAP_SHARED) in Rust. So I would be curious to see what safety guarantees Fil-C claims to provide for mmap.

modeless 2mo ago
Adding Fil-C-like runtime checks to Rust is definitely an interesting direction. As I mentioned upthread. It's not just the availability of the safe API that's interesting, though, but also the prohibition on using the unsafe API in the entire program and all dependencies. Which Rust could also do in theory but not yet in practice AFAIK.
- wildfireday2 2mo ago
  Complete memory safety (much less concurrent garbage collection) isn’t really workable for things like kernel and some embedded programming contexts. Rust can work in those contexts precisely because it has an unsafe out. Even so Fil-C fails at being 100% compatible for userspace due to the silly things people do with pointers. Hence the large amount of effort he’s had to do to fix up that 0.1% of userspace that breaks.
- scns 2mo ago
  > but also the prohibition on using the unsafe API in the entire program and all dependencies. Which Rust could also do in theory but not yet in practice AFAIK. It is possible, check MaulingMonkeys' comment upthread.
jitl 2mo ago
Rust is less safe because it has a feature for turning off safety, called `unsafe`. Fil-C does not have a way to turn off safety, and it enforces safety checks at runtime. That's the reasoning anyways. If you define another language Rust-Without-Any-Unsafe, then maybe that one is safer than Fil-C.
- MaulingMonkey 2mo ago
  > If you define another language Rust-Without-Any-Unsafe, then maybe that one is safer than Fil-C. Just write `#![forbid(unsafe_code)]` at the top of your src/lib.rs, and track crates not using it with `cargo geiger`. You don't need a whole new language, it already provides the tools to wield that hatch shut. > Rust is less safe because it has a feature for turning off safety Can I write Fil-C's mmap wrapper in Fil-C? If no, fair enough, but it's worth noting I can write a safe Rust mmap wrapper in Rust, and I absolutely and frequently need to do that kind of "syscall wrapping" in arenas Fil-C explicitly hasn't handled, by virtue of being explicitly a Linux project. If yes, that sounds like an escape hatch to Fil-C's memory safety, undermining the claim that Fil-C is fundamentally safer, and you're now at best arguing it's safer as tends to be used.
  - im3w1l 2mo ago
    It should be mentioned that rust's type system has a long-standing known bug compromising memory safety, as made famous by cve-rs. It's perhaps not a big issue for most people but if you are someone that wants the assurances of #![forbid(unsafe_code)] that should probably be on your radar.
    - kibwen 2mo ago
      Certainly, we should build into our threat model the idea that the implementation of Rust will have bugs that compromise safety until proven otherwise (merely fixing that one aforementioned bug won't alter that calculus). And the same applies to Fil-C: we should assume it has bugs that compromise safety until proven otherwise. Until then, in practice, Rust has much more real-world use that convincingly demonstrates its ability to realistically eliminate memory safety risks.
      - im3w1l 2mo ago
        A known bug with easily accessible proof-of-concept is quite different from a theoretical bug.
deathanatos 2mo ago
> from someone (not necessarily the Rust stdlib) implementing a safe wrapper around a particular syscall? You might call that library "nix"[1]. Many, though not all, of the bindings are safe wrappers around the underlying unsafe syscall. (The specific call of mmap from upthread, though, that one is not. I'm not sure how you would make such a call safe.) [1]: https://docs.rs/nix/latest/nix/index.html https://docs.rs/nix/latest/nix/index.html
pizlonator 2mo ago
mmap is a great example of Fil-C providing a unique level of safety. You can’t use mmap in a way that corrupts memory in Fil-C Try it. :-)

by Cyph0n 2mo ago

modeless 2mo ago

Adding Fil-C-like runtime checks to Rust is definitely an interesting direction. As I mentioned upthread. It's not just the availability of the safe API that's interesting, though, but also the prohibition on using the unsafe API in the entire program and all dependencies. Which Rust could also do in theory but not yet in practice AFAIK.

wildfireday2 2mo ago
Complete memory safety (much less concurrent garbage collection) isn’t really workable for things like kernel and some embedded programming contexts. Rust can work in those contexts precisely because it has an unsafe out. Even so Fil-C fails at being 100% compatible for userspace due to the silly things people do with pointers. Hence the large amount of effort he’s had to do to fix up that 0.1% of userspace that breaks.
scns 2mo ago
> but also the prohibition on using the unsafe API in the entire program and all dependencies. Which Rust could also do in theory but not yet in practice AFAIK. It is possible, check MaulingMonkeys' comment upthread.

jitl 2mo ago

Rust is less safe because it has a feature for turning off safety, called `unsafe`. Fil-C does not have a way to turn off safety, and it enforces safety checks at runtime. That's the reasoning anyways. If you define another language Rust-Without-Any-Unsafe, then maybe that one is safer than Fil-C.

MaulingMonkey 2mo ago
> If you define another language Rust-Without-Any-Unsafe, then maybe that one is safer than Fil-C. Just write `#![forbid(unsafe_code)]` at the top of your src/lib.rs, and track crates not using it with `cargo geiger`. You don't need a whole new language, it already provides the tools to wield that hatch shut. > Rust is less safe because it has a feature for turning off safety Can I write Fil-C's mmap wrapper in Fil-C? If no, fair enough, but it's worth noting I can write a safe Rust mmap wrapper in Rust, and I absolutely and frequently need to do that kind of "syscall wrapping" in arenas Fil-C explicitly hasn't handled, by virtue of being explicitly a Linux project. If yes, that sounds like an escape hatch to Fil-C's memory safety, undermining the claim that Fil-C is fundamentally safer, and you're now at best arguing it's safer as tends to be used.
- im3w1l 2mo ago
  It should be mentioned that rust's type system has a long-standing known bug compromising memory safety, as made famous by cve-rs. It's perhaps not a big issue for most people but if you are someone that wants the assurances of #![forbid(unsafe_code)] that should probably be on your radar.
  - kibwen 2mo ago
    Certainly, we should build into our threat model the idea that the implementation of Rust will have bugs that compromise safety until proven otherwise (merely fixing that one aforementioned bug won't alter that calculus). And the same applies to Fil-C: we should assume it has bugs that compromise safety until proven otherwise. Until then, in practice, Rust has much more real-world use that convincingly demonstrates its ability to realistically eliminate memory safety risks.
    - im3w1l 2mo ago
      A known bug with easily accessible proof-of-concept is quite different from a theoretical bug.

deathanatos 2mo ago

> from someone (not necessarily the Rust stdlib) implementing a safe wrapper around a particular syscall? You might call that library "nix"[1]. Many, though not all, of the bindings are safe wrappers around the underlying unsafe syscall. (The specific call of mmap from upthread, though, that one is not. I'm not sure how you would make such a call safe.) [1]: https://docs.rs/nix/latest/nix/index.html https://docs.rs/nix/latest/nix/index.html

pizlonator 2mo ago

mmap is a great example of Fil-C providing a unique level of safety. You can’t use mmap in a way that corrupts memory in Fil-C Try it. :-)