XCM: Deny barrier checks for nested XCMs with specific instructions to be executed on the local chain #7200

bkontur · 2025-01-16T10:53:39Z

Resolves (partially): #7148
Depends on: #7169

Description

This PR addresses partially #7148 (Problem 2) and ensures the proper checking of nested local instructions. It introduces a new barrier - DenyRecursively - to provide more refined control over instruction denial. The main change is the replacement of DenyThenTry<Deny, Allow> with DenyThenTry<DenyRecursively<Deny>, Allow> which handles both top-level and nested local instructions by applying allow condition after denial.

For context and additional information, please refer to Problem 2 - Barrier vs nested XCM validation.

TODO

Evaluate PoC, more details at poc(XCM): Deny Nested XCM Barriers #7351:

DenyNestedXcmInstructions: Keep it as it is and be explicit:
1. Name the Deny barriers for the top level.
2. Name the Deny barrier for nested with DenyInstructionsWithXcm.
DenyThenTry<DenyInstructionsWithXcm, Allow>: Alternatively, hard-code those three instructions in DenyThenTry, so we wouldn’t need DenyInstructionsWithXcm. However, this approach wouldn’t be as general.
DenyInstructionsWithXcmFor: Another possibility is to check DenyInstructionsWithXcm::Inner for the actual message, so we don’t need duplication for top-level and nested (not sure, maybe be explicit is good thing) - see Problem2 - example. Instead of this:

DenyThenTry<
             (
                            // Deny for top level XCM program 
                            DenyReserveTransferToRelayChain,
                            // Dedicated barrier for nested XCM programs
                            DenyInstructionsWithXcmFor<
                                             // Repeat all Deny filters here 
                                             DenyReserveTransferToRelayChain,
                             >
             ),

we could just use:

DenyThenTry<
             (
                            // Dedicated barrier for XCM programs
                            DenyInstructionsWithXcmFor<
                                             // Add all `Deny` filters here 
                                             DenyReserveTransferToRelayChain,
                                             ...
                             >
             ),

POC Evaluation
Consider better name DenyInstructionsWithXcm => DenyRecursively, more details at here
Clean-up and docs
Merge xcm: fix for DenyThenTry Barrier #7169 or rebase this branch on the top of yrong:fix-for-deny-then-try
Set for the runtimes where we use DenyThenTry<Deny, Allow> => DenyThenTry<DenyRecursively<Deny>, Allow>
Schedule sec.audit

…tytech/polkadot-sdk into bko-deny-nested-xcm-barrier

polkadot/xcm/xcm-builder/src/barriers.rs

raymondkfcheung · 2025-01-29T10:43:40Z

/cmd fmt

raymondkfcheung · 2025-01-29T14:39:56Z

/cmd fmt

polkadot/xcm/xcm-builder/src/tests/barriers.rs

Resolves (partially): #7148 Depends on: #7169, #7200 # Description For context and additional information, please refer to #7148 and #7200. # TODOs * [x] Rebase #7169 and #7200 * [x] Evaluate PoC described on #7200 | POC | Top-Level Denial | Nested Denial | Try `Allow` | Remark | |--------------------------------|--------------------|--------------------|--------------------|----------------------------------------------------------------------------------| | `DenyThenTry` | ✅ | ❌ | ✅ | Blocks top-level instructions only. | | `RecursiveDenyThenTry` | ✅ | ✅ | ✅ | Blocks both top-level and nested instructions. | | `DenyInstructionsWithXcm` | ❌ | ✅ | ❌ | Focuses on nested instructions, requires additional checks for top-level denial. | | `DenyFirstInstructionsWithXcm` | ✅ | ✅ | ❌ | Prioritises top-level denial before recursive checks. | --------- Co-authored-by: ron <[email protected]> Co-authored-by: Branislav Kontur <[email protected]> Co-authored-by: Francisco Aguirre <[email protected]> Co-authored-by: command-bot <> Co-authored-by: Clara van Staden <[email protected]> Co-authored-by: Adrian Catangiu <[email protected]> Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

