Rendered at 05:31:31 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Panzerschrek 41 minutes ago [-]
Extern "fil-C" can't be compatible with Rust code or something similar. It requires a metadata block attached to each allocation. So, if a memory block has been allocated in Rust and a pointer to it is passed to a fil-C function, it can't access it correctly. The only way to allow such cross-langauge-and-abi calls is to compile Rust code itself like fil-C, which requires doubled memory consumption, expensive runtime checks and GC overhead.
pornel 3 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 3 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.
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?
Georgelemental 4 hours ago [-]
It's also because Fil-C calls need to carry along a bunch of extra information, to support the safety checks
sheepscreek 3 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.
ameliaquining 43 minutes ago [-]
What precisely do you mean by "this process"? The kind of linking that Fil-C supports is pretty different from what the blog post proposes.
pizlonator 3 hours ago [-]
Correct
ameliaquining 3 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.
KateLawson 2 hours 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 :-)
But it’s strictly less safe than either Fil-C or Rust since it only protects bounds
QuaternionsBhop 2 hours 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.
creatonez 1 hours ago [-]
> [...] instead of accidentally linking ordinary C into it
Out of curiosity. If you really needed to, could a language speak both the C ABI and the Fil-C ABI? As I understand Fil-C itself can't do this without having Python-like FFI overhead, but maybe a different compiler implementation could?
throwaway27448 1 hours ago [-]
Wouldn't this abandon the entire premise that fil-c binaries will crash rather than corrupt?
chubot 1 hours ago [-]
(revised comment)
Hm on first reading I was confused by the extern "fil-c" framing -- that seems to imply a bridge between C and Fil-C, which introduces some nasty language/runtime inter-op issues.
But I like this part
I want a Rust FFI that speaks the Fil-C ABI. ... We could use Rust for compile-time safety and then pay a performance penalty for using C.
nnevatie 47 minutes ago [-]
Reading this my slop-sense is tingling.
Wleddzig 4 hours ago [-]
[flagged]
ameliaquining 3 hours ago [-]
Can you please link to specific false statements and explain why they're false?
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.
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://clang.llvm.org/docs/BoundsSafety.html#overview
But it’s strictly less safe than either Fil-C or Rust since it only protects bounds
Out of curiosity. If you really needed to, could a language speak both the C ABI and the Fil-C ABI? As I understand Fil-C itself can't do this without having Python-like FFI overhead, but maybe a different compiler implementation could?
Hm on first reading I was confused by the extern "fil-c" framing -- that seems to imply a bridge between C and Fil-C, which introduces some nasty language/runtime inter-op issues.
But I like this part
I want a Rust FFI that speaks the Fil-C ABI. ... We could use Rust for compile-time safety and then pay a performance penalty for using C.