←back to thread

Fil's Unbelievable Garbage Collector

(fil-c.org)
597 points pizlonator | 2 comments | 05 Sep 25 00:55 UTC | HN request time: 0.001s | source
Show context
kragen ◴[05 Sep 25 04:55 UTC] No.45135095[source]▶
Hmm, Fil-C seems potentially really important; there's a lot of software that only exists in the form of C code which it's important to preserve access to, even if the tradeoffs made by conventional C compilers (accepting large risks of security problems in exchange for a small improvement in single-core performance) have largely become obsolete.

The list of supported software is astounding: CPython, SQLite, OpenSSH, ICU, CMake, Perl5, and Bash, for example. There are a lot of things in that list that nobody is likely to ever rewrite in Rust.

I wonder if it's feasible to use Fil-C to do multitasking between mutually untrusted processes on a computer without an MMU? They're making all the right noises about capability security and nonblocking synchronization and whatnot.

Does anyone have experience using it in practice? I see that https://news.ycombinator.com/item?id=45134852 reports a 4× slowdown or better.

The name is hilarious. Feelthay! Feelthay!

replies(8): >>45135151 #>>45135324 #>>45135967 #>>45137459 #>>45139406 #>>45139586 #>>45139998 #>>45140957 #
pizlonator ◴[05 Sep 25 05:05 UTC] No.45135151[source]▶
> I wonder if it's feasible to use Fil-C to do multitasking between mutually untrusted processes on a computer without an MMU?

You could. That said, FUGC’s guts rely on OS features that in turn rely on an MMU.

But you could make a version of FUGC that has no such dependency.

As for perf - 4x is the worst case and that number is out there because I reported it. And I report worst case perf because that’s how obsessive I am about realistically measuring, and then fanatically resolving, perf issues

Fact is, I can live on the Fil-C versions of a lot of my favorite software and not tell the difference

replies(5): >>45135179 #>>45135182 #>>45135319 #>>45136221 #>>45136740 #
modeless ◴[05 Sep 25 05:14 UTC] No.45135182[source]▶
A Fil-C kernel that ran the whole system in the same address space, safely, would sure be something. Getting rid of the overhead of hardware isolation could compensate for some of the overhead of the software safety checks. That was the dream of Microsoft's Singularity project back in the day.

I guess there would be no way to verify that precompiled user programs actually enforce the security boundaries. The only way to guarantee safety in such a system would be to compile everything from source yourself.

replies(2): >>45135187 #>>45136217 #
miki123211 ◴[05 Sep 25 08:17 UTC] No.45136217[source]▶
This is what IBM I[1] (AKA AS400) does I think.

Ibm I applications are compiled to a hardware-independent intermediate representation called TIMI, which the SLIC (kernel) can then compile down to machine code, usually at program installation time. As the SLIC is also responsible for maintaining system security, there's no way for a malicious user to sneak in a noncompliant program.

[1] https://en.wikipedia.org/wiki/IBM_i

replies(3): >>45136326 #>>45137324 #>>45139119 #
1. pdw ◴[05 Sep 25 11:24 UTC] No.45137324[source]▶
I always wondered how secure AS/400 actually is. The original implementation might have checked tag bits in hardware (I don't know), but the current (PowerPC) implementation relies on the compiler generating a "check tag bits" every time a pointer is dereferenced [1]. So it seems that any arbitrary code execution vulnerability would be absolutely devastating. And the "SLIC" is not a small microkernel -- it also contains the compilers, the database and other system components. It'd be hard to believe there would no exploitable bugs in there.

[1] https://www.devever.net/~hl/ppcas

replies(1): >>45137534 #
2. kragen ◴[05 Sep 25 11:58 UTC] No.45137534[source]▶
Yes, I agree.