[HN Gopher] Fil-C: A memory-safe C implementation
___________________________________________________________________
Fil-C: A memory-safe C implementation
Author : chmaynard
Score : 76 points
Date : 2025-10-28 17:25 UTC (5 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| gnabgib wrote:
| No discussion, but just on the front page last week (31 points)
| https://news.ycombinator.com/item?id=45655519
|
| Previous discussion:
|
| 2025 _Safepoints and Fil-C_ (87 points, 1 month ago, 44 comments)
| https://news.ycombinator.com/item?id=45258029
|
| 2025 _Fil 's Unbelievable Garbage Collector_ (603 points, 2
| months ago, 281 comments)
| https://news.ycombinator.com/item?id=45133938
|
| 2024 _The Fil-C Manifesto: Garbage In, Memory Safety Out_ (13
| points, 17 comments)
| https://news.ycombinator.com/item?id=39449500
| synergy20 wrote:
| posted multiple times, x86 only last time I checked
| lambdaone wrote:
| All the more reason to make it portable. I wonder if this can
| be implemented via LLVM?
| kragen wrote:
| It is implemented via LLVM.
| kragen wrote:
| Either Fil-C or a different implementation of the same idea seems
| essential to me. A great deal of software has been written in C,
| and without some way of running it, we lose access to that
| intellectual heritage. But pervasive security vulnerabilities
| mean that the traditional "YOLO" approach to C compilation is a
| bad idea for software that has to handle untrusted input, such as
| Web browsing or email.
|
| Pizlo seems to have found an astonishingly cheap way to do the
| necessary pointer checking, which hopefully I will be able to
| understand after more study. (The part I'm still confused about
| is how InvisiCaps work with memcpy.)
|
| tialaramex points out that we shouldn't expect C programmers to
| be excited about Fil-C. The point tialaramex mentions is "DWIM",
| like, accessing random memory and executing in constant time, but
| I think most C programmers won't be willing to take a 4x
| performance hit. After all, if they wanted to be using a slow
| language, they wouldn't be writing their code in C. But I think
| that's the wrong place to look for interest: Fil-C's target
| audience is _users_ of C programs, not _authors_ of C programs.
| We want the benefits of security and continued usage of existing
| working codebases, without having to pay the cost to rewrite
| everything in Rust or TypeScript or whatever. And for many of us,
| much of the time, the performance hit may be acceptable.
| nielsbot wrote:
| I like to share this every time there's a post about memory
| safe C:
|
| Apple has a memory-safer C compiler/variant they use to compile
| their boot loaders:
|
| https://saaramar.github.io/iBoot_firebloom/
| astrange wrote:
| A descendent of this is in clang as -fbounds-safety.
| kragen wrote:
| Yeah, fat pointers are definitely a viable approach, but a
| lot of the existing C code that is the main argument for
| Fil-C assumes it can put a pointer in a long. (Most of the C
| code that assumed you could put it in an int has been flushed
| out by now, but that was a big problem when the Alpha came
| out.) I'm guessing that the amount of existing C code in
| Apple's bootloader is minimal, maybe 1000 lines, not the
| billions of lines you can compile with Fil-C.
| matthewfcarlson wrote:
| You're off by a few orders of magnitude. I'll grant you,
| what is the bootloader becomes a very complex question.
| Even if you scope it to just "what is the code physically
| etched into the chip as the mask ROM" (secureROM) you're
| talking hundreds of thousands. If you're talking about all
| the code that runs before the kernel starts executing
| you're talking hundreds of millions.
| kragen wrote:
| No, I was only talking about the pre-existing C code that
| wasn't written for the bootloader, which therefore might
| have incompatibilities with fat pointers you had to hunt
| down and fix.
|
| Also I'm really skeptical about your "hundreds of
| millions" number, even if we're talking about all the
| code that runs before the kernel starts. How do you
| figure? The entire Linux kernel doesn't contain a hundred
| millions of lines of code, and that includes all the
| drivers for network cards and multiport serial boards
| that nobody's made in 30 years, plus ports to Alpha, HP
| PA-RISC, Loongson, Motorola 68000, and another half-dozen
| architectures. All of that contains maybe 30 million
| lines. glibc is half a million. Firefox 140.4.0esr is 33
| million.
|
| Are you really suggesting that tens of gigabytes of
| source code are compiled into the bootloader? That would
| make the bootloader at least a few hundred megabytes of
| executable code, probably gigabytes, wouldn't it?
| ummonk wrote:
| Couldn't one just make long bigger then to make it match?
| kragen wrote:
| Maybe so; I haven't tried. Probably a lot less code
| depends on unsigned long wrapping at 264 than used to
| depend on unsigned int wrapping at 216, and we got past
| that. But stability standards were lower then. Any code
| that runs on both 32-bit and 64-bit LP64 systems can't be
| _too_ dependent on the exact sizeof long, and sizeof long
| already isn 't sizeof int the way it was on 32-bit
| platforms.
| conradev wrote:
| and the author of Fil-C worked on that!
| kragen wrote:
| Oh, somehow I missed that connection!
| TuxSH wrote:
| Also this is _de facto_ limited to userspace application for
| the mainstream OSes if my understanding is correct.
|
| Reading Fil-C website's "InvisiCaps by example" page, I see
| that "Laundering Integers As Pointers" is disallowed. This
| essentially disqualifies Fil-C for low-level work, which makes
| for a substantial part of C programs.
|
| (int2ptr for MMIO/pre-allocated memory is in theory UB, in
| practice just fine as long as you don't otherwise break
| aliasing rules (and lifetime rules in C++) - as the compiler
| will fail to track provenance at least once).
|
| But that isn't really what Fil-C is aimed at - the value is, as
| you implied, in hardening userspace applications.
| kragen wrote:
| Yes, I think that's reasonable. I imagine you wouldn't have
| to extend Fil-C very much to sneak some memory-mapped I/O
| addresses into your program, but maybe having the garbage
| collector pause the program in the middle of an interrupt
| handler would have other bad effects. Like, if you were
| generating a video signal, you'd surely get display glitches.
| mbrock wrote:
| Check out this document to see how the Fil-C ports of Python
| and Perl and so on work:
|
| https://github.com/mbrock/filnix/blob/main/ports/analysis.md
|
| This is still within the userspace application realm but it's
| good to know that Fil-C does have explicit capability-
| preserving operations (`zxorptr`, `zretagptr`, etc) to do
| e.g. pointer tagging, and special support for mapping
| pointers to integer table indices and back (`zptrtable`,
| etc).
| mbrock wrote:
| I'm working on packaging Fil-C for Nix, as well as integrating
| Fil-C as a toolchain in Nix so you can build any Nix package with
| Fil-C.
|
| https://github.com/mbrock/filnix
|
| It's working. It builds tmux, nethack, coreutils, Perl, Tcl, Lua,
| SQLite, and a bunch of other stuff.
|
| Binary cache on https://filc.cachix.org so you don't have to wait
| 40 minutes for the Clang fork to build.
|
| If you have Nix with flakes on a 64-bit Linux computer, you can
| run nix run github:mbrock/filnix#nethack
|
| right now!
| nextaccountic wrote:
| Somewhat related, safe C++ proposal is not being continued
|
| https://news.ycombinator.com/item?id=45234460
___________________________________________________________________
(page generated 2025-10-28 23:00 UTC)