pizlonator

This is all it takes to port PHP to Fil-C and according to our tests this turns all of the exploits into DoS

https://github.com/pizlonator/fil-c/blob/deluge/projects/php...

I think that the frontier labs knew what they were doing when they invested in cybersecurity starting in the spring (or maybe earlier). They knew it would create hype. They knew it fit with their narrative that they are building a dangerous thing (something they believe because it’s fun to believe in doom, because it’s a great story for investors, and because it’s not inconsistent with a moat - in fact it makes a moat via regulatory capture).

I wrote one and kept iterating by using it to fix bugs in itself

I still also use other harnesses, but mine is already at the point where I prefer it more often than not

You should totally keep working on yours. It’s a cool learning experience. And you might stumble on some good ideas that nobody else has had

> I see this as a pretty sneaky way of avoiding your security vulnerabilities going public and all the bad media exposure that goes along with it.

No, it's a way of making sure that Apple can fix the security issue and deliver the fix to customers before it can be exploited.

OP is being a big man about this

Good shit

> Well, if you write a library in the scriptc subset, it will also work in regular JavaScript runtimes, for free.

Not quite for free. You’d have to target the subset of both TS and scriptc and differential test, since there exist programs that work in both TS and scriptc but produce different output

There are lots of those kinds of exploits if the one-bit overflow gives you control of a pointer. That doesn't work in Fil-C; the pointer's capability is protected in that case.

There are many orders of magnitude fewer real exploits using intra-struct overflow without pointer control than there are exploits using vanilla logic bugs (like the programmer forgot to check the is_admin bit before proceeding to the admin privileges business logic).

So, obsessing over intra-struct overflows in a language that prevents ptr-int type confusion is missing the plot.

