Two-Layer Execution Environment Isolating Script Context

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing execution environments for custom code in scripting languages like JavaScript face challenges in providing secure, scalable, and platform-independent execution while maintaining high performance and isolating individual script executions, especially due to vulnerabilities from fraudulent code changes and difficulties in migrating between cloud vendors.

Innovation Solution

A two-layer execution environment is implemented, with a lower native layer immune to scripting language attacks and an upper layer in JavaScript for custom code execution. The environment isolates individual script executions by discarding the upper layer after each execution and uses a 'pathfinding' feature to simplify interactions with platform services, and a recursion counter to prevent self-reinvocation, ensuring secure and efficient execution across different cloud platforms.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If the execution environment is reused for multiple script executions to improve performance, then execution speed and throughput are improved, but security is worsened due to potential fraudulent code changes affecting subsequent executions

Engineering Contradiction:

Improveexecution throughputVSAvoidexecution security

Core Design Contradiction:

ProductivityVSReliability

Solution Approach 1:

The execution environment is segmented into two distinct layers: a persistent lower layer (native execution environment) that maintains high performance through reuse, and a temporary upper layer (scripting language execution context) that is discarded after each execution to ensure security. This segmentation allows the system to simultaneously achieve both performance and security requirements.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The problematic scripting language execution context is extracted and separated from the persistent native execution environment. By taking out the upper layer and discarding it after each execution, the system eliminates security risks while preserving the performance benefits of the lower layer through reuse.

Inventive Principle:

Principle #2Taking out (Extraction)

2Reliability

If the execution environment is discarded after each execution to ensure security, then security is improved, but execution performance and startup time are worsened

Engineering Contradiction:

Improveexecution securityVSAvoidexecution performance

Core Design Contradiction:

ReliabilityVSProductivity

Solution Approach 1:

The execution environment is divided into a reusable lower layer and a disposable upper layer. Only the upper layer (containing scripting language-specific components and execution context) is discarded after each execution, while the lower layer (native execution environment with core functionality) is preserved and reused for subsequent executions.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

Different parts of the execution environment have different lifecycle characteristics: the lower layer is designed for persistence and reuse to maintain performance, while the upper layer is designed for temporary use and disposal to ensure security. This local differentiation of quality attributes allows the system to optimize both security and performance simultaneously.

Inventive Principle:

Principle #3Local quality

3Productivity

If cloud vendor specific execution environments are used to achieve high performance, then execution performance is improved, but adaptability is worsened due to difficulty in migrating between cloud vendors

Engineering Contradiction:

Improveexecution performanceVSAvoidcloud platform independence

Core Design Contradiction:

ProductivityVSAdaptability or versatility

Solution Approach 1:

A portable intermediary layer (the execution environment with standardized interfaces) is introduced between the cloud vendor specific infrastructure and the customer code. This intermediary abstracts cloud vendor specifics, allowing customer code to execute on different cloud platforms without modification while maintaining high performance through optimized native execution.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The execution environment is designed with universal interfaces and standardized communication protocols that work across multiple cloud platforms. The lower layer can be adapted to different cloud vendors while maintaining the same API surface, enabling the system to achieve both performance optimization and cloud platform independence.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentUS20250021389A1Codeshield - A Scalable, Performant And Secure Execution Environment For Custom Code

Publication Date: 2025.01.16 DYNATRACE LLC

AI summary

A technology is disclosed for the managed execution of custom scripting code that interacts with services provided by a service provider, where the service provider also provides the environment for the managed code execution. The managed execution environment separates functionality that perform interactions with underlying operating system functionality, like access to remote resources from functionality related to the execution of scripting code. To isolate the state of consecutive script executions while maintaining short startup times and high throughput of the managed execution environment, only functionality related to script execution is discarded after individual executions and functionality related to operation system interaction is reused for multiple executions. Security management, like maintaining access tokens or restricting access to external resources is performed in parts of the execution environment that are protected from undesired access or manipulations by execution of custom scripting code.