raymondkfcheung · 2025-01-31T14:48:27Z

polkadot/xcm/xcm-builder/src/tests/barriers.rs

+	// `DenyThenTry`: Top-level=Deny, Nested=Allow, TryAllow=Yes
+	assert_barrier::<DenyThenTry<Denies, AllowAll>>(Err(ProcessMessageError::Unsupported), Ok(()));
+
+	// `RecursiveDenyThenTry`: Top-level=Deny, Nested=Deny, TryAllow=Yes
+	assert_barrier::<RecursiveDenyThenTry<Denies, AllowAll>>(
+		Err(ProcessMessageError::Unsupported),
+		Err(ProcessMessageError::Unsupported),
+	);
+
+	// `DenyInstructionsWithXcm`: Top-level=Allow, Nested=Deny, TryAllow=No
+	assert_deny_barrier::<DenyInstructionsWithXcm<Denies>>(
+		Ok(()),
+		Err(ProcessMessageError::Unsupported),
+	);
+
+	// `DenyFirstInstructionsWithXcm`: Top-level=Deny, Nested=Deny, TryAllow=No
+	assert_deny_barrier::<DenyFirstInstructionsWithXcm<Denies>>(
+		Err(ProcessMessageError::Unsupported),
+		Err(ProcessMessageError::Unsupported),
+	);


POC Evaluation

Redefine DenyThenTry as RecursiveDenyThenTry: blocks both top-level and nested instructions, before trying to allow execution.

Create a new DenyFirstInstructionsWithXcm: blocks both top-level and nested instructions.

Establish a helper DenyInstructionsWithXcm, handles nested denies.

Updated to match the latest implementations:

PoC Top-Level Denial Nested Denial Try Allow Remark

DenyThenTry<Deny, Allow> ✅ ❌ ✅ Blocks only top-level instructions, allowing nested ones unless denied elsewhere.

DenyThenTry<DenyRecursively<Deny>, Allow> ✅ ✅ ✅ Blocks both top-level and nested local instructions, then applies the allow condition.

DenyRecursively<Deny> ✅ ✅ ❌ Blocks both top-level and nested local instructions, without attempting to allow execution.

franciscoaguirre · 2025-02-13T18:50:34Z

polkadot/xcm/xcm-builder/src/barriers.rs

+				Ok(())
+			})
+			// Fallback safety in case of an unexpected failure.
+			.unwrap_or(Ok(()))?;


Don't we want to propagate this error? I'm confused by the double error

This unwrap_or(Ok(())) fallback pattern is used elsewhere in the codebase (see search results). While it's intended as a safety measure, let's discuss whether a more robust approach might be preferable.

I think the Result<Result<ControlFlow<()>, ProcessMessageError>, ProcessMessageError> could be flattened to Result<ControlFlow<()>, ProcessMessageError>

There are 3 return "branches" this fn should take:

Err(ProcessMessageError::StackLimitReached) in case of too much recursion -> message denied by barrier

Self::deny_execution(origin, xcm.inner_mut(), max_weight, properties)?; -> shortcircuits with Err(deny_reason) if current recursion layer returns Err.

Ok(ControlFlow::Continue(())) otherwise

Refactored the code to make it more readable, pls check.

franciscoaguirre · 2025-02-13T19:06:46Z

polkadot/xcm/xcm-builder/src/barriers.rs

+///
+/// Note: Ensures that restricted instructions do not execute on the local chain, enforcing stricter
+/// execution policies, while allowing remote chains to enforce their own rules.
+pub struct DenyLocalInstructions<Inner>(PhantomData<Inner>);


Isn't DenyRecursively a better name? I understand that this only recurses to the nested xcms in SetAppendix, SetErrorHandler and ExecuteWithOrigin and not InitiateTransfer for example, but we could just clarify that in the docs.

