Multi-Context Resource Access Security with Ruleset Firewalls

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing software reverse engineering (SRE) techniques lack effective mechanisms to securely control access to memory and secure intellectual property resources, particularly in systems with multiple software contexts, leading to potential unauthorized access and tampering.

Innovation Solution

A system with a processor configured to operate in multiple software contexts, featuring a context manager, security circuitry, and firewalls to manage access requests based on authorization rulesets, ensuring secure access to specific software contexts and preventing unauthorized access during context switches.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If a debugger tool is given access to memories and secure resources in a trusted island for software reverse engineering, then the ability to analyze and understand the system is improved, but the security and protection of intellectual property resources deteriorates

Engineering Contradiction:
Improvesoftware reverse engineering capabilityVSAvoidsecurity protection of resources
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The system divides the debugging access control into multiple segments: a context manager that tracks software contexts, security circuitry that stores and evaluates authorization rulesets for different contexts, and a firewall that enforces access decisions. This segmentation allows different security policies to be applied to different software contexts, enabling reverse engineering of authorized contexts while protecting unauthorized ones.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The security circuitry acts as an intermediary between the debugger tool and the protected resources. It receives access requests from the debugger, evaluates them against context-specific authorization rulesets stored in its memory, and only grants access when the current software context matches an authorized context. This intermediary layer prevents direct unauthorized access while allowing legitimate reverse engineering activities.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If access control is implemented for multiple software contexts, then the security protection against unauthorized access is improved, but the system complexity increases

Engineering Contradiction:
Improveaccess control securityVSAvoidsystem architecture complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent combines multiple security functions into a single integrated security circuitry block: context tracking, ruleset storage, access request evaluation, and firewall control all reside in one hardware component. This merging reduces overall system complexity compared to having separate security modules for each function, while still providing comprehensive multi-context access control.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The context manager automatically tracks the current software context and provides this information to the security circuitry without requiring manual intervention. The security circuitry itself manages the storage and retrieval of authorization rulesets, and the firewall automatically enforces access decisions based on the evaluated context. This self-service automation reduces operational complexity while maintaining strong security controls.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS20250328660A1Resource access security for multiple software contexts
Publication Date: 2025.10.23 TEXAS INSTRUMENTS INC
  • US20250328660A1 patent drawing
  • US20250328660A1 patent drawing
  • US20250328660A1 patent drawing

AI summary

In an example, a system includes a processor, security circuitry, and a firewall. In operation, the processor executes in one of multiple software contexts, each of which has a respective software context identification (ID). The processor identifies the current software context currently operating and so indicates that to the security circuitry. The security circuitry stores multiple authorization rulesets for the multiple software contexts, respectively, each of which is associated with a corresponding one of the software context IDs. In response to an access request that includes a specified software context ID and an identification of target resource(s) to be accessed, the security circuitry determines which of the target resource(s) the access request is allowed to access based on the authorization ruleset for the specified software context ID. The firewall allows or denies access to the target resource(s) based on a signal from the security circuitry.