Risks of 32-bit memory address space and disabled GC

[norswap]

I seem to recall that the memory available to the MIPS version of Cannon is limited (2GB? 4GB?). We should check this, and make sure it's not possible to craft a set of blocks such that processing them would cause the memory limit to be exceeded.

We should also make sure memory is never written to the various "magic" memory location (input hash, output hash, preimage oracle input and output). (update: registers and pre-image data are separate from memory now).

[norswap]

Important to keep in mind: we explicitly disable garbage collection (because it requires threading), so we need to be mindful of memory consumption. Every heap allocation is forever!

If we're able to stack allocate the per-epoch inputs (transactions and receipts), that would help a lot I think.

[protolambda]

The system state is now fully separated from regular program memory address space. And the pre-image oracle is now backed by read/write syscalls. So registers and state etc. are safe from accidental overwrites. There still exists a memory risk where we run out of available address-space, due to the lack of GC. Will update issue title and description to reflect this.