8 ms·

I guess to get on board with this, it is my understanding you have to accept the premise of a Garbage Collector in the runtime?

kragen 1y ago
So far we haven't found a viable alternative; CHERI has holes in its temporal integrity guarantees.
- Findecanor 1y ago
  Both Fil-C and CHERI rely on a concurrent GC/a GC-like task to find and invalidate all pointers to free()'d memory objects (in "quarantine") before putting them back into the memory pool. The difference is that because Fil-C has bounds in each object's header, it only has to nullify it to remove access whereas in CHERI a quarantined object can still be accessed through any pointer that hasn't been invalidated yet. I've seen discussions on adding an additional memory tag to CHERI for memory in quarantine, but I dunno what is best. Fil-C relies on the compiler being trusted whereas CHERI does not. If we do, then perhaps we could come up with a hardware-accelerated system that is more lightweight than either.
  - kragen 1y ago
    I didn't know this, but aside from the GC, Fil-C promptly revokes capabilities to freed objects, not relying on a concurrent task to do it eventually; CHERI cannot AFAIK.
  - vacuity 1y ago
    Implementations can always get better, but I think the only categorical (if even that) improvement that will arise depends on careful program design/implementation; that is, reducing the scope and number of capabilities and providing semantic information on capability usage. Fil-C and CHERI do an admirable job of maximizing backwards compatibility and even allowing incremental improvements, but I think it's time that programmers bought into capabilities too.
  - Findecanor 1y ago
    Follow-up: CHERioT (Microsoft's RV32E-based variation for embedded systems) does have a quarantine tag bit per 64-bit word of memory. The base address' bit is checked on capability load by the CPU's "Load filter".
    - kragen 11mo ago
      Thank you!
mbrock 1y ago
Note that it is a garbage collector designed and implemented by one of the most experienced GC experts on earth. He previously designed and implemented WebKit's state of the art concurrent GC, for example. So—yes, but don't dismiss it too quickly.
- simonask 1y ago
  If that's all you need, the state of the art is very available already through the JVM and the .NET CLR, as well as a handful others depending on your use case. Most of those also come with decent languages, and great facilities to leverage the GC to its maximum. But GCs aren't magic and you will never get rid of all the overhead. Even if the CPU time is not noticeable in your use case, the memory usage fundamentally needs to be at least 2-4x the actual working set of your program for GCs to be efficient. That's fine for a lot of use cases, especially when RAM isn't scarce. Most people who use C or C++ or Rust have already made this calculation and deemed the cost to be something they don't want to take on. That's not to say Fil-C isn't impressive, but it fills a very particular niche. In short, if you're bothering with a GC anyway, why wouldn't you also choose a better language than C or C++?
  - mbrock 1y ago
    I don't understand the need to hammer in the point that Fil-C is only valuable for this tiny, teeny, irrelevant microscopic niche, while not even talking about what the niche is? To be clear, the niche is rebuilding your entire GNU/Linux userland with full memory safety and completely acceptable performance, tomorrow, without rewriting anything, right? Is this such a silly little idiosyncratic hobby?
    - conradev 1y ago
      I am a member of this niche – thank you for the flake!! https://discourse.nixos.org/t/radically-improving-nix-nixos-security-with-fil-c/71476 https://discourse.nixos.org/t/radically-improving-nix-nixos-...
    - simonask 1y ago
thomasmg 1y ago
The author of Fil-C does have some ideas to avoid a garbage collector [1], in summary: Use-after-free at worst means you might see an object of the same size, but you can not corrupt data structures (no pointer / integer confusion). This would be more secure than standard C, but less secure than Fil-C with GC. [1] https://x.com/filpizlo/status/1917410045320650839 https://x.com/filpizlo/status/1917410045320650839

kragen 1y ago

So far we haven't found a viable alternative; CHERI has holes in its temporal integrity guarantees.

Findecanor 1y ago
Both Fil-C and CHERI rely on a concurrent GC/a GC-like task to find and invalidate all pointers to free()'d memory objects (in "quarantine") before putting them back into the memory pool. The difference is that because Fil-C has bounds in each object's header, it only has to nullify it to remove access whereas in CHERI a quarantined object can still be accessed through any pointer that hasn't been invalidated yet. I've seen discussions on adding an additional memory tag to CHERI for memory in quarantine, but I dunno what is best. Fil-C relies on the compiler being trusted whereas CHERI does not. If we do, then perhaps we could come up with a hardware-accelerated system that is more lightweight than either.
- kragen 1y ago
  I didn't know this, but aside from the GC, Fil-C promptly revokes capabilities to freed objects, not relying on a concurrent task to do it eventually; CHERI cannot AFAIK.
- vacuity 1y ago
  Implementations can always get better, but I think the only categorical (if even that) improvement that will arise depends on careful program design/implementation; that is, reducing the scope and number of capabilities and providing semantic information on capability usage. Fil-C and CHERI do an admirable job of maximizing backwards compatibility and even allowing incremental improvements, but I think it's time that programmers bought into capabilities too.
- Findecanor 1y ago
  Follow-up: CHERioT (Microsoft's RV32E-based variation for embedded systems) does have a quarantine tag bit per 64-bit word of memory. The base address' bit is checked on capability load by the CPU's "Load filter".
  - kragen 11mo ago
    Thank you!

mbrock 1y ago

Note that it is a garbage collector designed and implemented by one of the most experienced GC experts on earth. He previously designed and implemented WebKit's state of the art concurrent GC, for example. So—yes, but don't dismiss it too quickly.

simonask 1y ago
If that's all you need, the state of the art is very available already through the JVM and the .NET CLR, as well as a handful others depending on your use case. Most of those also come with decent languages, and great facilities to leverage the GC to its maximum. But GCs aren't magic and you will never get rid of all the overhead. Even if the CPU time is not noticeable in your use case, the memory usage fundamentally needs to be at least 2-4x the actual working set of your program for GCs to be efficient. That's fine for a lot of use cases, especially when RAM isn't scarce. Most people who use C or C++ or Rust have already made this calculation and deemed the cost to be something they don't want to take on. That's not to say Fil-C isn't impressive, but it fills a very particular niche. In short, if you're bothering with a GC anyway, why wouldn't you also choose a better language than C or C++?
- mbrock 1y ago
  I don't understand the need to hammer in the point that Fil-C is only valuable for this tiny, teeny, irrelevant microscopic niche, while not even talking about what the niche is? To be clear, the niche is rebuilding your entire GNU/Linux userland with full memory safety and completely acceptable performance, tomorrow, without rewriting anything, right? Is this such a silly little idiosyncratic hobby?
  - conradev 1y ago
    I am a member of this niche – thank you for the flake!! https://discourse.nixos.org/t/radically-improving-nix-nixos-security-with-fil-c/71476 https://discourse.nixos.org/t/radically-improving-nix-nixos-...
  - simonask 1y ago

thomasmg 1y ago

The author of Fil-C does have some ideas to avoid a garbage collector [1], in summary: Use-after-free at worst means you might see an object of the same size, but you can not corrupt data structures (no pointer / integer confusion). This would be more secure than standard C, but less secure than Fil-C with GC. [1] https://x.com/filpizlo/status/1917410045320650839 https://x.com/filpizlo/status/1917410045320650839