SIMD-0459
Syscall Parameter Address Restrictions
TL;DR
Syscall parameter related changes split off from SIMD-0219: Removing pitfalls and foot-guns from the ABI (including syscalls) and runtime.
Summary
Syscall parameter 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 first half which is focused on reducing the attack surface and fix long standing issues with CPI in general. 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. The reason for cutting SIMD-0219 at this specific boundary is that this first half is not expected to have any impact on performance, while the second half on the other hand will. Additionally, some consensus relevant code reordering is added to reduce the attack surface of around CU metering and make the CPI logic more comprehensible after this SIMDs feature gates are cleaned up.
Key Changes
- The following pointers must be on the stack or heap,
- The destination address of all sysvar related syscalls
- The pointer in the array of &[AccountInfo] / SolAccountInfo
- The AccountInfo::data field, which is a RefCell<&[u8]> in sol_invoke_signed_rust
- The AccountInfo::lamports field, which is a RefCell<&u64> in sol_invoke_signed_rust
- The following pointers must point to what was originally serialized in the
- AccountInfo::key / SolAccountInfo::key
- AccountInfo::owner / SolAccountInfo::owner
- AccountInfo::lamports / SolAccountInfo::lamports
- AccountInfo::data::ptr / SolAccountInfo::data
Impact
Splitting SIMD-0219 should have no impact on dApp developers or validators. The additional changes are continuously tested (over a month) and monitored on mainnet-beta to not cause any existing dApps to behave differently.
Security Considerations
None.