6 ms·
He claims that all syscalls are safe because they're implemented by his custom libc, but that libc then calls out to the system libc, where the system calls are
by wasmperson 3mo ago
He claims that all syscalls are safe because they're implemented by his custom libc, but that libc then calls out to the system libc, where the system calls are unsafe. He then claims that this is unlike rust, where making a syscall is unsafe. If you stick to the rust standard library in the same way that fil-c programs stick to the fil-c standard library, then all of your rust "system calls" are safe, too.
Someone in the audience also pointed out that a tool like this could be used to compile rust programs, not just C programs, in which case it's odd to hear Fil-C repeatedly framed as a language in opposition to rust rather than as a tool which might complement it.
- cypherpunk666 3mo agoindeed, the ideas could be used more widely. fil-c runs on linux. what if linux ran on fil-c?
- josephg 3mo agoDo you want your kernel to be 2x slower and use 4x as much memory?
- wavemode 3mo agoA computer spends the vast majority of its time and memory in userspace, so this tradeoff isn't as bad as it sounds.
- avadodin 3mo agoYou can run your Fil–C userland on provably–secure seL4. (Left as an exercise for the reader)
- josephg 3mo agoIf you’re using SeL4, userland processes are already strictly sandboxed. There’s still some benefit to Fil-C, since the added memory safety would make it much more difficult to take over a process. But the blast radius of a compromised program in SeL4 is much smaller because of the capability model.
- josephg 3mo agoThe 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.
- cypherpunk666 3mo agoa fun exercise is to ask an LLM how it might be applied.
- yjftsjthsd-h 3mo agoI was under the impression that fil-c's memory management (gc?) wouldn't work on a kernel? Be sweet if you could, ofc
- brabel 3mo agoThis is a myth that seems to never die. OS kernels can and have been written in GC languages. Watch the video maybe? The whole presentation was running on a distro fully compiled with FillC.
- yjftsjthsd-h 3mo agoThe video has a slide which says, > I'm running on an OS where the entire userland is compiled with Fil-C/C++ (emphasis mine) Looking up https://fil-c.org/pizlix https://fil-c.org/pizlix , that says, > The kernel is compiled with Yolo-C. So that you can compile the kernel, a copy of GCC is installed in /yolo/bin/gcc. Where do you see anything saying the Linux (the kernel) can be built with Fil-C?
- brabel 3mo agoOk, I stand corrected: only the kernel userland was compiled with Fil-C. However, I don't see why the full Linux kernel could not be compiled with Fil-C. It would be nice if Fil himself could explain what limitations there are, but the documentation does not list missing C/C++ features as far as I know, it only says it's "fanatically compatible" which I take to mean mostly everything should work?! But to my point in general, here's a osdev.org wiki explaining how high level languages can and have been used for OS development (with the caveat that some Assembly code is required, which I believe is also true of kernels written in C): https://wiki.osdev.org/Languages https://wiki.osdev.org/Languages
- doctorpangloss 3mo agowhat if fil-c could draw pelicans?
- LoganDark 3mo ago> Someone in the audience also pointed out that a tool like this could be used to compile rust programs, not just C programs, in which case it's odd to hear Fil-C repeatedly framed as a language in opposition to rust rather than as a tool which might complement it. You can combine both approaches for sure, but that doesn't change that they are indeed separate approaches. One (Rust) intends to characterize and prevent undefined behavior at compile time, and another (Fil-C) intends to make undefined behavior impossible at runtime, as evidenced by decisions like (for example) making unsafe usage of setjmp/longjmp safe. You could sort of achieve "safety-in-depth" by combining both approaches, but Rust prefers to prevent all undefined behavior statically, and Fil-C prefers to focus on dynamic approaches. They have real differences, so that's probably what comes off as "oppositional"
- raggi 3mo agoThis presentation wasn’t too bad in terms of us vs theming, but in general throughout the lifetime of the project there’s been a strong us vs them rhetoric. I think it’s working as a marketing tactic to some extent but there are better, albeit harder ways to market the thing.
- LoganDark 3mo agoRust generally invites us vs them everywhere because it's just so ambitious and attractive (to some). Fil-C probably receives questions all the time about why they don't just do X or Y that Rust does. Maybe they end up supporting their position against that type of pressure and it looks like they're opposing Rust when all they're doing is justifying themselves.
- pjmlp 3mo agoBecause by making Cyclone's ideas mainstream, which AT&T started alongside Cornell University, the C and C++ devs that so far felt safe from all those RC/GC languages, now had an actually problem as companies started paying attention and embracing the language's ideas, even extending the type system of existing RC/GC languages. Thus anyone that identifies themselves with the programming language they work with, gets dragged into a us vs them discussion.
- cypherpunk666 3mo agoalso: why not use fil-c to improve cython, and the ffi.
- FuckButtons 3mo agothe only reason to use cython (in my experience) is to write quick numpy extensions without a tonne of extra baggage from having a complete compiled extension in C/C++/Rust. Often, you explicitly want to avoid the compiler offering you any kinds of additional checking because you want to get maximum throughput. Most of the functions I’ve written in cython explicitly opt out of bounds checking etc since the memory access is sequential and bounded by construction and very obvious when you mess things up by writing simple unit tests. Given that, it doesn’t seem useful to me to add any kind of memory safety as additional overhead. YMMV I mostly do scientific computing and signal processing.
- josephg 3mo agoIf you want a slow, garbage collected language in the Python ecosystem, why not just write Python?
- cypherpunk666 3mo agoyou would. python and ffi would have runtime sanity checks a la fil-c. better error messages too. ask your favorite LLM how it would look.
- quotemstr 3mo agoBoth Rust and Fil-C have unsafe blocks, but in Fil-C latter system, only Pizlo gets to write them. Why am I not filled with confidence?
- pizlonator 3mo agoFil-C has no unsafe blocks
- modeless 3mo agoRust doesn't runtime validate that your usage of syscalls is memory safe, while Fil-C does. For example you can call mmap in Fil-C and it is still guaranteed to be memory safe, while in Rust you can easily violate memory safety by calling mmap. This seems like an unambiguous improvement to me. This is as memory safe as it is possible to be on a system with a kernel that is not memory safe. Adding Fil-C-like runtime checks to Rust is definitely an interesting direction.
- quotemstr 3mo agoOkay, let me know when I can call process_vm_writev or ptrace and have Fil-C verify safety properties on the result.
- jcranmer 3mo agoDon't forget reads and writes of /proc/self/mem! :-)
- modeless 3mo agoBetter include Rowhammer too. Maybe Fil-C should run a test and refuse to start on any system with bad RAM or unpatched CPU errata. It could also monitor the voltage to protect against undervolting attacks. And you'll need some cosmic ray shielding too. Of course I'm kidding, but it is absolutely the case that if you truly care about safety you need to consider more than the program source code and binary, but also the environment, including kernel and hardware. The user doesn't care if their web browser got hacked via stack buffer underflow or /dev/exynos-mem or Rowhammer; the result is the same.
- pizlonator 3mo agoSure all of those are escape hatches that work against any memory safety tech. Point is, Fil-C goes further than any other memory safety tech in terms of what it guards
- pizlonator 3mo agoCustom libc does not call to system libc. “Custom” and “system” aren’t the terms I use; I say user libc and you libc (because they are basically the same libc - either both are musl or both are glibc). User libc calls to the Fil-C runtime, which filters syscalls, and those filtered syscalls are made via yolo libc. Hence, a Fil-C program is memory safe down to the syscalls and syscalls cannot be used to escape the protections (unless you do weird stuff with /proc)
- wasmperson 3mo agoThe way I see it, as far as memory safety is concerned that's just framing. Both Fil-C and Rust have a boundary below which the unsafe lives. If Fil-C is only safer than rust when you don't pass the `-F unsafe_code` argument to rustc then IMO "safer" in this case is somewhat of an empty claim.
- flumpcakes 3mo agoI think you should watch the linked presentation, it will show how it is "safer" than rust. Unfortunately there are performance implications, but fil-c seems fast enough to go into production for many workloads and surprisingly needs very little code changes to existing C/C++ projects which is a huge benefit.
- josephg 3mo agoI think Fil-C might make a lot of sense for running legacy C or C++ codebases. But for new code, it seems like it’s trying to compete with other GC languages. Take away C’s performance advantages and I don’t know why anyone would use it. Fil-C: Combining the ergonomics of C with the performance of Python!
- pizlonator 3mo agoFil-C is much faster than Python And it’s fun to write new code in.
- 3mo ago
- mort96 3mo agoIn Rust, there are safe syscall wrappers, and then there's the unsafe general `syscall` function: https://docs.rs/libc/latest/libc/fn.syscall.html https://docs.rs/libc/latest/libc/fn.syscall.html. If I'm understanding correctly, it's this general syscall function that's safe in Fil-C.