* restrict curve25519 multiscalar multiplication vector length to 512
* add syscall tests for msm vector length
* add new feature gate `curve25519_restrict_msm_length`
* update tests for feature new gate
* Update programs/bpf_loader/src/syscalls/mod.rs
Co-authored-by: Trent Nelson <trent.a.b.nelson@gmail.com>
* remove length guard on the multisicalar mult lib function
---------
Co-authored-by: Trent Nelson <trent.a.b.nelson@gmail.com>
* use PROGRAM_OWNER + program data for account executable
mock account data with executable_meta in precompiled program and update
test_bank_hash_consistency test
pr: return const slice and add comments
pr: use ReadableAccount
use const to get rid of magic number
add featuregate disable_bpf_loader_instructions to disable bpf loader management instructions, and deprecate_executable_meta_update_in_bpf_loader to deprecate executable flag update in bpf loader
deprecate usage of executable in Account
fix a test
fix sbp bench
fix sbf program tests
add feature gate to account and borrowed account apis
fix tests
more test fixes
* restore bpf_loader v2 tests
---------
Co-authored-by: HaoranYi <haoran.yi@solana.com>
* Use 2's random selection to evict program cache
* implement decaying of usage counter
* replace RwLock with AtomicU64
* address review comments
* remove -> swap_remove
iter_memory_pair_chunks was iterating regions in reverse, but not memory
_within_ regions in reverse.
This commit fixes the issue and simplifies the implementation by removing
nested loops which made control flow hard to reason about.
If the vector holding an account is reallocated during execution of a callee,
we must zero the spare capacity regardless of whether the account size changed,
because the underlying vector might contain uninitialized memory in the spare
capacity.
reserve(additional) reserves additional bytes on top of the current _length_
not capacity. Before this fix we could potentially reserve less capacity than
required.
* updated inner_call for hashing fn to follow generic approach
* different hash compute budget values for all digests
* fixed conflicts
* reverted changes to compute_budget.rs and added 3method to trait to get compute budget values
* updated type for result fn for HasherImpl
* using Hash directly in result fn, got rid of HASH_BYTES and removed comment form compute_budget
* updated import statement
* cargo fmt -all
* removed unused import and reference related warning
* oops forgot semicolon
* removed trailing white space
* solana-program - altbn128: add g1 & g2 compression
still fixing tests for point of infinity
feat: proof compression syscall working
add rust test to ci
remove prints
added c test
added sycall pricing
* fixed ci checks
* refactored altbn128 and compression
* Do not unnecessarily re-verify unloaded program
* clippy fixes
* new unit test for extract
* fixes after rebase
* fixes after rebase
* address review comments
* fix clippy
* allow pedantic invalid cast lint
* allow lint with false-positive triggered by `test-case` crate
* nightly `fmt` correction
* adapt to rust layout changes
* remove dubious test
* Use transmute instead of pointer cast and de/ref when check_aligned is false.
* Renames clippy::integer_arithmetic to clippy::arithmetic_side_effects.
* bump rust nightly to 2023-08-25
* Upgrades Rust to 1.72.0
---------
Co-authored-by: Trent Nelson <trent@solana.com>
Computing Poseidon[0] hashes is too expensive to be done in a Solana
program in one transaction. Poseidon is a zero-knowlege proof friendly
hash function, used by the majority of ZK-based projects, including the
ones built on top of Solana.
This change introduces the `sol_poseidon` syscall which takes 2D byte
slice as an input and then calculates a Poseidon hash using a BN254
curve and the following Poseidon parameters:
* x^5 S-boxes
* width - 2 ≤ t ≤ 13
* inputs - 1 ≤ n ≤ 12
* 8 full rounds and partial rounds depending on t: [56, 57, 56, 60, 60,
63, 64, 63, 60, 66, 60, 65]
Computation of Poseidon hashes is done with the light-poseidon[1]
crate, which is audited[2] and compatible with Circom[3] (BN254 curve,
the same parameters and constants).
Proposed compute costs depend on number of inputs and are based on
light-poseidon benchmarks[4].
[0] https://www.poseidon-hash.info/
[1] https://crates.io/crates/light-poseidon
[2] https://github.com/Lightprotocol/light-poseidon/blob/main/assets/audit.pdf
[3] https://docs.circom.io/
[4] https://github.com/Lightprotocol/light-poseidon/tree/main#performance
* transaction_context: update make_data_mut comment
* bpf_loader: cpi: pass SerializeAccountMetadata to CallerAccount::from*
We now have a way to provide CallerAccount with trusted values coming
from our internal serialization code and not from untrusted vm space
* bpf_loader: direct_mapping: enforce account info pointers to be immutable
When direct mapping is enabled, we might need to update account data
memory regions across CPI calls. Since the only way we have to retrieve
the regions is based on their vm addresses, we enforce vm addresses to
be stable. Accounts can still be mutated and resized of course, but it
must be done in place.
This also locks all other AccountInfo pointers, since there's no legitimate
reason to make them point to anything else.
* bpf_loader: cpi: access ref_to_len_in_vm through VmValue
Direct mapping needs to translate vm values at each access since
permissions of the underlying memory might have changed.
* direct mapping: improve memory permission tracking across CPI calls
Ensure that the data and realloc regions of an account always track the
account's permissions. In order to do this, we also need to split
realloc regions in their own self contained regions, where before we
had:
[account fields][account data][account realloc + more account fields + next account fields][next account data][...]
we now have:
[account fields][account data][account realloc][more account fields + next account fields][next account data][...]
Tested in TEST_[FORBID|ALLOW]_WRITE_AFTER_OWNERSHIP_CHANGE*
Additionally when direct mapping is on, we must update all perms at once before
doing account data updates. Otherwise, updating an account might write into
another account whose perms we haven't updated yet. Tested in
TEST_FORBID_LEN_UPDATE_AFTER_OWNERSHIP_CHANGE.
* bpf_loader: serialization: address review comment don't return vm_addr from push_account_region
* bpf_loader: rename push_account_region to push_account_data_region
* cpi: fix slow edge case zeroing extra account capacity after shrinking an account
When returning from CPI we need to zero all the account memory up to the
original length only if we know we're potentially dealing with uninitialized
memory.
When we know that the spare capacity has deterministic content, we only need to
zero new_len..prev_len.
This fixes a slow edge case that was triggerable by the following scenario:
- load a large account (say 10MB) into the vm
- shrink to 10 bytes - would memset 10..10MB
- shrink to 9 bytes - would memset 9..10MB
- shrink to 8 bytes - would memset 8..10MB
- ...
Now instead in the scenario above the following will happen:
- load a large account (say 10MB) into the vm
- shrink to 10 bytes - memsets 10..10MB
- shrink to 9 bytes - memsets 9..10
- shrink to 8 bytes - memset 8..9
- ...
* bpf_loader: add account_data_region_memory_state helper
Shared between serialization and CPI to figure out the MemoryState of an
account.
* cpi: direct_mapping: error out if ref_to_len_in_vm points to account memory
If ref_to_len_in_vm is allowed to be in account memory, calles could mutate it,
essentially letting callees directly mutate callers memory.
* bpf_loader: direct_mapping: map AccessViolation -> InstructionError
Return the proper ReadonlyDataModified / ExecutableDataModified /
ExternalAccountDataModified depending on where the violation occurs
* bpf_loader: cpi: remove unnecessary infallible slice::get call
* dereplicode address alignment check
* Uses `checked_div` and `checked_rem` in built-in loaders.
* Uses `checked_div` and `checked_rem`.
* sdk: replace sub() with saturating_sub()
* eliminate `String` "arithmetic"
* allow arithmetic side-effects in tests and benches and on types we don't control
---------
Co-authored-by: Trent Nelson <trent@solana.com>
Brooks
Lucas Steuernagel
Alexander Meißner
Justin Starry
samkim-crypto
Tao Zhu
Alessandro Decina
HaoranYi
Pankaj Garg
Andrew Fitzgerald
Brooks
Justin Starry
Sanjay Singh
ananas-block
Christian Kamm
behzad nouri
vadorovsky