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

[bkontur]

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

Description

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:
  • DenyInstructionsWithXcm: 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.
  • RecursiveDenyThenTry: Alternatively, hard-code those three instructions in DenyThenTry, so we wouldn’t need DenyInstructionsWithXcm. However, this approach wouldn’t be as general.
  • DenyFirstInstructionsWithXcm: 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
• 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
• Schedule sec.audit

[raymondkfcheung]

Regarding the naming, maybe we can use DenyNestedXcmInstructions, which may be better to state clearly with nested XCMs.

[bkontur]

I think DenyNestedXcmInstructions is a better name, but we still need to ensure it's explicitly used only for the following instructions: SetAppendix, SetErrorHandler, and ExecuteWithOrigin—which are meant to be executed on the local chain.

This is important because there are other instructions with nested XCM, such as DepositReserveAsset { xcm: Xcm<()>, ... } and InitiateReserveWithdraw { xcm: Xcm<()>, ... }, where the inner xcm is executed on a remote chain.

[raymondkfcheung]

Good point! If we want to check all nested XCM instructions recursively (including those executed remotely), we could rename it to DenyNestedXcmInstructions and adjust the logic accordingly.

However, since this implementation currently applies only to instructions executed on the local chain (SetAppendix, SetErrorHandler, and ExecuteWithOrigin), we could instead introduce two separate types for clarity:

• DenyNestedLocalInstructions: Covers only local execution cases (current behavior).
• DenyNestedRemoteInstructions: Specifically targets instructions like DepositReserveAsset and InitiateReserveWithdraw, ensuring remote execution filtering.

Would this separation make sense, or do you think a more unified approach is preferable?

[acatangiu]

DenyNestedRemoteInstructions: Specifically targets instructions like DepositReserveAsset and InitiateReserveWithdraw, ensuring remote execution filtering.

Generally, a local chain should not assume rules about other chains' rules/barriers.

The design is that each chain only enforces its own local rules.

It is the job of the offchain component (wallet/ui/app) building the XCM to validate (e.g. through XCM dry-run APIs) that the XCM they build will pass barriers on all involved chains.

[raymondkfcheung]

I've defined a new NestedXcmType when performing the deny execution. This categorises nested XCM calls as either Local or Remote, ensuring we handle them separately.

Right now, both types go through deny_recursively, but I can implement two different denial strategies (DenyNestedLocalInstructions and DenyNestedRemoteInstructions) if needed. Let me know if you see any difference in behavior, or if you'd prefer keeping a single DenyNestedXcmInstructions that applies to both.

Or shall I use origin: &Location to determine whether it's Local or Remote? If it's Remote, then I could deny all location-based instructions.

[raymondkfcheung]

/cmd fmt

[raymondkfcheung]

/cmd fmt

[raymondkfcheung]

DenyInstructionsWithXcm can't reject the top level Deny barrier. Other two approaches (#7351) can deny earlier.

[raymondkfcheung]

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.

[paritytech-workflow-stopper]

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/13077258725
Failed job name: build-rustdoc