We never deny stuff inside a remote_xcm. We always expect that to be filtered by the destination's barrier

The current name doesn't even mention recursion.

DenyRecursively might be clearer. We discussed DenyLocalInstructions with @acatangiu and @bkontur, focusing on local instructions, but I'm happy to revisit the name if the team prefers DenyRecursively (or another suggestion).

I agree, DenyLocalInstructions is confusing when read at the barrier config level. DenyRecursively is more explicit in its intent.

I support renaming to DenyRecursively

Renamed to DenyRecursively

polkadot/xcm/xcm-builder/src/tests/barriers.rs

franciscoaguirre · 2025-02-13T19:15:20Z

polkadot/xcm/xcm-builder/src/tests/barriers.rs

+
+// Dummy filter which wraps `DenyExecution` on `ShouldExecution`
+struct DenyWrapper<Deny: ShouldExecute>(PhantomData<Deny>);
+impl<Deny: ShouldExecute> DenyExecution for DenyWrapper<Deny> {


What is this? It's kind of confusing to just call should_execute but call the method deny_execution. Beats the purpose of having two traits

DenyWrapper is a testing helper that wraps the ShouldExecute trait. With the introduction of the DenyExecution trait in #7169, I added this wrapper to simplify tests. I'll investigate cleaner ways to handle this testing logic.

Renamed to Executable to hopefully reduce the confusion around its purpose.

Co-authored-by: Francisco Aguirre <[email protected]>

polkadot/xcm/xcm-builder/src/barriers.rs

acatangiu · 2025-02-17T17:30:24Z

polkadot/xcm/xcm-builder/src/barriers.rs

+///
+/// Note: Ensures that restricted instructions do not execute on the local chain, enforcing stricter
+/// execution policies, while allowing remote chains to enforce their own rules.
+pub struct DenyLocalInstructions<Inner>(PhantomData<Inner>);


I agree, DenyLocalInstructions is confusing when read at the barrier config level. DenyRecursively is more explicit in its intent.

I support renaming to DenyRecursively

acatangiu · 2025-02-17T17:38:25Z

polkadot/xcm/xcm-builder/src/barriers.rs

+				Ok(())
+			})
+			// Fallback safety in case of an unexpected failure.
+			.unwrap_or(Ok(()))?;


I think the Result<Result<ControlFlow<()>, ProcessMessageError>, ProcessMessageError> could be flattened to Result<ControlFlow<()>, ProcessMessageError>

There are 3 return "branches" this fn should take:

Err(ProcessMessageError::StackLimitReached) in case of too much recursion -> message denied by barrier

Self::deny_execution(origin, xcm.inner_mut(), max_weight, properties)?; -> shortcircuits with Err(deny_reason) if current recursion layer returns Err.

Ok(ControlFlow::Continue(())) otherwise

acatangiu · 2025-02-17T17:43:46Z

prdoc/pr_7200.prdoc

+    This PR addresses partially #7148 (Problem 2) and ensures the proper checking
+    of nested local instructions. It introduces a new barrier -
+    `DenyLocalInstructions` - to provide more refined control over instruction
+    denial. The main change is the replacement of `DenyThenTry<Deny, Allow>` with
+    `DenyThenTry<DenyLocalInstructions<Deny>, Allow>` which handles both top-level
+    and nested local instructions by applying allow condition after denial.


Please reword this to be clear to the reader without having to go read github issues (don't reference issue numbers).

You can reuse most of the documentation of the new DenyRecursively type here and should be good.

Updated, pls check.

Co-authored-by: Adrian Catangiu <[email protected]>

polkadot/xcm/xcm-builder/src/barriers.rs

bkontur · 2025-02-18T14:09:39Z

polkadot/xcm/xcm-builder/src/barriers.rs

+				}
+				*count = count.saturating_add(1);
+				Some(())
+			}).flatten().ok_or(ProcessMessageError::StackLimitReached)?;


