Shared Hardware Pipeline Modes for Secure and Insecure Tasks

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Networking devices face challenges in efficiently performing both secure and insecure operations without duplicating hardware, as existing solutions are costly or lack flexibility.

Innovation Solution

Implementing secure and insecure logical interfaces (LIFs) with hardware that maintains secure mode status indicators, allowing tasks to be tagged as secure or insecure, and performing operations in separate environments without duplicating hardware.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If separate hardware entities are used for secure and insecure operations, then security isolation is improved, but device complexity and cost increase

Engineering Contradiction:

Improvesecurity isolationVSAvoidhardware duplication

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The patent segments the hardware entity into different operational modes (secure mode and insecure mode) rather than creating separate physical hardware. This is achieved through mode-specific status indicators and task routing mechanisms that divide the functional space within a single hardware entity, allowing secure and insecure operations to coexist without physical duplication.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The hardware entity is designed to be universal by supporting multiple functions through mode switching. A single hardware entity can perform both secure and insecure operations by changing its operational mode, eliminating the need for dedicated separate hardware for each function and reducing overall device complexity.

Inventive Principle:

Principle #6Universality (Multi-functionality)

2Ease of operation

If secure mode status indicators are used to tag tasks, then task management and security control are improved, but device complexity increases

Engineering Contradiction:

Improvetask managementVSAvoidcontrol circuitry

Core Design Contradiction:

Ease of operationVSDevice complexity

Solution Approach 1:

The patent uses parameter changes through mode-specific status indicators to control task routing and hardware behavior. By changing the operational mode parameter of the hardware entity, the system can route tasks to appropriate resources and adjust security controls without adding complex control logic for each individual task.

Inventive Principle:

Principle #35Parameter changes

3Adaptability or versatility

If hardware entities operate in different modes, then security and flexibility are improved, but resource access control complexity increases

Engineering Contradiction:

ImproveflexibilityVSAvoidresource access control

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The hardware entity dynamically adjusts its resource access permissions based on its operational mode. When transitioning between secure and insecure modes, the hardware automatically enables or disables access to different resource sets through mode-specific status indicators, providing flexible adaptability without requiring complex manual access control mechanisms.

Inventive Principle:

Principle #15Dynamics

Data Source

PatentUS12614001B2Methods and systems for running secure pipeline tasks and insecure pipeline tasks in the same hardware entities

Publication Date: 2026.04.28 PENSANDO SYSTEMS INC

AI summary

A system includes a hardware entity that can perform tasks in a secure mode or in an insecure mode. The system's secure resources include a secure memory and a secure logical interface (LIF). The system's insecure resources include an insecure memory and a first insecure LIF. A security mode circuit in the hardware entity can set the hardware entity to secure mode or to insecure mode. Tasks submitted via the secure LIF are performed in secure mode. Tasks submitted via the insecure LIF are performed in insecure mode. The tasks are associated with security mode status indicators that are written to the hardware entities security mode indicator to thereby set the hardware entity into secure mode or insecure mode. The hardware entity cannot access secure resources while in insecure mode.