Further changes to the way memory accesses are treated.

Author: Lichtso

proposals/0219-stricter-vm-verification.md

@@ -8,7 +8,7 @@ category: Standard
 type: Core
 status: Review
 created: 2025-01-06
-feature: GJVDwRkUPNdk9QaK4VsU4g1N41QNxhy1hevjf8kz45Mq
+feature: C37iaPi6VE4CZDueU1vL8y6pGp5i8amAbEsF31xzz723
 ---
 
 ## Summary
@@ -73,45 +73,51 @@ The virtual address space of the stack frames must become consecutive:
 This goes for all programs globally and is not opt-in.
 Thus, this change is independent of SIMD-0166.
 
-### VM write access
+### VM memory access
 
-When a write access to the input region (`0x400000000..0x500000000`) happens,
-which overlaps with a range in which an accounts payload, including its resize
-padding but not its metadata, was serialized it must be checked that:
+The payload address space of an account is the range in the serialized input
+region (`0x400000000..0x500000000`) which covers the payload and optionally the
+10 KiB resize padding (if not a loader-v1 program), but not the accounts
+metadata.
+
+For loads / read accesses to an accounts payload address space check that:
+
+- The access is completely within the current length of the account,
+otherwise `InstructionError::AccountDataTooSmall` must be thrown.
+
+For stores / write accesses to an accounts payload address space check that:
 
 - The account is flagged as writable,
 otherwise `InstructionError::ReadonlyDataModified` must be thrown
 - The account is owned by the currently executed program,
-otherwise `InstructionError::ExternalAccountDataModified` must be thrown
-
-Thus, changing and later restoring data in unowned accounts is prohibited.
+otherwise `InstructionError::ExternalAccountDataModified` must be thrown.
+- The access is completely within the current length of the account,
+otherwise grow the account length and fill it with zeros up to the end of the
+access or the end of the payload address space, which ever is lower.
 
 ### Syscall slice parameters
 
-When a range in virtual address space which:
-
-- starts in any account data (including its resize padding) and leaves it
-- starts outside account data and enters it
-
-is passed to `memcpy`, `memmove`, `memset`, or `memcmp`, it must throw
-`SyscallError::InvalidLength`.
-
 Except for CPI, all other syscalls which
 act on ranges in the virtual address space are confined to a single
-memory region for now. Meaning they have to stay within one of:
+memory region. Meaning they have to stay within one of:
 
-- Readonly data
-- Stack
-- Heap
+- Readonly data (`0x100000000..0x200000000`)
+- Stack (`0x200000000..0x300000000`)
+- Heap (`0x300000000..0x400000000`)
+- Instruction meta data
 - Account meta data
-- Account data without resize padding
-- Account resize padding
+- Account payload address space
+- Instruction payload
 
-And can not cross into any other region. This restriction is planned to
-be lifted in another SIMD.
+And can not cross into any other region.
 
 ## Impact
 
+Changing and later restoring data in unowned accounts is now prohibited.
+The same goes for growing an unowned account and later truncating it to its
+original length. Or reading from the uninitialized memory beyond the current
+length of any account.
+
 These restrictions have been extensively tested by replay against MNB.
 Most of the dApps devs whose dApps would fail have been contacted and had
 their dApps fixed already.