From 9270bcc5004c54feb3adedcdd57e0a4063e71a62 Mon Sep 17 00:00:00 2001 From: agusduha Date: Wed, 2 Apr 2025 16:43:49 -0300 Subject: [PATCH 1/2] fix: finalize Msg Passing FMA --- security/fma-message-passing-contracts.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/security/fma-message-passing-contracts.md b/security/fma-message-passing-contracts.md index 6c696a36..df4bd29e 100644 --- a/security/fma-message-passing-contracts.md +++ b/security/fma-message-passing-contracts.md @@ -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 @@ -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. +- [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)) - [ ] 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] 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 From f4a37085f4b5c6ae76f0da4417212779ec904ae0 Mon Sep 17 00:00:00 2001 From: agusduha Date: Fri, 11 Apr 2025 11:38:19 -0300 Subject: [PATCH 2/2] fix: complete action item --- security/fma-message-passing-contracts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/fma-message-passing-contracts.md b/security/fma-message-passing-contracts.md index df4bd29e..9ed28800 100644 --- a/security/fma-message-passing-contracts.md +++ b/security/fma-message-passing-contracts.md @@ -120,7 +120,7 @@ See [fma-generic-contracts.md](https://github.com/ethereum-optimism/design-docs/ - [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)) -- [ ] FM3: Check for any L2Beat Stage 1 considerations related to the inability to successfully call `validateMessage` as part of a force-include a transaction. +- [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)