Skip to content

fix: finalize Msg Passing FMA #251

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 15, 2025
Merged

fix: finalize Msg Passing FMA #251

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
9270bcc
fix: finalize Msg Passing FMA
agusduha Apr 2, 2025
f4a3708
fix: complete action item
agusduha Apr 11, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 12 additions & 12 deletions security/fma-message-passing-contracts.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@
| Created at | 2025-02-04 |
| Initial Reviewers | AgusDuha |
| Needs Approval From | Michael Amadi, Matt Solomon |
| Status | Implementing Actions |
| Status | Final |

## Introduction

Expand Down Expand Up @@ -117,17 +117,17 @@ See [fma-generic-contracts.md](https://github.com/ethereum-optimism/design-docs/
## Action Items

- [x] Resolve all the comments.
- [ ] FM1: Decide whether to implement any of the mitigation approaches described, either now or in the future.
- [ ] FM1: Decide whether to implement a monitoring solution that tracks when a message is sent to a `destination` that is not part of the dependency set.
- [ ] FM2: Implement a monitoring tool that tracks invalid/non-existent initiated messages.
- [ ] FM3: Check for any L2Beat Stage 1 considerations related to the inability to successfully call `validateMessage` as part of a force-include a transaction.
- [ ] FM3: Implement a mechanism that can execute `validateMessage` that is censorship-resistant to mitigate the current risks, as discussed [here](https://github.com/ethereum-optimism/specs/issues/520).
- [ ] FM3: Implement a monitoring tool that tracks and flags initiated messages that are not relayed despite being ready.
- [ ] FM4: Implement a monitoring tool that alerts when relayed events are repeated.
- [ ] FM5: Implement a monitoring tool that alerts successful reentrancies.
- [ ] FM6: Ensure that the Interop documentation for developers explains the possibility of repeated identifiers being validated during a `validatedMessage`, the role of `L2ToL2CrossDomainMessenger`, and whether replay protections are required, depending on the expected use case when developing custom messengers.
- [ ] Write a FMA for `op-supervisor`, as this component is critical and transversal to many of the cases explained, since its failure could degrade liveness or the safety of interop.
- [ ] Ensure the support team is aware of these failure modes and prepared to respond.
- [x] FM1: Decide whether to implement any of the mitigation approaches described, either now or in the future. (re-introduce the L2 Dependency manager predeploy in the future)
- [x] FM1: Decide whether to implement a monitoring solution that tracks when a message is sent to a `destination` that is not part of the dependency set. (tracked on [Interop Monitoring issue](https://github.com/ethereum-optimism/optimism/issues/15178))
- [x] FM2: Implement a monitoring tool that tracks invalid/non-existent initiated messages. (tracked on [Interop Monitoring issue](https://github.com/ethereum-optimism/optimism/issues/15178))
- [x] FM3: Check for any L2Beat Stage 1 considerations related to the inability to successfully call `validateMessage` as part of a force-include a transaction. (tracked in the [Censorship Resistance issue](https://github.com/ethereum-optimism/specs/issues/520))
- [x] FM3: Implement a mechanism that can execute `validateMessage` that is censorship-resistant to mitigate the current risks, as discussed [here](https://github.com/ethereum-optimism/specs/issues/520).
- [x] FM3: Implement a monitoring tool that tracks and flags initiated messages that are not relayed despite being ready. (tracked on [Interop Monitoring issue](https://github.com/ethereum-optimism/optimism/issues/15178))
- [x] FM4: Implement a monitoring tool that alerts when relayed events are repeated. (Covered by tests no monitoring solution)
- [x] FM5: Implement a monitoring tool that alerts successful reentrancies. (Covered by tests no monitoring solution)
- [x] FM6: Ensure that the Interop documentation for developers explains the possibility of repeated identifiers being validated during a `validatedMessage`, the role of `L2ToL2CrossDomainMessenger`, and whether replay protections are required, depending on the expected use case when developing custom messengers. (The current documentation is in [Interop docs](https://docs.optimism.io/stack/interop/message-passing))
- [x] Write a FMA for `op-supervisor`, as this component is critical and transversal to many of the cases explained, since its failure could degrade liveness or the safety of interop. (Follow in [Supervisor FMA PR](https://github.com/ethereum-optimism/design-docs/pull/233))
- [x] Ensure the support team is aware of these failure modes and prepared to respond.

## Audit Requirements

Expand Down