Require a `code` flag for memories?

[titzer]

The initial design issue proposed an additional flag on memories to mark them as suitable for (temporarily) holding code for func.new. There wasn't a lot of support for the idea, so to simplify the proposal, I removed the flag from the explainer.

Do we want to add this code flag back?

Feel free to use this issue to discuss.

[IFcoltransG]

Most of the time, code tags on memory will correspond to exactly the memories referenced by one or more func.new instructions, in which case this might not be worth the complexity. But there are exceptions.

One exception where a module's func.new couldn't guarantee that the code tag would be set on a memory is if the module doesn't control the memory. For example, it imports a memory that's not intended to be executable. I can't see a security weakness to let the module just use the imported memory in this circumstance; it could achieve the same result by declaring its own code memory and copying from that imported memory into it.

I'm more concerned if a memory can be used by a func.new that didn't originally appear in the module, presumably because it was itself generated by a different func.new (or any future dynamic features added to wasm).
A JIT-compiled func.new would mean runtimes couldn't statically know in advance which memories will be executed (although perhaps this would be rare enough for users to accept any performance costs). It would also make it harder to prevent malicious uses of func.new. Let's suppose an attacker corrupts the linear memory used by a func.new, taking control over what new wasm it executes. The scope does limit direct damage an attacker can deal with memories, exports, globals and so on, but if the module has access to any memory, then without validation of code tags it could simply run its own func.new with that memory and a different scope. It can't declare a scope itself, but I don't see anything in the current spec preventing it from using a pre-existing scope from the scope section.

To be honest, though, restricting access to executable memory via withheld code tags is a much less natural solution to func.new privilege escalation than restricting func.new's access to scopes, or to the func.new instruction.

[gkgoat1]

Most of the time, code tags on memory will correspond to exactly the memories referenced by one or more func.new instructions, in which case this might not be worth the complexity. But there are exceptions.

One exception where a module's func.new couldn't guarantee that the code tag would be set on a memory is if the module doesn't control the memory. For example, it imports a memory that's not intended to be executable. I can't see a security weakness to let the module just use the imported memory in this circumstance; it could achieve the same result by declaring its own code memory and copying from that imported memory into it.

I'm more concerned if a memory can be used by a func.new that didn't originally appear in the module, presumably because it was itself generated by a different func.new (or any future dynamic features added to wasm). A JIT-compiled func.new would mean runtimes couldn't statically know in advance which memories will be executed (although perhaps this would be rare enough for users to accept any performance costs). It would also make it harder to prevent malicious uses of func.new. Let's suppose an attacker corrupts the linear memory used by a func.new, taking control over what new wasm it executes. The scope does limit direct damage an attacker can deal with memories, exports, globals and so on, but if the module has access to any memory, then without validation of code tags it could simply run its own func.new with that memory and a different scope. It can't declare a scope itself, but I don't see anything in the current spec preventing it from using a pre-existing scope from the scope section.

To be honest, though, restricting access to executable memory via withheld code tags is a much less natural solution to func.new privilege escalation than restricting func.new's access to scopes, or to the func.new instruction.

We could also make scopes themselves scoped so func.new calls can't recurse by default