@raymondkfcheung let's do this also for: https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/xcm-executor/src/lib.rs#L803

bkontur added T6-XCM This PR/Issue is related to XCM. C1-mentor A task where a mentor is available. Please indicate in the issue who the mentor could be. labels Jan 16, 2025

bkontur mentioned this pull request Jan 21, 2025

[Snowbridge]: Ensure source always from AH for exported message #6838

Draft

3 tasks

bkontur linked an issue Jan 21, 2025 that may be closed by this pull request

[XCM] Investigate better support for filtering XCM programs with Barrier #7148

Open

PoC: DenyInstructionsWithXcm for validating nested XCM instructions

9c80770

bkontur force-pushed the bko-deny-nested-xcm-barrier branch from 2c6325f to 9c80770 Compare January 22, 2025 09:31

bkontur added the C2-good-first-issue A task for a first time contributor to become familiar with the Polkadot-SDK. label Jan 22, 2025

bkontur assigned bkontur and unassigned bkontur Jan 22, 2025

raymondkfcheung self-assigned this Jan 23, 2025

raymondkfcheung mentioned this pull request Jan 27, 2025

poc(XCM): Deny Nested XCM Barriers #7351

Merged

2 tasks

bkontur and others added 4 commits January 28, 2025 09:35

PoC: DenyInstructionsWithXcm for validating nested XCM instructions

6c79a06

Merge branch 'bko-deny-nested-xcm-barrier' of https://github.com/pari…

a98fc0d

…tytech/polkadot-sdk into bko-deny-nested-xcm-barrier

Merge branch 'master' into bko-deny-nested-xcm-barrier

a70881e

Fix merge conflicts

72bec5b

raymondkfcheung reviewed Jan 29, 2025

View reviewed changes

polkadot/xcm/xcm-builder/src/barriers.rs Outdated Show resolved Hide resolved

Merge branch 'master' into bko-deny-nested-xcm-barrier

7aec7fe

github-actions bot and others added 3 commits January 29, 2025 10:46

Update from raymondkfcheung running command 'fmt'

6f60579

Fix merge conflicts

06c7e65

Merge branch 'master' into bko-deny-nested-xcm-barrier

7bd8e10

Update from raymondkfcheung running command 'fmt'

2d3d33d

raymondkfcheung reviewed Jan 29, 2025

View reviewed changes

polkadot/xcm/xcm-builder/src/tests/barriers.rs Outdated Show resolved Hide resolved

raymondkfcheung and others added 2 commits January 31, 2025 13:41

Merge branch 'master' into bko-deny-nested-xcm-barrier

797f868

raymondkfcheung reviewed Jan 31, 2025

View reviewed changes

raymondkfcheung added 3 commits January 31, 2025 16:59

Refactor DenyInstructionsWithXcm with new NestedXcmType

72f8fe4

Rename to DenyNestedLocalInstructions

5fe41bc

Remove NestedXcmType

95ce08d

raymondkfcheung mentioned this pull request Feb 11, 2025

Add EventEmitter to XCM executor. #7234

Open

raymondkfcheung added 2 commits February 12, 2025 14:59

Merge branch 'master' into bko-deny-nested-xcm-barrier

a5aaee8

Merge branch 'master' into bko-deny-nested-xcm-barrier

a9dc849

franciscoaguirre reviewed Feb 13, 2025

View reviewed changes

raymondkfcheung and others added 7 commits February 13, 2025 19:31

Update polkadot/xcm/xcm-builder/src/tests/barriers.rs

106561a

Co-authored-by: Francisco Aguirre <[email protected]>

Merge branch 'master' into bko-deny-nested-xcm-barrier

c8e5879

Add DenyNothing

3b945a7

Rename to Executable

79f45bb

Merge branch 'master' into bko-deny-nested-xcm-barrier

cf235c1

Merge branch 'master' into bko-deny-nested-xcm-barrier

