Soni L.
Soni L.
some of the CFI strategies are "hardware-assisted". now, wasm is technically not hardware, but we think wasm could adopt some concept of "hardware-assisted" CFI, and we think it can be...
indeed, overflowing a buffer and corrupting/replacing function pointers is perfectly legal. CFI limits the damage such replacements can do, by restricting the function pointers you can replace. wasm has limited...
hmm. how does that interact with imports?
interesting! why is it like that?
ah interesting. ... but hmm, so it's a closed group, right? that seems like it would make things annoying. ... but hmm, we guess this gives us named function types....
something like ```wasm (type $t (private)) (rec (func $ignoreme (param $t)) (func $strlen_t (param i32) (result i32)) ) ``` would be unique for each instance of the module? but if...
what happens if you have a recursion group like ```wasm (rec (type $t i32) (type $u i64) ) ``` what do these types mean
ahh! so, instead of applying newtypes to the parameters and results, we could be applying newtypes to the function types themselves? that makes sense
really we just wanna have function newtypes outside of the GC proposal. :p this would allegedly enable some new optimizations in emscripten too...
so, rough idea: ```wasm (newtype $t $heaptype) ``` is sugar for ``` (rec (type (private)) (type $t $heaptype) ) ``` (or thereabouts. not entirely sure about the syntax.) and this...