(Believe me, if intra-struct overflows over primitives were a big threat, I'd change the Fil-C policy.)

I confirmed, it's faster than the Go version, which is very surprising, and super impressive!

Caveats:

- I don't think it's right to say that it's "written in TypeScript". In fact, it's written in the subscript of TypeScript that scriptc supports. scriptc isn't just a subset of ts; it even diverges from ts semantics in sneaky ways to facilitate its optimizations. So, these folks have really created a TypeScript-like native language with some kind of RC-GC hybrid and a bunch of caveats. Not clear if this is any better than just creating a new language.

- Very likely that it was codeveloped with scriptc, so it's getting maximum benefit from exactly the sorts of idioms that scriptc supports well. And, I would bet they landed optimizations to scriptc specifically to get this result.

This could be useful, assuming they invest in supporting it, and you're the sort of person who needs 2x faster ts compiles.

Fil-C used to as well. It's not a fundamental limitation; it's more policy: if the programmer takes a pointer to `name`, and then uses arithmetic to get to the `is_admin` field, do we allow it or not? If we allow it, then this hypothetical example becomes a security vulnerability. If we disallow it, then a huge number of C/C++ programs stop working.

This "name overflows to is_admin" example doesn't come up in real code or real CVEs. It does come up in HN comments on Fil-C threads though.

CHERI is less compatible than Fil-C, in terms of how many changes you have to make to code to make it work, and this is an example of a policy decision that causes that result.

You're showing an example of something that could be a security bug if someone wrote that code, but you are missing the plot when it comes to memory safety and its connection to security.

What makes memory safety so important is that in C/C++, a missing bounds check on `name` gives you access to the entire heap, not simply the other fields within that allocation. Attackers aren't using missing bounds checks to look for `is_admin` fields in the same object. They're looking for a pivot to full memory control, so they can plug in their RCE exploit chain. So, the only time that attackers are looking for an intra-object overflow is if they have something like `struct { char buf[100]; void* ptr; }`, since that does lead to a pivot to full memory control. Fil-C protects that; you can't use that overflow to corrupt `ptr`'s capability.

This is why memory safety tech like MIE, MTE, and Fil-C focus on allocation granularity. If I wanted to support subobject granularity, I could; it's not a huge change to the capability model. Fil-C's first two capability models (back in late 2023, early 2024) supported subobject granularity. I'm choosing not to support it now because I understand the security implications well enough to know that it's not worth the complexity.

Fil-C started out as a macOS project. Fil-C supports Windows and macOS today via APE. Requiring recompiliation of everything is a luxury I can choose to support on Linux that results in memory safety of the whole process. If you find Fil-C useful and understand compilers, you could probably get a variant working that has FFI and then expose Windows and Mac API to it. You'd get something with a weaker safety guarantee, but no weaker than what you get today from Rust or Java.

It’s cool that this mentions Fil-C but it also undersells it. TFA also undersells CHERI. Fil-C doesn’t just “find a lot of temporal-safety” bugs. It closes off memory safety bugs (special and temporal) for exploit writers and ascribes a tight semantics to the whole language. CHERI makes some different trade offs but also gives a tight enough semantics that memory safety exploits aren’t going to work. Both CHERI and Fil-C are more comprehensive than Rust, since they attack the problem at the ABI level (and so you don’t get the problem that the protection only applies to the parts that were rewritten in the safe subset of a new language). Rust could be claimed to be better in that its compile time, but that doesn’t make a significant difference if you’re worried about the definedness of semantics or exploitability.

Good point.

Oracle stock is up today.

Refreshing to see this.

The pricing ($.68 in/$.07 cached/$2.09 out) makes it much cheaper than Kimi K3, GLM 5.3, and Meta Muse Spark 1.3. That's great!

But also much more expensive than GLM 5.3-flash and Spark 1.3 Contributor (the Meta-takes-your-data pricing of Spark 1.3).

So, I think it would have to be significantly better than GLM 5.3-flash to be worth it. GLM 5.3-flash is already very good.

The classic on the fly GC algorithm is DLG, hilariously published in two papers, because the first one had a bug. Here's the second paper: https://caml.inria.fr/pub/papers/doligez_gonthier-gc-popl94....

It's a well known algorithm. Folks who do GCs for a living know about it. The folks who work on Go are surely aware of it. I'm assuming that they do not use it for a good reason, hence my question!

Fil-C's GC (Fil's Unbelievable Garbage Collector) uses an alternative on-the-fly algorithm, which I call Phil's Concurrent Marking.

I've documented it here: https://fil-c.org/fugc

Here's the source: https://github.com/pizlonator/fil-c/blob/deluge/libpas/src/l...

Phil's Concurrent Marking differs from DLG in that it only requires a Djikstra barrier and uses a permagrey stack (something that Go used to do).

However, FUGC does clever things for coroutines (as in ucontexts, which Fil-C supports) - they are not permagrey; they only become grey if they execute. That's relevant to Go because Go moved away from permagrey stacks because of coroutine scan overheads, which the FUGC coroutine strategy might avoid.

But even if Go could not go back to permagrey, then the answer would be to use DLG, which would involve using the combined Yuasa+Dijstra barrier, which Go uses today anyway

Is there a reason why Go isn’t using on the fly GC, where there’s no STW at all?

Yes, Fil-C delivers almost all of its safety guarantees at runtime, because from a security standpoint, that's good enough.

> But we literally do already have WebP for WUFFS.

This comes down to how strong your claim is, and what point you're trying to make.

If you're saying that compiling codecs in Fil-C is not a good use of Fil-C in general, then that's wrong, because not all codecs have a WUFFS version.

If you're saying that compiling WebP with Fil-C is not a good use of Fil-C because there's a WUFFS version, then that's also wrong, because I can't use the WUFFS version in a fully memory-safe web browser, since WUFFS doesn't support Fil-ABI and nobody has written a browser where the whole transitive closure of everything that the browser uses is WUFFS or some other safe language.

