38 ms·

Author here! :-) > What is the actual catch with Fil-C? Two things: - Not ABI compatible with Yolo-C. So, you have to recompile the whole stack. This is both

Author here! :-) > What is the actual catch with Fil-C? Two things: - Not ABI compatible with Yolo-C. So, you have to recompile the whole stack. This is both a major catch, and it is both a bug and a feature. It's a bug for obvious reasons. It's a feature because it means I'll probably be the first to have a totally usable, totally memory safe desktop environment. - In my testing, it's between 1.2x and 4x slower than Yolo-C. It uses between 2x and 3x more memory. Others have observed higher overheads in certain tests (I've heard of some things being 8x slower). How much this matters depends on your perspective. Imagine running your desktop environment on a 4x slower computer with 3x less memory. You've probably done exactly this and you probably survived the experience. So the catch is: Fil-C is for folks who want the security benefits badly enough. It's not obvious that either of these catches are fundamental. The Fil-C development philosophy is very much to get something working first, which means downscoping. That's why I didn't include Yolo-C ABI compat as a goal at all and it's also why I haven't done as many optimizations as I should have. If you look at my GitHub you'll see >20 open issues with performance optimization ideas. > In some other memory-safety circles (Rust, Zig, etc) I'm going to expect that this is going to be heavily scrutinized over the claims made by the author of Fil-C. Of course this has happened. Zig is definitely not as safe as either Rust or Fil-C, since Zig doesn't have a great story for use after free. Rust is less safe than Fil-C in practice, because Rust code uses `unsafe` a lot (>100 uses of `unsafe` in uutils and sudo-rs, for example), and Rust code ends up depending on an unsafe stack (like calling into libc, but also lots of other dependent libraries that are written in C). Fil-C doesn't have an `unsafe` statement and the dependencies are all recompiled with Fil-C.

IshKebab 11mo ago
> Zig is definitely not as safe as either Rust or Fil-C, since Zig doesn't have a great story for use after free. Have you considered making... Fil-Zig? Would it be easier to do because Zig is already fairly far ahead of C in terms of safety? > Rust is less safe than Fil-C in practice, because Rust code uses `unsafe` a lot (>100 uses of `unsafe` in uutils and sudo-rs, for example), and Rust code ends up depending on an unsafe stack (like calling into libc, but also lots of other dependent libraries that are written in C). To be fair `sudo-rs`'s usage of unsafe is all there just to interface with C code (e.g. PAM) so it isn't really sudo-rs that is "less safe", it's just that PAM isn't any safer (because it's unmodified C). Also you can use Rust without libc - https://github.com/sunfishcode/mustang https://github.com/sunfishcode/mustang - unfortunately it doesn't seem to have gained much traction which I think is a shame because glibc is a curse. Most Rust programs actually have very few C dependencies. The big exceptions are libc and OpenSSL, but I think they'll be excised eventually.
- pizlonator 11mo ago
  > To be fair `sudo-rs`'s usage of unsafe is all there just to interface with C code (e.g. PAM) so it isn't really sudo-rs that is "less safe" That's exactly my point. sudo compiled with Fil-C: uses pam compiled with Fil-C, and all of pam's dependencies are compiled with Fil-C, so the whole thing is memory safe. sudo-rs: uses pam compiled with Yolo-C, so it's not actually safe. pam is quite big and pulls in other unsafe dependencies
  - IshKebab 11mo ago
    > sudo-rs: uses pam compiled with Yolo-C, so it's not actually safe Well it is, it's just that it doesn't magically make PAM safe either. We're not disagreeing about anything technical, I just think it's slightly unfair to say Rust isn't as safe as Fil-C based on that. It is as safe; it just can't automatically make all C code safer like Fil-C can (and CHERI, etc.).
whitequark_ 11mo ago
[flagged]
Ar-Curunir 11mo ago
Almost all uses of unsafe in Rust are either for FFI, or to avoid the overhead of things like ref-counting. If you use, eg, Rc RefCell everywhere you will achieve safety without issue.
- pizlonator 11mo ago
  > Almost all uses of unsafe in Rust are either for FFI Which makes Rust less safe than Fil-C. Consider that you have a dependency like libc, PAM, openssl, or the like. In Rust: you will `unsafe` call into the unsafe versions of those libraries. Hence, even if your Rust code is safe in isolation, your program is not safe overall because you're pulling in unsafe code. In Fil-C: compile those dependencies with Fil-C, and then the whole process is safe.
  - josephg 11mo ago
    > In Fil-C: compile those dependencies with Fil-C, and then the whole process is safe. Great work on Fil-C by the way. Very technically impressive stuff! It seems like the competition for Fil-C is other garbage collected languages. Rust will always outperform Fil-C, with the caveat that rust allows unsafe blocks, raw pointers and raw C FFI. But if you’re happy to ditch performance and the ability to do bare metal systems level programming, why Fil-C over Go or C#? If you want a safer, less convenient dialect of rust, that also exists. Just don’t use or depend on any unsafe code in your program. (There are 3rd party tools to check this). More and more C libraries are getting pure rust ports these days. It’s increasingly rare to actually need to pull in C libraries at all. Sticking to safe rust is a bit inconvenient - but I suspect so is using fil-c. I suppose with fil-C you can use any libraries you want, you’ve just gotta recompile them. That’s cool! Rust has a bunch of unsafe code in std, so you’re still at risk of a bug there causing safety problems. But the same is true of Fil-C. I could definitely see myself reaching for Fil-C when running legacy code. It’d be nice if there was a way to use fil-C to protect my rust program from memory bugs in C dependencies. But I can think of dozens of ways why that would be tricky to pull off. Also I’m curious - can Fil-C protect against threading bugs like rust can? Rust has Send & Sync traits to mark which objects can be safely shared between threads. I can’t think of a way to do that in an automated way without help from the programmer.

