Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Notes by djb on using Fil-C

cr.yp.to

Post reply on HN
Print view View original

161–170 of 263 posts

Re: Notes by djb on using Fil-C

#161

Post by quotemstr »

gpm wrote: post #150
sheepscreek wrote: post #149

I’m glad Phil’s work is finally getting the recognition it deserves. There may be useful takeaways here for Rust’s “unsafe” mode - particularly for applications willing to accept the extra burden of statically linking Fil-C-compiled dependencies. Best of both worlds!

> particularly for applications willing to accept the extra burden of statically linking Fil-C-compiled dependencies. Best of both worlds! As near as I can tell Fil-C doesn't support this, or any other sort of FFI, at all. Nor am I sure FFI would even make sense, it seems like an approach that has to take over the entire program so that it can track pointer provenance.

He could add an API to mint a capability out of thin air. It could even be done out of process.

In fact, I think Fil-C and CHERI could implement 90% the same programmer-level API!

Re: Notes by djb on using Fil-C

#162

Post by quotemstr »

silotis wrote: post #152
thesz wrote: post #146

Earlier quoted context omitted.

> best case scenario since there is very little memory management involved and runtime is dominated by computation in tight loops. This describes most C programs and many, if not most, C++ programs. Basically, this is how C/C++ code is being written, by avoiding memory management, especially in tight loops.

This depends heavily on what problem domain you're talking about. For example, a DBMS is necessarily going to shuffle a lot of data into and out of memory.

It depends. Consider DuckDB or another heavily vectorized columnar DB: there's a big part of the system (SQL parser, storage chunk manager, etc.) that's not especially performance-sensitive and a set of tiny, fast kernels that do things like predicate-push-down-based full table scans, ART lookups, and hash table creation for merge joins. DuckDB is a huge pile of C++. I don't see a RIIR taking off before AGI.

But you know what might work?

Take current DuckDB, compile it with Fil-C, and use a new escape hatch to call out to the tiny unsafe kernels that do vectorized high-speed columnar data operations on fixed memory areas that the buffers safe code set up on behalf of the unsafe kernels. That's how it'd probably work if DuckDB were implemented in Rust today, and it's how it could be made to work with Fil-C without a major rewrite.

Granted, this model would require Fil-C's author to become somewhat less dogmatic about having no escape hatches at all whatsoever, but I suspect he'll un-harden his heart as his work gains adoption and legitimate use-cases for an FFI/escape hatch appear.

Re: Notes by djb on using Fil-C

#163

Post by hedgehog »

gpm wrote: post #150
sheepscreek wrote: post #149

I’m glad Phil’s work is finally getting the recognition it deserves. There may be useful takeaways here for Rust’s “unsafe” mode - particularly for applications willing to accept the extra burden of statically linking Fil-C-compiled dependencies. Best of both worlds!

> particularly for applications willing to accept the extra burden of statically linking Fil-C-compiled dependencies. Best of both worlds! As near as I can tell Fil-C doesn't support this, or any other sort of FFI, at all. Nor am I sure FFI would even make sense, it seems like an approach that has to take over the entire program so that it can track pointer provenance.

For securing and maintaining a complex legacy application it seems like a reasonable approach would be to move the majority into Fil-C, then hook the bits that don't fit up via RPC. Maybe some bits get formal verification, rewritten in Rust, ported to new platform APIs, whatever, but at least you get some safety for the whole app without a rewrite.

Re: Notes by djb on using Fil-C

#164

Post by erichocean »

timeon wrote: post #141
erichocean wrote: post #135

I would really like to see Omarchy go this direction. A fully memory-safe userland for Omarchy is possible with existing techhnology.

Can you elaborate why Omarchy? I'm asking, in context of recompiling with Fil-C, because that seems to be just Arch + configurations.

For cultural reasons, I would like Omarchy—culturally—to adopt straightforward security as one of their goals, in addition to usability and beauty.

It's low hanging fruit, and a great way to further differentiate their Linux distribution.

Re: Notes by djb on using Fil-C

#165

Post by buu700 »

kragen wrote: post #57
simonask wrote: post #44

Earlier quoted context omitted.

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…

I think Fil-C is for people who are using software that has already been written, not for people who are trying to pick what language to write new software in. A substantial amount of software has, after all, already been written.

It seems kind of analogous to disabling hyperthreading. Sure there's an immediate performance hit, but in exchange you're now protected from entire classes of vulnerabilities. A few years later, no one remembers or cares about that old setback that has been long since eclipsed by subsequent hardware advancements.

Modern hardware is stupidly fast compared to what existed at the time that a lot of C/C++ projects first started. My M2 MacBook Air has 5x higher multi-core performance than my previous daily driver (a 2015 MacBook Pro, a highly capable machine in its own right), and the new iPhone is now even faster than that. I'd happily accept a worst-case 4x slowdown of all user space C/C++ code in the interest of security, especially when considering how much of that code is going to be written by AI going forward.

