Comment by mirashii | Hacker News Reader

Comment by mirashii | Hacker News Reader

Parent Full thread

I generally agree with all of this, but I'll add a few additional remarks. Because it's come up a bunch lately, I decided to do a bunch of code review/audit of the Fil-C codebase, and I'd say while it's got a lot of good bones, there's a long way to go to being a foundation I'd be ready to build on. I've reported a few UAF's upstream, and I've got a few PRs I'll add on, but if it only took me a day or two to find some of these big holes, I'm sure there's more lurking under the surface. I'd consider it to at this point be more of an engineering demo that this approach is feasible and tractable, but not a production ready language that I'd want to ship code in.

On the muddling the discourse, I'm not on twitter and don't engage there, so I don't have an opinion on that, but I did come across https://news.ycombinator.com/item?id=49044561 recently, and I just don't see how the author can make such bold claims while examples like the one Steve provided above are still in the language. Corrupting memory in Fil-C is still easy, type confusion is still easy, intra-object overflows are still easy. Fil-C prevents a range of classes of bugs from being exploitable, but it doesn't stop the bugs from happening.

Yeah. In that thread the Fil-C author said of typescript, go and C#:

> Those languages rely on a much larger pile of YOLO C/C++ code for their runtimes and standard libraries than Fil-C does. So Fil-C is safer than those

Given the relative immaturity of Fil-C, this seems wildly wrong to me. I’m not sure how to take his claims about his runtime seriously.

[ https://news.ycombinator.com/item?id=49042736 ]

This is a simple fact. The Fil-C runtime is tiny compared to TS and C#

> The Fil-C runtime is tiny compared to TS and C#

Sure, this is a simple fact.

> So Fil-C is safer than those

This is not a simple fact that follows, and a good example of why you seem to be catching so much criticism for overly bold claims. One could state that a smaller runtime is easier to audit, and so the investment needed to reach similar levels of safety is lower. One might even argue that after similar levels of investment, that the probability that it's safer is higher. But jumping all the way from lower number of lines => safer is a simple fact is a huge leap.

I have worked on both a major JS runtime and a .NET runtime. I have fixed hundreds of security bugs in JSC. Based on that, I have no doubt that what Fil-C does is safer. Just the absence of a JIT makes it safer in a way that I don’t think is seriously debatable. Even with JIT disabled, a JS runtime has massive attack surface due to the language relying on a large native library to do anything useful, not to mention a mind boggling amount of language implementation corner cases.

By contrast Fil-C has a small number of rules and largely obviates the need for “native” code.

First of all, it’s incredible that on a HN thread about a language that isn’t C, there are 46 mentions of Fil-C! You guys are obsessed!

I make bold claims because they hold water.

- You can at worst corrupt only the capability you’re pointing to.

- intra object overflows are almost never useful for memory corruption exploits unless they let you corrupt a pointer, and Fil-C prevents that from being useful because you cannot corrupt the capability.

- the zunsafe api is basically unused. One library uses it (OpenSSL) for good reasons. This is in contrast to widespread use of the unsafe keyword in Rust, beyond just one library for a narrow purpose.

Thanks for reporting bugs. Worth noting that they require doing things that extant C code never does. It’s good to fix those, but the true threat model of any memory safe language is not to sandbox a malicious programmer, but to protect the program of a normal programmer against a malicious user

> the zunsafe api is basically unused. One library uses it (OpenSSL) for good reasons

Wait, so there are escape hatches? But… you’ve repeatedly said, many times, that there are zero escape hatches?

And now here you’re saying not only that there only are escape hatches, but there’s a good reason to use them?

Damn. Misrepresenting `unsafe{}` whilst saying your language is better because there are no escape hatches and no need for escape hatches is like… 80% of your online personality.

When can we expect the website to be updated to remove the misleading claims?

From the second paragraph of fil-c.org:

"Fil-C has no unsafe statement and only limited FFI to unsafe code."

`zunsafe_call` is a weird thing to get hung up on as an "escape hatch", considering it's just a super limited form of FFI, intentionally designed so that it's only usable for OpenSSL's use case.

> Misrepresenting `unsafe{}`

`unsafe` lets you write Rust code that violates any reasonable definition of memory safety (including Rust's definition or my definition), and it's widely used.

> Unlike other approaches to increasing the safety of C, Fil-C achieves complete memory safety with zero escape hatches.

Except there is an escape hatch, by your own admission above?

> `zunsafe_call` is a weird thing to get hung up on as an "escape hatch"

from the docs:

> unsigned long zunsafe_call(const char* symbol_name, ...);

> Performs an unsafe call to Yolo-land.

That’s just a `unsafe{ func(…) }` escape hatch

> intentionally designed so that it's only usable for OpenSSL's use case.

Cool motive, still an escape-hatch =)

Do you have the backbone to update the fil-c website to correct the record, and let the person you retweeted here[1] know that the escape hatch row is incorrect?

Or… is what everyone says about you here true?

1. https://x.com/filpizlo/status/2081765923757903940

Reply on news.ycombinator.com