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.

▲ afdbcreid 3 hours ago | parent [-]

Both only attach provenance to allocations. The common example is:

    struct User {
        char name[100];
        bool is_admin;
    };

Where a buffer overflow can still overwrite `is_admin`.

Both also require recompilation of everything, which might be possible for CHERI but not for Fil-C - which is why, for example, there cannot be Fil-C support for Windows or macOS.

▲

cperciva 2 hours ago | parent | next [-]

No, CHERI supports sub-object capabilities.

▲

afdbcreid an hour ago | parent [-]

Nice, didn't know that!

	▲	dwattttt an hour ago \| parent [-]
		It's a safe/stable operation to derive a more limited capability (pointer) from a more capable one. An example would be an arena allocator having a pointer valid for the whole arena, but then only handing out a derived pointer that's valid for the size requested. You can also limit access permissions IIUC; I'm only going by old memory hear, but you'd be able to hand out a read-only pointer derived from an RWX pointer.

▲

aw1621107 an hour ago | parent | prev [-]

IIRC Filip said that Fil-C can be modified fairly easily to catch those overflows, but that breaks a fair bit of C code.