Re: Notes by djb on using Fil-C

#166

Post by pas »

bgwalter wrote: post #124
pas wrote: post #117

Earlier quoted context omitted.

... if he thinks some WG is making a mistake and he's not welcome there (everyone else seems to be okay with what's happening based on the quoted email on the first link), then - CoC or not - he should then leave, and publicly post distance himself from the outcome. (Obviously he was never the one to back down from a just fight, but it's important to find the right hill to die on. And allies! And him not following RF…

Why should he leave? The IETF pretends on its sponsor page ( https://www.ietf.org/support-us/endowment/ ): The IETF is a global standards-setting organization, intentionally created without a membership structure so that anyone with the technical competency can participate in an individual capacity. This lack of membership ensures its position as the primary neutral standards body because participants cannot exert in…

> Why should he leave?

Because the game is rigged apparently?

If not then let the WG work. If no one except djb feels this strongly about hybrid vs. pure post-quantum stuff then it's okay.

(And I haven't read the threads but this is a clear security trade-off. Involving complexity, processing power and bandwidth and RAM and so on, right? And the best and brightest cryptographers checked the PQ algorithms, and the closer we get to them getting anywhere near standardized in a pure form the more scrutiny they'll receive.

And someone being an NSA lackey is not a technical merit argument. Especially if it's true, because in this case the obvious thing is to start coalition building to have some more independent org up and running, because arguing with a bad faith actor is not going to end well.)

Re: Notes by djb on using Fil-C

#167

Post by tonetheman »

uecker wrote: post #19
IshKebab wrote: post #10

Earlier quoted context omitted.

Almost like it's actually fine. https://medium.com/@ewindisch/curl-bash-a-victimless-crime-d...

It is definitely not fine. The argument seems to be that since you need to trust somebody, curl | bash is fine because you just trust whoever controls the webserver. I think this is missing the point.

[dead]

Re: Notes by djb on using Fil-C

#168

Post by vacuity »

pornel wrote: post #116
lquidfire wrote: post #113

Cool project! I take it the goal is that, overhead being acceptable, most C / C++ programmes don't actually "have to be" rewritten in something like Rust? I wonder how / where Epic Games comes in?

Note that Fil-C is a garbage-collected language that is significantly slower than C. It's not a target for writing new code (you'd be better off with C# or golang), but something like sandboxing with WASM, except that Fil-C crashes more precisely.

A GC lang isn't necessarily significantly slower than C. You should qualify your statements. Moreover, this is a variant of C, which means that the programs are likely less liberal with heap allocations. It remains to be seen how much of a slowdown Fil-C imposes under normal operating conditions. Moreover, although it is indeed primarily suited for existing programs, its use in new programs isn't necessarily worse than, e.g., C# or Go. If performance is the deciding factor, probably use Rust, Zig, Nim, D, etc. .

Re: Notes by djb on using Fil-C

#169

Post by vacuity »

thesz wrote: post #148
vacuity wrote: post #133

Earlier quoted context omitted.

Along with the sibling comment, microbenchmarks should not be used as authoritative data when the use case is full applications. For that matter, highly optimized Java or Go may be "1 to 4 times as slow as plain C". Fil-C has its merits, but they should be described carefully, just with any technology.

I replied to unwarranted (to my eye) call that Fil-C is significantly slower than plain C. Fil-C has its drawbacks, but they should be described carefully, just with any technology.

I maintain that microbenchmarks are not convincing, but you have a fair point that GP's statement is unfounded, and now I've made a reply to GP to that effect.

Re: Notes by djb on using Fil-C

#170

Post by bgwalter »

pas wrote: post #166
bgwalter wrote: post #124

Earlier quoted context omitted.

Why should he leave? The IETF pretends on its sponsor page ( https://www.ietf.org/support-us/endowment/ ): The IETF is a global standards-setting organization, intentionally created without a membership structure so that anyone with the technical competency can participate in an individual capacity. This lack of membership ensures its position as the primary neutral standards body because participants cannot exert in…

> Why should he leave? Because the game is rigged apparently? If not then let the WG work. If no one except djb feels this strongly about hybrid vs. pure post-quantum stuff then it's okay. (And I haven't read the threads but this is a clear security trade-off. Involving complexity, processing power and bandwidth and RAM and so on, right? And the best and brightest cryptographers checked the PQ algorithms, and the clo…

> If no one except djb feels this strongly about hybrid vs. pure post-quantum stuff then it's okay.

That is one of the contentious issues. See the last paragraphs of:

https://blog.cr.yp.to/20251004-weakened.html

Starting with "Remember that the actual tallies were 20 supporters, 2 conditional supporters, and 7 opponents".

Post reply on HN