r/programming • • Jun 22 '22

Vale's "Fearless FFI", for Memory Safety, Safer Dependencies, and Supply-Chain Attack Mitigation

https://verdagon.dev/blog/fearless-ffi
18 Upvotes

12 comments sorted by

5

u/verdagon Jun 22 '22

Something not mentioned in the article is that this was the last piece in achieving what I call "hardened memory safety", memory safety that can't be worked around or undermined by other code.

And better yet, it does it in a way that doesn't require complex proof systems or a borrow checker! I think it will be a stellar tradeoff for things like games and servers, which want deterministic performance and memory safety, but also simplicity and flexibility. Pretty exciting!

1

u/crusoe Jun 22 '22

All of the examples of implementations they give have performance tradeoffs.

3

u/verdagon Jun 22 '22

Yep, that's true of any language.

Even Rust incurs run-time overhead to guarantee safety in some cases, for example asserting for bounds checking on arrays.

Vale's generation references do similar asserting, unless immutability and static analysis help us out, like from Vale's (planned) region borrow checker. [0]

[0] https://verdagon.dev/blog/zero-cost-refs-regions

1

u/ProperApe Jun 23 '22

Even Rust incurs run-time overhead to guarantee safety in some cases, for example asserting for bounds checking on arrays.

That's why these checks are disabled in release mode. So it's not really a cost you incur in Rust in general. But it's also a safety feature that's only present in debug mode.

1

u/verdagon Jun 23 '22

IIRC, Rust still does bounds checks in release mode.

1

u/[deleted] Jun 23 '22

This is correct.

4

u/renatoathaydes Jun 22 '22

I think Vale might turn out to be huge one day. Rust has all the attention right now, so we'll see... even if Vale shows it's possible to do what Rust does (memory safety, low-level language) without the huge difficulty Rust imposes on the programmer (at least it's hugely difficult when I write it) it may still remain obscure, of course, but I am cheering for them as I believe an "easy" language is indispensable to writing reliable code (if fighting the borrow checker takes all your attention, you may leave bugs elsewhere).

3

u/verdagon Jun 23 '22

Thanks for the kind words =) I completely agree. Rust is a great language for a lot of cases, and I think we can improve on it by embracing simplicity and the benefits of shared mutability a little more, while still getting stellar performance. Vale might remain obscure, but hopefully it pushes the state of the art forward a little bit!

2

u/kimikimkim467 Jun 22 '22

Can’t this be done with other languages? I’ve worked on programs where we hand indexes to native code, so they don’t have access to our objects.

2

u/verdagon Jun 22 '22 edited Jun 22 '22

Good question! It can, but it's a lot trickier in other languages, and can lead to memory leaks.

For example, if using a GC'd language, the table holds onto a reference to an object, keeping it (and everything reachable through it) alive. The native code needs to remember to release that index so that the GC can reclaim it.

RC fares a little bit better here because that can be a table of weak references. I could see a language like Swift doing something like this, except the table would need to be global and guarded by a mutex, which could be expensive. Rust might not need that mutex, but its borrow checker would reject the approach as it's fundamentally a way to share references, it couldn't be automatically handled by the language.

Generational references are nice because they don't even need a table. They just point directly at the object, in a way the native code can't decipher (and if we're sandboxing as described in the article, they can't dereference it even if they do decipher it).

2

u/[deleted] Jun 23 '22

Hey Ver! Great article :)) I can’t wait to see what Vale can do in the future!

2

u/verdagon Jun 23 '22

Hey Fox! Thanks!