Cloud Platform Isolating Suspicious Third-Party Code

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Cloud computing platforms face inefficiencies due to high overhead from context switching and slow startup times of containerized processes, leading to laggy requests and increased resource usage, especially when handling third-party code, which can also be vulnerable to speculative execution attacks.

Innovation Solution

Implementing an isolated execution environment that runs multiple third-party codes within a single process, using a sandboxed approach to mitigate speculative execution attacks by restricting access to timers and concurrency, and isolating suspicious code in a separate process to prevent data leakage.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If containerized processes are used to execute third-party code, then isolation and fault tolerance are improved, but startup time and resource overhead increase

Engineering Contradiction:

Improveisolation and fault toleranceVSAvoidstartup time

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

Multiple isolated execution environments are merged into a single shared process, allowing third-party code to run in isolated contexts while sharing the process infrastructure. This combines the isolation benefits of separate processes with the efficiency of a shared process space, eliminating repeated process startup overhead.

Inventive Principle:

Principle #5Merging (Combining)

Solution Approach 2:

The shared process is started in advance and maintains a ready state before requests arrive. Execution environments are pre-configured within this process, so when a request comes in, the code can be executed immediately without the delay of process creation. This preliminary setup eliminates cold-start latency.

Inventive Principle:

Principle #10Preliminary action

2Productivity

If multiple processes are used to handle concurrent requests, then parallel processing capability is improved, but context switching overhead increases

Engineering Contradiction:

Improveparallel processing capabilityVSAvoidcontext switching overhead

Core Design Contradiction:

ProductivityVSLoss of energy

Solution Approach 1:

The system segments the execution space into multiple isolated execution environments within a single process. Each environment maintains its own execution context and memory space for isolation, but all environments share the same process resources. This segmentation provides parallel processing capability without the overhead of process-level context switching.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

A single process is designed to serve multiple functions by hosting multiple isolated execution environments. This universal process can handle different third-party codes concurrently, replacing the need for multiple dedicated processes. The process achieves multi-functionality while minimizing context switching overhead through shared resources.

Inventive Principle:

Principle #6Universality (Multi-functionality)

3Use of energy by moving object

If third-party code is executed in a multi-tenant environment, then resource utilization is improved, but security risks from speculative execution attacks increase

Engineering Contradiction:

Improveresource utilizationVSAvoidsecurity risks

Core Design Contradiction:

Use of energy by moving objectVSObject-affected harmful factors

Solution Approach 1:

Each execution environment within the shared process is given local quality through isolated memory spaces and restricted access controls. Third-party code in one environment cannot access or interfere with code in other environments, providing security isolation while maintaining resource sharing at the process level. This local quality ensures that resource utilization benefits do not compromise security.

Inventive Principle:

Principle #3Local quality

4Loss of energy

If code is executed in isolated execution environments within a single process, then context switching overhead is reduced, but process memory management complexity increases

Engineering Contradiction:

Improvecontext switching overheadVSAvoidprocess memory management complexity

Core Design Contradiction:

Loss of energyVSDevice complexity

Solution Approach 1:

An intermediary memory management mechanism is introduced to handle the complexity of managing multiple isolated execution environments within a single process. This intermediary layer abstracts the memory allocation and isolation logic, providing a simplified interface for environment creation and management while handling the underlying complexity of memory segmentation and protection.

Inventive Principle:

Principle #24Intermediary (Mediator)

Data Source

PatentUS10805323B1Cloud computing platform that isolates suspicious third-party code in a distributed cloud computing network

Publication Date: 2020.10.13 CLOUDFLARE INC

AI summary

A worker process monitors a behavior of a third-party code piece executing in a first isolated execution environment of a plurality of isolated execution environments of a first process in a first compute server. When the behavior of the executing third-party code piece is indicative of a potential speculative execution attack, the third-party code piece is flagged. When a subsequent request is received that triggers execution of the flagged third-party code piece, the worker process generates a private process in the first compute server, separate from the first process, and instantiates a single isolated execution environment within the second process for executing the third-party code piece. The work process loads the third-party code piece in the single isolated execution environment and the second process executes the third-party code piece.