Earlier quoted context omitted.
A computer spends the vast majority of its time and memory in userspace, so this tradeoff isn't as bad as it sounds.
The benefit also isn’t as big as you might expect. Most of Linux’s recently found security vulnerabilities were due to ToC/ToU bugs. Fil-C would not magically fix these problems. It would sometimes be a good trade off, for some users. But I don’t think many regular users would choose to pay this cost.
Fil-C: Garbage In, Memory Safety Out [video]
131–140 of 190 posts
Re: Fil-C: Garbage In, Memory Safety Out [video]
#132I was amazed by the presentation all the way up until 33:47, where the buggy program compiles and only errors out when the invalid access is executed. So apparently Fil-C enforces memory safety dynamically at run-time , rather than detecting these bugs at compile-time . A new language designed around memory safety, such as Rust, can reject large and important classes of memory-safety bugs at compile-time. Rust does n…
Rust has compile time checks to enforce some safety. In comparison Fil-C is a lot more memory safe, it's more comparable to being a software implementation of CHERI.
Unfortunately it comes with downsides: runtime performance, runtime enforcement, granular safety (the safety is around allocations).
It also comes with huge upsides: you can run C/C++ with little to no code changes. Imagine compiling nginx and the associated system libraries with Fil-C, the performance hit is probably acceptable and now the web server is memory safe.
Rust probably provides enough memory safety (even if it is not complete safety) in most circumstances though.
Re: Fil-C: Garbage In, Memory Safety Out [video]
#133Earlier quoted context omitted.
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.
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.
It is possible, check MaulingMonkeys' comment upthread.
Re: Fil-C: Garbage In, Memory Safety Out [video]
#134Ha, looking through the links dang added, I came upon something I wrote back in December I gave (somewhat arbitrarily) the example that safe Rust is OK with a 64-bit pointer (on a modern PC for example) having the value made by the UTF-8 text "LAUGHING". That's 8 bytes, 8 bytes is 64 bits, it fits perfectly. Of course I point out, unsafe Rust, which is allowed to dereference pointers, must never dereference this LAUG…
How does it do that? When the 64-bit pointer is actually a pointer, does it mangle it into something that is certainly not UTF-8 (e.g. changing its top byte to 0xC0, and assuming that bits 56-63 are the same as bits 48-55, or something like that)?
Now, by pointing only at memory aligned to 4 bytes, the way a 32-bit integer would be on a typical machine, the bottom two bits of the pointer are always zero. So, we ask for such 4-byte aligned pointers when allocating memory to point at, most allocators actually never give out smaller alignments anyway because they cause problems in C but we've told the allocator our requirement so even if it could it won't give out unaligned pointers.
Finally we need to re-arrange our pointer so that those two zero bits are in the right place to put a UTF-8 continuation marker. In Rust this is legal safe code, the map_addr method on a pointer is allowed to twiddle with a pointer's address bits (on typical platforms, all of them) and so long as your transform is reversible (which this one is) it will work correctly when you twiddle the pointer back and dereference that pointer in unsafe Rust.
Re: Fil-C: Garbage In, Memory Safety Out [video]
#135Earlier quoted context omitted.
also: why not use fil-c to improve cython, and the ffi.
If you want a slow, garbage collected language in the Python ecosystem, why not just write Python?
Re: Fil-C: Garbage In, Memory Safety Out [video]
#136Earlier quoted context omitted.
The whole point of Fil-C is that it is fast enough to consider using in production for some applications while still guaranteeing memory safety. We already have ASAN and Valgrind and other tools for development purposes, that's not what Fil-C is targeting.
So Fil-C is competing with Go, C#, typescript and Python. If I’m writing a greenfield project where “bare metal” performance isn’t needed, why would anyone choose Fil-C over a more mature GC language? C is more verbose and more error prone than Go and C#. It has worse tooling. It’s missing decades of language features. C isn’t properly cross platform. There’s no package manager. The “standard library” isn’t fully sta…
Or you could write a library that works for Fil-C and C without writing the library twice.
Re: Fil-C: Garbage In, Memory Safety Out [video]
#137Earlier quoted context omitted.
Do you want your kernel to be 2x slower and use 4x as much memory?
A computer spends the vast majority of its time and memory in userspace, so this tradeoff isn't as bad as it sounds.
(Left as an exercise for the reader)
Re: Fil-C: Garbage In, Memory Safety Out [video]
#138Earlier quoted context omitted.
>I've long faulted Rust's use of Result over exceptions Why?
Not the person you're asking, but result types pessimize code more, add register pressure, use more icache for largely dead code, etc. They're arguably noisier at the source level too. That said, I've spent too much of my life chasing implicit control flow to accept exceptions. Heck, C++'s "noexcept" is a strong argument against exceptions all by itself.
Yes. This is why unchecked exceptions are annoying. Checked exceptions are a „failed experiment“ anyway.
A result type (or even Go‘s err) with forced error handling meaningfully increases the robustness of a program in my experience.
Re: Fil-C: Garbage In, Memory Safety Out [video]
#139I was amazed by the presentation all the way up until 33:47, where the buggy program compiles and only errors out when the invalid access is executed. So apparently Fil-C enforces memory safety dynamically at run-time , rather than detecting these bugs at compile-time . A new language designed around memory safety, such as Rust, can reject large and important classes of memory-safety bugs at compile-time. Rust does n…
I thought it was very obvious throughout the video what was happening... Rust has compile time checks to enforce some safety. In comparison Fil-C is a lot more memory safe, it's more comparable to being a software implementation of CHERI. Unfortunately it comes with downsides: runtime performance, runtime enforcement, granular safety (the safety is around allocations). It also comes with huge upsides: you can run C/C…
Sure, Fil-C prevents the bug from possibly being exploited, which is a huge improvement. But crashing can be a DoS attack, and if running a mission-critical system, it might not be an acceptable outcome.
I just feel the already very good presentation could have been made much better if it had put more weight on explaining these trade-offs.
Re: Fil-C: Garbage In, Memory Safety Out [video]
#140Earlier quoted context omitted.
> Also, Fil-C’s guarantee that it will panic on OOB or if a race goes badly Fil-C as currently implemented does not guarantee panics on unsafe accesses due to races. You dodge the problem by using a private definition of safety under data race that permits program executions nobody would expect.
I define memory safety in terms of capabilities, which is a mainstream definition. The worst that can happen in a race is that you read or write an object that would have been accessible even in the absence of races. The thing that makes races hard to debug in C or C++ is memory corruption; that doesn’t happen in Fil-C