813d652

Merge branch 'master' into bko-deny-nested-xcm-barrier

5abd904

acatangiu reviewed Feb 17, 2025

View reviewed changes

raymondkfcheung and others added 9 commits February 18, 2025 10:46

Merge branch 'master' into bko-deny-nested-xcm-barrier

ab72d64

Update polkadot/xcm/xcm-builder/src/barriers.rs

7170543

Co-authored-by: Adrian Catangiu <[email protected]>

Rename to DenyRecursively

19ef51c

Update PR Doc

51e9c12

Merge branch 'master' into bko-deny-nested-xcm-barrier

1c21271

Update comments

d75ce48

Flat the return of deny_recursively

488636c

Use flatten

5ab11b9

Revert to use unwrap_or

f208bae

raymondkfcheung reviewed Feb 18, 2025

View reviewed changes

polkadot/xcm/xcm-builder/src/barriers.rs Outdated Show resolved Hide resolved

raymondkfcheung and others added 3 commits February 18, 2025 13:08

Update comments

ff42492

Fix format

1faaaf0

minor refactor

acc8570

acatangiu approved these changes Feb 18, 2025

View reviewed changes

bkontur commented Feb 18, 2025

View reviewed changes

raymondkfcheung added 3 commits February 18, 2025 14:31

Merge branch 'master' into bko-deny-nested-xcm-barrier

e74fc03

Use flatten

3268565

Merge branch 'master' into bko-deny-nested-xcm-barrier

8a76030

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

XCM: Deny barrier checks for nested XCMs with specific instructions to be executed on the local chain #7200

XCM: Deny barrier checks for nested XCMs with specific instructions to be executed on the local chain #7200

bkontur commented Jan 16, 2025 •

edited by raymondkfcheung

Loading

raymondkfcheung commented Jan 29, 2025

raymondkfcheung commented Jan 29, 2025

raymondkfcheung Jan 31, 2025

raymondkfcheung Feb 3, 2025 •

edited

Loading

franciscoaguirre Feb 13, 2025

raymondkfcheung Feb 14, 2025

acatangiu Feb 17, 2025

raymondkfcheung Feb 18, 2025

franciscoaguirre Feb 13, 2025

raymondkfcheung Feb 14, 2025

acatangiu Feb 17, 2025

raymondkfcheung Feb 18, 2025

franciscoaguirre Feb 13, 2025

raymondkfcheung Feb 14, 2025

raymondkfcheung Feb 14, 2025

acatangiu Feb 17, 2025

acatangiu Feb 17, 2025

acatangiu Feb 17, 2025

raymondkfcheung Feb 18, 2025

bkontur Feb 18, 2025

raymondkfcheung Feb 18, 2025

PoC	Top-Level Denial	Nested Denial	Try Allow	Remark
`DenyThenTry<Deny, Allow>`	✅	❌	✅	Blocks only top-level instructions, allowing nested ones unless denied elsewhere.
`DenyThenTry<DenyRecursively<Deny>, Allow>`	✅	✅	✅	Blocks both top-level and nested local instructions, then applies the allow condition.
`DenyRecursively<Deny>`	✅	✅	❌	Blocks both top-level and nested local instructions, without attempting to allow execution.

XCM: Deny barrier checks for nested XCMs with specific instructions to be executed on the local chain #7200

Are you sure you want to change the base?

XCM: Deny barrier checks for nested XCMs with specific instructions to be executed on the local chain #7200

Conversation

bkontur commented Jan 16, 2025 • edited by raymondkfcheung Loading

Description

TODO

raymondkfcheung commented Jan 29, 2025

raymondkfcheung commented Jan 29, 2025

Choose a reason for hiding this comment

raymondkfcheung Feb 3, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bkontur commented Jan 16, 2025 •

edited by raymondkfcheung

Loading

raymondkfcheung Feb 3, 2025 •

edited

Loading