IshKebab 11mo ago

> Zig is definitely not as safe as either Rust or Fil-C, since Zig doesn't have a great story for use after free. Have you considered making... Fil-Zig? Would it be easier to do because Zig is already fairly far ahead of C in terms of safety? > Rust is less safe than Fil-C in practice, because Rust code uses `unsafe` a lot (>100 uses of `unsafe` in uutils and sudo-rs, for example), and Rust code ends up depending on an unsafe stack (like calling into libc, but also lots of other dependent libraries that are written in C). To be fair `sudo-rs`'s usage of unsafe is all there just to interface with C code (e.g. PAM) so it isn't really sudo-rs that is "less safe", it's just that PAM isn't any safer (because it's unmodified C). Also you can use Rust without libc - https://github.com/sunfishcode/mustang https://github.com/sunfishcode/mustang - unfortunately it doesn't seem to have gained much traction which I think is a shame because glibc is a curse. Most Rust programs actually have very few C dependencies. The big exceptions are libc and OpenSSL, but I think they'll be excised eventually.

pizlonator 11mo ago
> To be fair `sudo-rs`'s usage of unsafe is all there just to interface with C code (e.g. PAM) so it isn't really sudo-rs that is "less safe" That's exactly my point. sudo compiled with Fil-C: uses pam compiled with Fil-C, and all of pam's dependencies are compiled with Fil-C, so the whole thing is memory safe. sudo-rs: uses pam compiled with Yolo-C, so it's not actually safe. pam is quite big and pulls in other unsafe dependencies
- IshKebab 11mo ago
  > sudo-rs: uses pam compiled with Yolo-C, so it's not actually safe Well it is, it's just that it doesn't magically make PAM safe either. We're not disagreeing about anything technical, I just think it's slightly unfair to say Rust isn't as safe as Fil-C based on that. It is as safe; it just can't automatically make all C code safer like Fil-C can (and CHERI, etc.).

whitequark_ 11mo ago

[flagged]

Ar-Curunir 11mo ago

Almost all uses of unsafe in Rust are either for FFI, or to avoid the overhead of things like ref-counting. If you use, eg, Rc RefCell everywhere you will achieve safety without issue.

pizlonator 11mo ago
> Almost all uses of unsafe in Rust are either for FFI Which makes Rust less safe than Fil-C. Consider that you have a dependency like libc, PAM, openssl, or the like. In Rust: you will `unsafe` call into the unsafe versions of those libraries. Hence, even if your Rust code is safe in isolation, your program is not safe overall because you're pulling in unsafe code. In Fil-C: compile those dependencies with Fil-C, and then the whole process is safe.
- josephg 11mo ago
  > In Fil-C: compile those dependencies with Fil-C, and then the whole process is safe. Great work on Fil-C by the way. Very technically impressive stuff! It seems like the competition for Fil-C is other garbage collected languages. Rust will always outperform Fil-C, with the caveat that rust allows unsafe blocks, raw pointers and raw C FFI. But if you’re happy to ditch performance and the ability to do bare metal systems level programming, why Fil-C over Go or C#? If you want a safer, less convenient dialect of rust, that also exists. Just don’t use or depend on any unsafe code in your program. (There are 3rd party tools to check this). More and more C libraries are getting pure rust ports these days. It’s increasingly rare to actually need to pull in C libraries at all. Sticking to safe rust is a bit inconvenient - but I suspect so is using fil-c. I suppose with fil-C you can use any libraries you want, you’ve just gotta recompile them. That’s cool! Rust has a bunch of unsafe code in std, so you’re still at risk of a bug there causing safety problems. But the same is true of Fil-C. I could definitely see myself reaching for Fil-C when running legacy code. It’d be nice if there was a way to use fil-C to protect my rust program from memory bugs in C dependencies. But I can think of dozens of ways why that would be tricky to pull off. Also I’m curious - can Fil-C protect against threading bugs like rust can? Rust has Send & Sync traits to mark which objects can be safely shared between threads. I can’t think of a way to do that in an automated way without help from the programmer.