Securing tomorrow's software: the need for memory safety standards

Re:Securing tomorrow's software: the need for memory safety ... by pizlonator on Thursday February 27, 2025 @11:28AM (#43195832)

Your first example will hilariously work if `f` is inline and simple enough and optimizations are turned on. I'm not sure I like that, so I might change that. I'd like to only guarantee the you get a capability in cases where that guarantee holds regardless of optimization (and I could achieve that with some more compiler hacking).

Not sure about the semantics of with_addr. But note that you can do this in Fil-C:

    char* p = ...;
    uintptr_t i = ...;
    p -= (uintptr_t)p; // now p is NULL but still has its original capability
    p += i; // now p points to whatever i's address was, but has p's original capability

I have a helper like that called `zmkptr` (it's just an inline function that does exactly the above).

[ Parent | on HN ]

Re:Securing tomorrow's software: the need for memory safety ... by amluto on Thursday February 27, 2025 @01:19PM (#43196917)

with_addr is basically that, but with a name and some documentation:

https://doc.rust-lang.org/std/primitive.pointer.html#method....

As I understand it, Rust added this in part for experiments with CHERI but mostly for miri.

Interestingly, the implementation of with_addr is very similar to your code.

How do you handle cases where there are multiple possible sources of the capability? For example:

    int *a = …, *b = …;
    (int*)(((uintptr_t)a + (uintptr_t)b) << 2)

I’m not sure I would allow this into any code I maintain, but still. There’s also the classic xor-list, and someone has probably done it like:

    struct node { struct node *p; };
    
    struct node *next(struct node *here, struct node *prev)
    {
        return (struct node *)((uintptr_t)here ^ (uintptr_t)prev);
    }

And this needs to either result in a compiler error or generate some kind of code.

Rust’s with_addr wins points for being explicit and unambiguous. It obviously loses points for not being C. And Rust benefits here from all of this being in the standard library and from some of the widely-available tooling (miri) getting mad if code doesn’t use it. I can imagine a future Fil-Rust project doing essentially the same thing as Fil-C except starting with Rust code. It might be interesting to see how the GC part would interact with the rest of the language.

[ Parent | on HN ]

Re:Securing tomorrow's software: the need for memory safety ... by pizlonator on Thursday February 27, 2025 @01:34PM (#43197058)

My compiler analysis says that if you have two possible pointers that a capability might come from, like in your first example, then you get no capability at all. I think that's a better semantics than picking some capability at random.

If you want to be explicit about where the capability comes from, use `zmkptr`.

[ Parent | on HN ]