4 ms·
>“what makes WASM different” As I understand it, it's just difficult to efficiently implement GC because of the stupid decision to abstract the call stack with
by knome 3y ago
>“what makes WASM different”
As I understand it, it's just difficult to efficiently implement GC because of the stupid decision to abstract the call stack within WASM, making it painful to get at stack pointers during collection.
One would think that a generic VM assembly and the ability to make pages of memory as no longer in use so the VM and then OS can recollect them would be sufficient.
Rather than admitting to and fixing their mistake, they're doubling down and doing something of much greater complexity to work around it.
- johncolanduoni 3y agoThat “stupid decision” is pretty key to WASM sandboxing model. How do you propose to preserve call flow integrity without it?
- ori_b 3y agoDon't put return address on the data stack, and don't allow write access to the call stack via anything other than call/ret.
- johncolanduoni 3y agoOkay, where does the VM spill registers to?
- HappMacDonald 3y agoI don't understand why more languages don't just handle a separate data stack from the call stack. Then the call stack can remain harder to screw up and you can continue using stack frames for arguments or locals as desired. When feeling productive (not much in the past year unfortunately) I've been trying to build a bytecode for i86/x64 that operates this way.
- ori_b 3y agoI see what you're getting at. I think something like code pointed integrity would be more interesting, and would even protect pointers in vtables and other heap allocated structures: https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-kuznetsov.pdf https://www.usenix.org/system/files/conference/osdi14/osdi14...