Rendered at 04:10:19 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
QuaternionsBhop 14 minutes ago [-]
This would also mean that you wouldn't need unsafe{} to call into the Fil-C ffi. The majority of unsafe{} in (non pure-rust) cargo dependencies is calling C ffi. Rust + Fil-C is a great match that fills a particular niche, I'd love to see it happen.
KateLawson 19 minutes ago [-]
Any reason why you don't use clang's `-fbounds-safety`? It offers ABI compatibility and incremental adoption. The author of Fil-C worked on it also :-)
Apparently this was done intentionally. The rationale given is that we don't want to allow non-safe C to be used in fil-C programs. Fair enough.
But why should we prevent fil-C programs to be used from Rust (or C, for that matter)?
I don't understand much about compilers, but I guess allowing one would also allow the other? i.e. it's not possible to make fil-C ABI compatible with C (so that it can be more easily called), while also not letting you use call C from it?
ameliaquining 2 hours ago [-]
You're looking too much at the complete memory safety goal; the important part here is the interop non-goal. Designing a foreign function interface between Fil-C and regular C, in a way that upholds both languages' expectations about the environment the code's running in, is a very difficult problem and nobody seems to have much of an idea of how such a thing could work.
I worry that this same problem will doom the extern "Fil-C" idea that this post advocates. Zig is not really an encouraging precedent because Zig's proposed memory-safe mode adds runtime checks to everything just like Fil-C does, whereas the post author wants to avoid those checks for Rust code that's already statically known to be memory-safe. That said, it's possible I'm missing something.
Georgelemental 2 hours ago [-]
It's also because Fil-C calls need to carry along a bunch of extra information, to support the safety checks
sheepscreek 2 hours ago [-]
Yes and AFAIK any fil-C program needs to be linked against fil-C compiled libraries, such as libc/musl/etc. I too would like to know what other challenges exist in making this process more automated.
pizlonator 2 hours ago [-]
Correct
pornel 2 hours ago [-]
There is a solution that Mozilla uses in prod for legacy C codecs:
It's not a replacement for Fil-C's role as a precise ASAN/Valgrind, but it works great if you want to call a C library without letting it freely spray caller's memory.
pizlonator 2 hours ago [-]
Yeah rlbox is great.
Fil-C is more precise than valgrind or asan. Valgrind and asan will allow a buggy access (like an OOB) to succeed if the resulting address is valid at all - which is useless from a security enforcement perspective since clobbering valid addresses is what the attacker is trying to do.
Fil-C only allows an access to succeed if it’s in bounds of that pointer’s capability. That is a useful level of precision for security, since it prevents the attacker from clobbering the addresses of their choice.
Wleddzig 3 hours ago [-]
[flagged]
ameliaquining 2 hours ago [-]
Can you please link to specific false statements and explain why they're false?
https://clang.llvm.org/docs/BoundsSafety.html#overview
But it’s strictly less safe than either Fil-C or Rust since it only protects bounds
https://fil-c.org/runtime
Apparently this was done intentionally. The rationale given is that we don't want to allow non-safe C to be used in fil-C programs. Fair enough.
But why should we prevent fil-C programs to be used from Rust (or C, for that matter)?
I don't understand much about compilers, but I guess allowing one would also allow the other? i.e. it's not possible to make fil-C ABI compatible with C (so that it can be more easily called), while also not letting you use call C from it?
I worry that this same problem will doom the extern "Fil-C" idea that this post advocates. Zig is not really an encouraging precedent because Zig's proposed memory-safe mode adds runtime checks to everything just like Fil-C does, whereas the post author wants to avoid those checks for Rust code that's already statically known to be memory-safe. That said, it's possible I'm missing something.
https://rlbox.dev/
It's not a replacement for Fil-C's role as a precise ASAN/Valgrind, but it works great if you want to call a C library without letting it freely spray caller's memory.
Fil-C is more precise than valgrind or asan. Valgrind and asan will allow a buggy access (like an OOB) to succeed if the resulting address is valid at all - which is useless from a security enforcement perspective since clobbering valid addresses is what the attacker is trying to do.
Fil-C only allows an access to succeed if it’s in bounds of that pointer’s capability. That is a useful level of precision for security, since it prevents the attacker from clobbering the addresses of their choice.