On the other hand, that is possible with Fil-C. (I'm posting this comment using a memory safe browser built with Fil-C, which has WebP built with Fil-C as well as everything else down to the libc/libc++ layer built with Fil-C.)

> double-free

Double-frees are deterministic panics in Fil-C. So yeah, Fil-C catches that, and any other memroy safety violation that could be used to achieve weird execution

> any real cases where you can afford Fil-C but you can’t afford WUFFS

Anytime you already have the C or C++ code but not the WUFFS.

The main use case for the Fil-C build of webp is my memory safe web browser, which is built entirely using Fil-C (including all dependencies).

> WUFFS codec is obviously going to be a lot faster than Fil-C for similar development effort

For greater development effort. Fil-C is just C, so WUFFS is only comparable effort if that’s the only version of the codec you ever write, and in the unlikely case you are as productive in WUFFS as you would have been in C.

> it will catch a lot more than Fil-C

Like what?

Fil-C catches not just the bugs in your codec but any transitive misuse of it from other C or C++ code. So, while you might be able to pick out things Rust or WUFFS catch that Fil-C doesn’t, I can easily pick out things that Fil-C catches that nothing else can.

webp builds with fil-C just fine if you want actual memory safety.

This is great but it’s got caveats:

- assembly code. They may have been careful but it’s an escape hatch

- if it has basically any dependencies then those are likely to transitively pull in more unsafe code

His “Lost Interview” with Steve is incredible.

Listening to Steve talk about the benefits of object oriented programming is something else

> I’m not sure if you were getting at this by mentioning the ABI specifically

Fil-C dynamically links its runtime, and it's a goal to support having different runtime versions link against code compiled by different versions of the compiler, within the same ABI epoch.

Hence, the current thing where the compiler computes the allocator bucket means that the shape of allocator buckets in the thread object is part of the ABI.

> In the specialized functions, these conditionals become constant and lots of code falls away

I see. That's a key difference from Fil-C.

Fil-C's GC only specializes on size in the sense that you end up in a different allocator bucket.

> we definitely see an improvement with static calls vs computing the size class in the runtime

I don't doubt that you do.

I just find it interesting that I don't.

Not sure what the difference is

Not sure that protobuf change is the same thing

But you might be right on your overall point: on my big x86 CPU, it doesn't matter, but it might matter on some tiny arm thingy

Super interesting!

Fil-C's GC has basically always had size-specialized allocation and I've done some experiments with this so I have my own data.

As the post says, there are two potential benefits:

- Faster memory clearing when the compiler knows the size. In Fil-C, I leverage that by having LLVM emit a memset inline, so it often ends up being some SIMD crap.

- Faster size class computation.

Interestingly, the faster size class computation isn't really faster in practice. I implemented it and that's how the ABI works today, but I'm likely to move the size class computation into the runtime to simply the ABI, since repeated experiments show that there are no savings to be had there. It's super surprising, but the numbers don't lie.

Anyway, cool to see other fast non-moving GCs also finding the same sweet spot as me.

(Posted from WebKit built with Fil-C so for extra meta, I'm using the GC I describe to write this post)

This is neat.

But the benchmarks are tiny, and it’s likely that Goose was tuned on them.

So, I think I would read this as: Goose has competitive performance to C and Rust and I’ll take them at their word that it’s as memory safe as Rust

The wild thing about locks in particular is that microbenchmarks will cause you to make „optimizations” that are the opposite of what benefits real world workloads.

Super dangerous to benchmark lock performance using microbenchmarks. If you have a tiny benchmark, then you're putting the CPU and memory into a very specific and unusual state (everything is quiet other than the lock itself).

The real world story for locks is usually that you're not rage-contending 100% of the time, but that you have some contention combined with CPUs doing some real work and some real memory accesses.

What I've found is that in those more real scenarios, the locks that perform best in microbenchmarks fall apart compared to completely different and unexpected algorithms.

> easy to be safer

It took over two years and help from contributors to get to the point where WebKit could be made fully memory safe.