SIMD-0460

TL;DR

Virtual address space related changes split off from SIMD-0219: Removing pitfalls and foot-guns from the ABI (including syscalls) and runtime.

Summary

Virtual address space related changes split off from SIMD-0219: Removing pitfalls and foot-guns from the ABI (including syscalls) and runtime.

Motivation

In a recent meeting between the Agave and Firedancer core developers it was decided that SIMD-0219 should be split into two feature gates. This SIMD covers the second half which is focused on the address translation, memory mappings, reallocation / resizing, zeroing and defining empty / unmapped address space. The reasoning for splitting SIMD-0219 is to de-risk its deployment and to be able to make progress on shipping earlier parts even if later parts have to be delayed further. Additionally, as the unaligned address translation mechanism required for this part of SIMD-0219 incurs a slight performance decrease, it was decided to globally deactivate stack frame gaps to counter the effect. Stack frame gaps were identified as a performance issue in the address translation in general.

Key Changes

• The access is completely within the maximum account length,
• The access is completely within the rest of the account growth budget of the
• The access is completely within the current length of the account,
• The account is flagged as writable,
• The account is owned by the currently executed program,

Impact

Splitting SIMD-0219 should have no impact on dApp developers or validators. An experiment to gauge the impact of the additional changes is currently running.

Security Considerations

Removing the stack frame gaps globally (even for SBPFv0) programs can affect programs which rely on the address space layout of the stack either by using absolute addressing, relative addressing across stack frames or being dependent on bugs such accesses reaching over the boundary of stack frames.