Skip to content

Commit 3d2c8c0

Browse files
agusduhamds1
agusduha
and
mds1
authored
feat: add interop access list FMA (#252)
* feat: add interop access list FMA * fix: merge FM1 and FM5, remove FM3 and FM4 * feat: add new unexpected storage warming FM * fix: add initial reviewer * fix: FM2 * fix: change status Co-authored-by: Matt Solomon <[email protected]> --------- Co-authored-by: Matt Solomon <[email protected]>
1 parent c11e240 commit 3d2c8c0

File tree

1 file changed

+107
-0
lines changed

1 file changed

+107
-0
lines changed

‎security/fma-interop-access-list.md

+107
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,107 @@
1+
# Interop Access List: Failure Modes and Recovery Path Analysis
2+
3+
| Author | Agusduha, Skeletor-spaceman |
4+
| ------------------- | ---------------------------- |
5+
| Created at | 2025-02-05 |
6+
| Initial Reviewers | Mark Tyneway |
7+
| Needs Approval From | Matt Solomon, Kelvin Fichter |
8+
| Status | Implementing Actions |
9+
10+
## Introduction
11+
12+
This document covers the failure modes and recovery paths for the access list validation mechanism in cross-chain message processing. The access list enhancement aims to prevent denial of service (DoS) attacks and enable cheap pre-validation of cross-chain messages.
13+
14+
The following components are included:
15+
16+
- **Contracts**:
17+
- Updates to `CrossL2Inbox`: Implements gas introspection to validate `ExecutingMessage` transactions
18+
- Storage slot warming mechanism for message validation
19+
- Checksum calculation and verification logic
20+
21+
Below are references for this project:
22+
23+
- Design PR: [Access List design](https://github.com/ethereum-optimism/design-docs/pull/214)
24+
- Specs PR: [Access List spec](https://github.com/ethereum-optimism/specs/pull/612)
25+
26+
## Failure Modes and Recovery Paths
27+
28+
### FM1: Gas Introspection Breaks Due to EVM Changes or Compiler Optimizations
29+
30+
- **Description:** The validation mechanism relies on gas introspection to determine if storage slots are warm. This can break in two ways:
31+
1. If the EVM's gas schedule changes, particularly around storage access costs, it could break the validation logic
32+
2. Future changes in the Solidity compiler, via-IR pipeline, or optimizer settings could eliminate or modify the `SLOAD` operation used for gas introspection, causing the contract to incorrectly determine that a cold storage slot is warm
33+
- **Risk Assessment:** High
34+
- Potential Impact: Critical. Changes to gas costs or optimized-away operations could cause all cross-chain message validation to fail or allow invalid messages to pass.
35+
- Likelihood: Medium. While gas schedule changes are rare, they do occur during network upgrades. Additionally, compiler optimizations regularly evolve and could unexpectedly affect low-level gas introspection.
36+
- **Mitigations:**
37+
- Set `WARM_READ_THRESHOLD` conservatively to account for potential fluctuations
38+
- Lock compiler version and optimization settings
39+
- Document compiler dependencies, optimization constraints, and gas schedule dependencies
40+
- Implement end-to-end tests that verify validation reverts work correctly in a real environment
41+
- Regular bytecode verification to ensure `SLOAD` operations remain in place
42+
- **Detection:**
43+
- Monitor for network upgrades that modify storage access gas costs
44+
- Regular bytecode verification to ensure `SLOAD` operations remain in place
45+
- End-to-end test suite that verifies validation reverts as expected
46+
- Run validation tests before accepting upgrades
47+
- **Recovery Path(s):**
48+
- Deploy contract upgrade with adjusted thresholds if gas schedule changes significantly
49+
- Roll back to previous compiler version if optimization cannot be disabled
50+
51+
### FM2: Storage Slot Collision
52+
53+
- **Description:** The checksum calculation for message validation uses storage slots that could potentially collide with other slots from the access list, leading to false validation of messages.
54+
- **Risk Assessment:** High
55+
- Potential Impact: Critical. Storage collisions could allow unauthorized messages to be validated. Additionally, this would break the ability to filter invalid executing messages at ingress, creating a spam vector where MEV searchers could attempt arbitrage by submitting invalid messages with no inclusion cost.
56+
- Likelihood: Extremely Low. Storage slots are calculated using a 248-bit (31 byte) hash space, providing cryptographically secure collision resistance. A collision would require finding a hash collision, which makes it infeasible to have a collision as long as the implementation is correct.
57+
- **Mitigations**
58+
- Implement robust checksum calculation that minimizes collision risk
59+
- Add tests verifying no collisions occur with expected storage patterns
60+
- Document storage layout and slot calculation methodology
61+
- **Detection:** Monitor for unexpected message validations that could indicate storage collisions.
62+
- **Recovery Path(s):** Deploy contract upgrade with revised storage slot calculation if collisions are detected and update ALL off-chain tools and SDKs that generate these hashes on the access list.
63+
64+
### FM3: Unexpected Storage Slot Warming Behavior
65+
66+
- **Description:** The validation mechanism assumes that storage slots are only warmed through the transaction's access list and that warming is rolled back on revert. However, this behavior relies on EVM implementation details that aren't explicitly guaranteed by the protocol. Several potential issues arise:
67+
1. A slot could be warmed through other means than the access list
68+
2. The current behavior where slot warming is rolled back on revert isn't guaranteed by the protocol spec - it's an implementation detail that could change, as cached values theoretically could persist after reverts
69+
3. Storage warming is currently scoped per transaction, but future EVM updates could change this to be per block, which would break the security assumption that each transaction's access list independently controls its warm slots
70+
- **Risk Assessment:** High
71+
- Potential Impact: Critical. If slots remain warm after reverts, can be warmed through alternative means, or warming persists across transactions in a block, it could allow unauthorized messages to be validated, bypassing the access list requirement entirely.
72+
- Likelihood: Low. While the current behavior is stable, it relies on implementation details rather than protocol guarantees.
73+
- **Mitigations:**
74+
- Document reliance on EVM warming behavior in reverts
75+
- Add tests specifically verifying slot cooling behavior after reverts across multiple EVM clients
76+
- Document dependency on per-transaction warming scope
77+
- Monitor EIP proposals that could affect storage warming mechanics
78+
- **Detection:**
79+
- Regular testing of slot warming behavior across multiple EVM clients, especially after network upgrades
80+
- Monitor for unexpected successful message validations
81+
- Track EVM changes that could affect storage slot warming mechanics or scope
82+
- Test that warm slots from previous transactions in a block don't affect current transaction
83+
- **Recovery Path(s):** Deploy contract upgrade with alternative validation mechanism if EVM warming behavior changes
84+
85+
### Generic items we need to take into account:
86+
87+
See [fma-generic-contracts.md](https://github.com/ethereum-optimism/design-docs/blob/main/security/fma-generic-contracts.md).
88+
89+
- [x] Check this box to confirm that these items have been considered and updated if necessary.
90+
91+
## Action Items
92+
93+
- [ ] FM1: Document gas schedule dependencies
94+
- [ ] FM1: Implement comprehensive gas schedule testing
95+
- [ ] FM2: Create storage layout documentation
96+
- [ ] FM2: Implement slots collision tests
97+
- [ ] FM3: Document EVM warming behavior dependencies and transaction-scoped assumptions
98+
- [ ] FM3: Implement comprehensive slot warming behavior tests including multi-transaction tests
99+
100+
## Audit Requirements
101+
102+
The access list validation mechanism in `CrossL2Inbox` requires an audit before production deployment, with particular focus on:
103+
104+
- Gas introspection implementation
105+
- Storage slot calculation and collision resistance
106+
- Access list validation logic
107+
- Integration with existing message passing system

0 commit comments

Comments
 (0)