Remix.run Logo
Panzerschrek 3 days ago

Extern "fil-C" can't be compatible with Rust code or something similar. It requires a metadata block attached to each allocation. So, if a memory block has been allocated in Rust and a pointer to it is passed to a fil-C function, it can't access it correctly. The only way to allow such cross-langauge-and-abi calls is to compile Rust code itself like fil-C, which requires doubled memory consumption, expensive runtime checks and GC overhead.

jaen 2 days ago | parent | next [-]

Naah.

Solvable by turning the usual C library allocation pattern inside-out:

Only the C side allocates, Rust gets views of that memory.

Also well established - calling WebAssembly components requires exactly the same pattern, as the only way to malloc is to call into the WASM side.

CyberDildonics 3 days ago | parent | prev | next [-]

Why would it double memory consumption just for a metadata block? Why not just wrap the memory allocation function so it makes that block?

tracnar 3 days ago | parent | prev [-]

Another way would be to enforce a copy, adding the metadata, at the boundary with fil-C, right? Of course that makes the FFI way less useful...

SkiFire13 2 days ago | parent [-]

Even that way will be very difficult to make it work.

The Fil-C side could change the data behind the pointer, which will not reflect on the Rust side due to the copy. Even if you manage to copy back the changes, Fil-C could also persist those pointers in e.g. global memory: at that point you no longer know when it's safe to copy back (or forward) any change.

The only way I can see this work if you cannot pass any Rust-land pointers into Fil-C, but at that point you could also compile the C code to WASM and use the WASM FFI (which has similar restrictions)

jaen 2 days ago | parent [-]

WASM is not a substitute for Fil-C.

WASM is not memory safe in the same sense, in particular, heap corruption vulnerabilities still exist, which could eg. allow bypassing auth, leaking private information etc.

C compiled to WASM is still vulnerable to something like OpenSSL Heartbleed. Fil-C (and CHERI) is not.