Capability Management for Exception Level Flexibility

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Capability-based architectures face challenges in providing flexibility to allow certain software to operate unconstrained by capabilities, while maintaining security and functional correctness, especially in scenarios requiring backwards compatibility and efficient performance.

Innovation Solution

A processing circuitry operable at multiple exception levels with capability storage elements and configuration storage that allows varying the effects of capabilities on a per-exception level basis, enabling software to operate unconstrained when necessary, while ensuring constraints are maintained where required, through mechanisms for switching between exception levels and managing return address and program counter information.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If capability-based architecture is implemented to maintain security and functional correctness, then security and reliability are improved, but flexibility and performance are worsened due to constrained operations

Engineering Contradiction:
ImprovesecurityVSAvoidflexibility
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The system dynamically switches between capability-constrained mode and capability-unconstrained mode based on the exception level and software trust status. Processing circuitry can operate with capability constraints enforced at some exception levels while allowing unconstrained execution at others, enabling adaptive security management that balances security requirements with performance and flexibility needs.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system segments the execution environment into multiple exception levels with different capability enforcement policies. Each exception level can have independent capability configuration, allowing trusted software at higher exception levels to operate unconstrained while maintaining security constraints at lower levels. This segmentation enables selective application of capability checks to specific code regions or privilege levels.

Inventive Principle:
Principle #1Segmentation

2Reliability

If capability checking is enforced for all operations, then security is improved, but performance is worsened due to additional verification overhead

Engineering Contradiction:
ImprovesecurityVSAvoidperformance
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The system applies capability checking partially rather than universally. Capability constraints are enforced only when necessary based on the exception level and software trust status, rather than applying checks to all operations at all times. This partial application of capability verification reduces overhead for trusted software while maintaining security where required.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

Different capability enforcement policies are applied to different exception levels and software contexts. Trusted software operating at higher exception levels experiences relaxed or disabled capability checking, while less trusted software at lower exception levels undergoes strict capability verification. This local differentiation of security policy quality optimizes performance for trusted code while maintaining security for untrusted code.

Inventive Principle:
Principle #3Local quality

3Stability of the object's composition

If capability constraints are applied uniformly across all exception levels, then security consistency is improved, but adaptability is worsened due to inability to allow trusted software to operate unconstrained

Engineering Contradiction:
Improvesecurity consistencyVSAvoidadaptability
Core Design Contradiction:
Stability of the object's compositionVSAdaptability or versatility

Solution Approach 1:

The capability enforcement policy is dynamic rather than static, changing based on the current exception level and software trust status. The system can adaptively enable or disable capability constraints as execution transitions between exception levels, allowing trusted software to operate in unconstrained modes when appropriate while maintaining security consistency through controlled transitions and proper capability management at each level.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentEP3619606B1An apparatus and method for managing use of capabilities
Publication Date: 2023.12.27 ARM LTD
  • EP3619606B1 patent drawingFigure 1
  • EP3619606B1 patent drawingFigure 2A~2B
  • EP3619606B1 patent drawingFigure 3

AI summary

An apparatus and method are provided for managing use of capabilities. The apparatus has processing circuitry to execute instructions, and a plurality of capability storage elements accessible to the processing circuitry and arranged to store capabilities used to constrain operations performed by the processing circuitry when executing instructions. The processing circuitry is operable at a plurality of exception levels, each exception level having different software execution privilege. Further, capability configuration storage is provided to identify capability configuration information for each of the plurality of exception levels. For each exception level, the capability configuration information identifies at least whether the operations performed by the processing circuitry when executing instructions at that exception level are constrained by capabilities. During a switch operation from a source exception level to a target exception level, the capability configuration information in the capability configuration storage pertaining to at least one of the source exception level and the destination exception level is used to determine how execution state of the processing circuitry is managed during the switch operation. This provides a great deal of flexibility in the management of capabilities.