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

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.

Good shit

Comments URL: https://news.ycombinator.com/item?id=50201562

Points: 1

# Comments: 0

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 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.)

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.

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.

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.

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.

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

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

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.

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