Memory syscalls cannot start in an account and end outside of it #3744
Conversation
|
The Firedancer team maintains a line-for-line reimplementation of the |
seanyoung
force-pushed
the
syscall-limits
branch
3 times, most recently
from
842df48 to
93e6375
Compare
In the same way, a memory syscall cannot start outside of an account and up within one.
seanyoung
force-pushed
the
syscall-limits
branch
from
0809b07 to
424c886
Compare
|
Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis. |
* Memory syscalls cannot start in an account and end outside of it In the same way, a memory syscall cannot start outside of an account and up within one. (cherry picked from commit 36d1017)
…t (backport of #3744) (#3885) * Memory syscalls cannot start in an account and end outside of it (#3744) * Memory syscalls cannot start in an account and end outside of it In the same way, a memory syscall cannot start outside of an account and up within one. (cherry picked from commit 36d1017) * Update Cargo.lock --------- Co-authored-by: Sean Young <[email protected]>
…t (backport of #3744) (#3885) * Memory syscalls cannot start in an account and end outside of it (#3744) * Memory syscalls cannot start in an account and end outside of it In the same way, a memory syscall cannot start outside of an account and up within one. (cherry picked from commit 36d1017) * Update Cargo.lock --------- Co-authored-by: Sean Young <[email protected]>
The input area of the address space contains things like the instruction data and the accounts passed into the program, including the account data itself. From the perspective of the SBF program, all these are stored back-to-back in memory, but with direct mapping, the account data is actually stored in a separate memory region.
Previously, memcpy, memmove, memcmp, and memset can start and stop anywhere in memory; it is possible to start in account data, and give a length beyond the end of the account data; it would cross into a new region. Conversely, it possible to start before account data and up within the account data.
This change restricts these four syscalls so that memory regions are entirely inside account data or outside of it.
There is no reason why you require this and no mainnet program does this. This change was requested by Firedancer for direct mapping.