Jonathan Protzenko
@protz.bsky.social
I talk about Rust, verification, cryptography, programming languages… and pets
Yes we would automate the generation of that "thin" layer. We have plenty of existing tooling to do so, we could use e.g. charon arxiv.org/abs/2410.18042 to inspect the function signatures, and generate the wrappers.
Charon: An Analysis Framework for Rust
With the explosion in popularity of the Rust programming language, a wealth of tools have recently been developed to analyze, verify, and test Rust programs. Alas, the Rust ecosystem remains relativel...
arxiv.org
June 10, 2025 at 8:19 PM
Yes we would automate the generation of that "thin" layer. We have plenty of existing tooling to do so, we could use e.g. charon arxiv.org/abs/2410.18042 to inspect the function signatures, and generate the wrappers.
If the proposal (forgot where the link is) to guarantee an extern "C" ABI for slices goes through, the wrapper will be greatly simplified.
June 10, 2025 at 6:50 PM
If the proposal (forgot where the link is) to guarantee an extern "C" ABI for slices goes through, the wrapper will be greatly simplified.
The plan is to go through the extern "C" ABI for the sake of i) FIPS certification and ii) being able to link against a system version of SymCrypt. This will involve a thin unsafe wrapper that re-exports the original Rust signatures to a Rust client through the C ABI.
June 10, 2025 at 6:50 PM
The plan is to go through the extern "C" ABI for the sake of i) FIPS certification and ii) being able to link against a system version of SymCrypt. This will involve a thin unsafe wrapper that re-exports the original Rust signatures to a Rust client through the C ABI.