Single-use execution environment for on-demand code execution

Abstract

Systems and methods are provided for efficiently configuring an execution environment for an on-demand code execution system to handle a single request (or session) of a single user. Once the session or request is complete, the execution environment is reset, such as by having the hardware processor state, memory, and storage reset. In particular, prior to execution of code, the state of the execution environment of the host computing device is retrieved, such as hardware processor, memory, and / or storage state. Further, during execution of the code instructions, intermediate state can be collected. After execution of the code, the execution environment is reset based on the saved state related to the hardware processor, memory, and / or storage. Subsequent code execution occurs safely in the execution environment, and the execution environment is again reset, and so on.

Description

[0001] By incorporating any priority claim

[0002] This application claims the benefit of U.S. Patent Application Serial No. 16 / 782,873, filed February 5, 2020, entitled “SINGLE USE EXECU TION ENVIRONMENT FOR ON-DEMAND CODE EXECUTION”, which is hereby incorporated herein by reference in its entirety. Background Technology

[0003] Computing devices can use communication networks to exchange data. Companies and organizations operate computer networks that interconnect several computing devices to support operations or provide services to third parties. Computing systems may be located in a single geographic location or in multiple different geographic locations (e.g., interconnected via private or public communication networks). Specifically, a hosted computing environment or data processing center, generally referred to herein as a "data center," may include several interconnected computing systems to provide computing resources to users of the data center. A data center may be a private data center operated on behalf of an organization, or it may be a public data center operated on behalf of the public or for the public interest.

[0004] To facilitate increased utilization of data center resources, virtualization technology allows a single physical computing device to host one or more instances of virtual machines, which appear to users in the data center and operate as independent computing devices. Through virtualization, a single physical computing device can dynamically create, maintain, delete, or otherwise manage virtual machines. Users can then request computing resources from the data center, such as the configuration of a single computing device or networked computing devices, and are supplied with varying numbers of virtual machine resources. In some virtualization environments, snapshots of virtual machines can be taken, and virtual machines can be restored to snapshots.

[0005] In some scenarios, a user may request computing resources from a data center to perform a specific task. This task may correspond to a set of computer-executable instructions, which the data center can then execute on behalf of the user. This can thus facilitate increased utilization of data center resources. Attached Figure Description

[0006] These and other features, aspects, and advantages are described below with reference to the accompanying drawings, which are intended for illustrative purposes and should in no way be construed as limiting the scope of the embodiments. Furthermore, various features of different disclosed embodiments can be combined to form additional embodiments that are part of this disclosure. In the drawings, the same reference numerals may denote corresponding features in similar embodiments. A brief description of the figures follows.

[0007] Figure 1A This is a block diagram illustrating an illustrative network environment for implementing a secure code execution system.

[0008] Figure 1B This is a block diagram illustrating an environment in which the on-demand code execution system can execute tasks corresponding to code that can be submitted by a user of the on-demand code execution system.

[0009] Figure 2 It shows Figure 1B The general architecture of the host computing device is shown in the figure.

[0010] Figures 3A to 3B This is a flowchart illustrating the illustrative interactions used to provide a secure execution environment.

[0011] Figure 4 Another architecture for host computing devices is shown.

[0012] Figure 5 This is a flowchart illustrating an example method for safely handling code execution requests.

[0013] Figure 6 This is a flowchart illustrating the interactive process for providing multiple secure execution environments.

[0014] Figure 7 This is a flowchart illustrating an example method for securely handling code execution requests across multiple host computing devices. Detailed Implementation

[0015] Various aspects of this disclosure relate to the execution of processes in a “serverless” or “cloud computing” environment. Various aspects of this disclosure also relate to on-demand code execution systems. On-demand code execution systems support the rapid execution of code that can be supplied by the user of the on-demand code execution system, which can be implemented in a serverless environment. As used herein, the terms “serverless” or “cloud computing” environment refer to an environment in which the responsibility for managing the creation, configuration, and state of the underlying execution environment is abstracted from the user. For example, the user does not need to create an execution environment, install an operating system, or manage the state of the environment to execute the desired code in that environment. In existing on-demand code execution systems, a single execution environment may be responsible for handling numerous requests across many users. This can introduce security vulnerabilities, such as: (i) malicious requests capable of corrupting the state or code of the server to cause it to perform unexpected actions; or (ii) allowing malicious attackers to discern sensitive information from a reusable execution environment.

[0016] As mentioned above, in some existing virtual machine systems, snapshots of virtual machines can be created, and virtual machines can be restored from snapshots. For example, a snapshot might be an image of the current state of a virtual machine. However, the snapshot process in existing virtual machine systems can be relatively slow, taking several seconds to create a snapshot and / or restore from it.

[0017] Generally speaking, aspects of this disclosure relate to the execution environment of an on-demand code execution system configured to handle a single request (or session) from a single user. Once the session or request is complete, the execution environment can be reset, for example, by resetting the hardware processor state, memory, and storage devices. Specifically, before executing code, the state of the host computing device's execution environment, such as the state related to the hardware processor, memory, and / or storage devices, can be saved. Furthermore, intermediate states can be collected during the execution of code instructions. After code execution, the execution environment can be reset based on the saved state related to the hardware processor, memory, and / or storage devices, as well as the intermediate states. Subsequent code execution can safely occur within the execution environment, and the execution environment can be reset again. Therefore, the execution environment can be reused and reset efficiently across multiple code executions.

[0018] As used herein, in addition to its common and conventional meaning, "execution environment" may refer to a logical unit created on a host computing device (such as within a virtual machine instance) that uses the resources available on the instance or device. New execution environments can be created or refreshed to handle the execution of user code based on a request to execute the user code. Each execution environment can provide a degree of isolation from other execution environments. For example, each execution environment may provide a file system isolated from other file systems on the device, and code executing in an execution environment may have limited or no access to other file systems or memory spaces associated with code executing outside the execution environment. An example execution environment could be a container within a virtual machine instance.

[0019] The systems and methods described herein improve security in serverless environments, such as on-demand code execution systems. As described herein, in some existing on-demand code execution systems, a single execution environment can handle numerous requests across many users. Security issues such as side-channel attacks and persistent malware can be addressed by resetting the execution environment after each request or session. As used herein, the term "side-channel attack" generally refers to a security vulnerability involving the collection of information about what a computing device is doing while executing code and using that information to reverse engineer the device. The term "side-channel attack" may also generally refer to situations in multi-tenant environments where multiple workers run concurrently, and the workers are able to infer information about other workloads currently physically co-located on the same computing device. Therefore, the systems and methods described herein improve upon existing serverless technologies.

[0020] The systems and methods described herein improve virtualization technologies. As mentioned above, the snapshot process in existing virtual machine systems can be relatively slow, requiring several seconds to create a snapshot and / or restore from it. For example, creating a snapshot in an existing virtual machine system may require creating an image of the entire state of the processor, memory, and storage devices. Similarly, restoring from a snapshot may require loading a saved image. Creating and / or restoring from a snapshot can take many seconds. Therefore, the techniques described herein do not rely entirely on existing snapshot technologies but offer a lighter and faster way to save and / or restore the state of the processor, memory, and storage devices in an execution environment than existing virtual machine technologies.

[0021] Go to Figure 1A An illustrative network environment 100 is shown, in which a secure code execution system 105 can quickly provide an execution environment for user code execution. Network environment 100 may include user computing device 102, network 104, and secure code execution system 105. Secure code execution system 105 may include gateway service 112, service provision 114, credential service, on-demand code execution system 110, auxiliary services 106, and data storage service 108. Components of network environment 100 may communicate with each other locally or via network 104. User computing device 102 may include any computing device capable of communicating with the secure code execution system via network 104, such as a client computing device. Example computing devices include laptop or tablet computers, personal computers, personal digital assistants (PDAs), hybrid PDA / mobile phones, mobile phones, and / or smartphones.

[0022] While some components of network environment 100 are described as communicating with each other, in some implementations, any component of network environment 100 may communicate with any other component of network environment 100. For example, gateway service 112 may communicate with any component of network environment 100; however, not all of these communication lines are... Figure 1A As shown in the image.

[0023] User computing device 102 may transmit a request for executable code instructions to secure code execution system 105. Gateway service 112 may receive the request. In response to receiving the request, service provision 114 may cause a new execution environment to be instantiated in on-demand code execution system 110. If the execution environment already exists, service provision 114 may cause the execution environment to be reset in on-demand code execution system 110. In some embodiments, if the execution environment is used for a session with multiple requests, the execution environment may already exist and be reused. User code can be executed on on-demand code execution system 110 within the execution environment. For example, the executed code on on-demand code execution system 110 may communicate with auxiliary service 106 or data storage service 108 to perform tasks.

[0024] Furthermore, a user can interact with the on-demand code execution system 110 via user computing device 102 to provide executable code and establish rules or logic defining when and how such code should be executed on the on-demand code execution system 110, thereby defining a "task". For example, a user might want to run a piece of code that they have already developed. One way to run the code would be to obtain a virtual machine instance from a service provider offering infrastructure as a service; configure the virtual machine instance to suit the user's needs; and use the configured virtual machine instance to run the code. To avoid the complexity of this process, the user can alternatively provide code to the on-demand code execution system 110 and request the on-demand code execution system 110 to execute the code. The on-demand code execution system 110 can dispose of the acquisition and configuration of computing capacity (e.g., execution environments, containers, instances, etc., described in more detail below) based on the code execution request and use the computing capacity to execute the code. The on-demand code execution system 110 can automatically scale up and down based on volume, thereby relieving users of the burden of worrying about over-utilization (e.g., acquiring too few computing resources and suffering performance problems) or under-utilization (e.g., acquiring more computing resources than are required to run the code and thus paying too much).

[0025] The illustrative environment 100 also includes one or more network-based data storage services 108 configured to enable the on-demand code execution system 110 to store data and retrieve data from one or more persistent or substantially persistent data sources. Illustratively, the network-based data storage service 108 enables the on-demand code execution system 110 to: store information corresponding to a task, such as code or metadata; store additional code objects representing the dependencies of the task; retrieve data to be processed during the execution of the task; and store information about the execution (e.g., results). The network-based data storage service 108 may represent, for example, a relational or non-relational database. In another example, the network-based data storage service 108 may represent a network attached storage device (NAS) configured to provide access to data arranged in a file system. The network-based data storage service 108 may further enable the on-demand code execution system 110 to query and retrieve information about data stored within the on-demand code execution system 110, such as by querying a number of related files or records, the size of those files or records, the file or record name, the file or record creation time, etc. In some instances, the network-based data storage service 108 may provide additional functionality, such as the ability to segment data into logical groups (e.g., groups associated with individual accounts). Although shown as distinct from ancillary service 106, the network-based data storage service 108 may in some cases represent a type of ancillary service 106.

[0026] Network-based data storage service 108 may include a data repository. As used herein, in addition to its common and customary meaning, "data repository" can refer to any data structure (and / or combination of data structures) used for storing and / or organizing data, including but not limited to relational databases (e.g., Oracle databases, MySQL databases, etc.), non-relational databases (e.g., NoSQL databases, etc.), key-value databases, in-memory databases, tables in databases, comma-separated value (CSV) files, Extensible Markup Language (XML) files, TeXT (TXT) files, flat files, spreadsheet files, and / or any other widely used or proprietary data storage format.

[0027] Network 104 can be any wired network, wireless network, or a combination thereof. Additionally, network 104 can be a personal area network (PAN), local area network (LAN), wide area network (WAN), cable network, satellite network, cellular telephone network, or a combination thereof. Furthermore, network 104 can be an over-the-air broadcast network (e.g., for radio or television) or a publicly accessible network of linked networks that may be operated by various different parties, such as the Internet. In some embodiments, network 104 can be a private or semi-private network, such as a corporate or university intranet. Network 104 may include one or more wireless networks, such as a Global System for Mobile Communications (GSM) network, a Code Division Multiple Access (CDMA) network, a Long Term Evolution (LTE) network, or any other type of wireless network. Network 104 may use protocols and components for communication via the Internet or any of the aforementioned types of networks, such as HTTP. Protocols and components for communication via the Internet or any of the aforementioned types of communication networks are known to those skilled in the art of computer communications and therefore do not require further description herein.

[0028] User computing device 102 and secure code execution system 105 may each be embodied in one or more devices. For example, user computing device 102 and secure code execution system 105 may include a network interface, memory, a hardware processor, and a non-transitory computer-readable medium drive, all of which can communicate with each other via a communication bus. The network interface may provide connectivity via network 104 and / or other networks or computer systems. The hardware processor may communicate with memory containing program instructions that are executed by the hardware processor to operate user computing device 102 and secure code execution system 105. Memory generally includes RAM, ROM, and / or other persistent and / or auxiliary non-transitory computer-readable storage media.

[0029] Additionally, in some implementations, the secure code execution system 105 and its components are implemented by one or more virtual machines in a managed computing environment. The managed computing environment may include one or more computing resources that can be rapidly provisioned and / or released. Computing resources may include hardware computing, networking, and / or storage devices configured with specifically configured computer-executable instructions. The managed computing environment may also be referred to as a "serverless," "cloud," or distributed computing environment.

[0030] Turn Figure 1B The on-demand code execution system 110 is shown operating in a distributed computing environment, which includes the use of one or more computer networks ( Figure 1B Several computer systems (not shown) are interconnected. The on-demand code execution system 110 can also be used in systems with... Figure 1B The computing environment operates with fewer or more devices as shown. Therefore, Figure 1B The description of the on-demand code execution system 110 in this disclosure should be considered illustrative and not limited to this disclosure.

[0031] To enable interaction with the on-demand code execution system 110, system 110 includes one or more front-ends 120 that facilitate interaction with the on-demand code execution system 110. In an illustrative embodiment, the front-end 120 serves as a "front door" to other services provided by the on-demand code execution system 110, enabling a user (via user computing device 102) to provide computer-executable code, request execution of the computer-executable code, and view the results of the computer-executable code. The front-end 120 includes various components for enabling interaction between the on-demand code execution system 110 and other computing devices. For example, each front-end 120 may include a request interface that provides user computing device 102 with the ability to upload or otherwise transmit user-specified code to the on-demand code execution system 110 and subsequently request execution of that code. In one embodiment, the request interface communicates with external computing devices (e.g., user computing device 102, auxiliary service 106, etc.) via a graphical user interface (GUI), CLI, or API. The front-end 120 processes the request and ensures that the request is properly authorized. For example, frontend 120 can determine whether the user associated with the request is authorized to access the user code specified in the request. The request interface of frontend 120 can receive calls from the user to perform a task as a Hypertext Transfer Protocol Secure (HTTPS) request. Furthermore, during task execution, any information included in the HTTPS request (e.g., headers and parameters) can be processed and utilized. As discussed above, any other protocol (including, for example, HTTP, MQTT, and CoAP) can be used to pass a message containing the task call to the request interface.

[0032] The reference to user code used herein can refer to any program code (e.g., program, routine, subroutine, thread, etc.) written in a specific programming language. In this disclosure, the terms “code,” “code instruction,” “user code,” and “program code” are used interchangeably. For example, such user code can be executed in conjunction with a specific web application or mobile application developed by the user to achieve a specific function. As described above, a single collection of user code (e.g., used to achieve a specific function) is referred to herein as a “task,” and the specific execution of that code (including, for example, compiling, interpreting, or otherwise enabling the code to execute) is referred to as “task execution” or simply “execution.” Tasks can be written in programming languages ​​such as, but not limited to, JavaScript, Java, Python, or Ruby. Tasks can be “triggered” to execute on the on-demand code execution system 110 in various ways. In embodiments, a user or other computing device can transmit a request to execute a task, which is generally referred to as a “call” to execute the task. Such a call may include the user code to be executed (or its location) and one or more arguments to be used to execute the user code. For example, a user code that provides a task and a request to execute the task may be invoked. In another example, the invocation may be identified by the name or identifier of a previously uploaded task. In yet another example, code corresponding to the task may be included in the invocation of the task and uploaded to a separate location (e.g., storage of auxiliary service 106 or storage within the on-demand code execution system 110) before the on-demand code execution system 110 receives the request. The code for the task may reference additional code objects maintained at the on-demand code execution system 110 by using identifiers of these code objects, such that the code objects are combined with the task's code in the execution environment before the task is executed. The on-demand code execution system 110 may vary its task execution strategy based on where the task's code is available when processing the invocation of the task.

[0033] The invocation to execute a task may specify one or more third-party libraries (including native libraries) to be used with the user code corresponding to the task. In one embodiment, the invocation may provide a file to the on-demand code execution system 110 containing the user code corresponding to the requested task and any libraries (and / or identification of their storage locations). In some embodiments, the invocation includes metadata indicating the program code of the task to be executed, the language in which the program code is written, the user associated with the invocation, and / or the computing resources (e.g., memory, etc.) reserved for executing the program code. For example, the program code for the task may be provided by the invocation, previously uploaded by the user, provided by the on-demand code execution system 110 (e.g., standard routines), and / or provided by a third party. Illustratively, code not included in the invocation or previously uploaded by the user may be referenced within the task's metadata using a URI associated with the code. In some embodiments, such resource hierarchy constraints (e.g., how much memory will be allocated to execute a particular user code) are specified for a particular task and may remain unchanged during each execution of the task. In such cases, the on-demand code execution system 110 may have access to such resource-level constraints before receiving each individual call, and individual calls may not specify such resource-level constraints. In some embodiments, the call may specify other constraints, such as license data indicating what kind of license or permission the caller uses to perform the task. Such license data may be used by the on-demand code execution system 110 to access private resources (e.g., on a private network). In some embodiments, individual code objects may also be associated with licenses or authorizations. For example, a third party may submit a code object and specify that the object is readable only by a subset of users. The on-demand code execution system 110 may include functionality for implementing these licenses or authorizations regarding code objects.

[0034] To manage requests for code execution, the frontend 120 may include an execution queue ( Figure 1B(Not shown in the image), the execution queue can maintain a record of requested task executions. Illustratively, the number of tasks that the on-demand code execution system 110 can execute simultaneously is limited, and therefore, new task executions initiated at the on-demand code execution system 110 (e.g., via API calls, via calls from executed or currently executing tasks, etc.) can be placed on the execution queue and processed, for example, in a first-in, first-out order. In some embodiments, the on-demand code execution system 110 may include multiple execution queues, such as separate execution queues for each user account. For example, a user of the on-demand code execution system 110 may want to limit the rate of task execution on the on-demand code execution system 110 (e.g., for cost reasons). Therefore, the on-demand code execution system 110 may utilize account-specific execution queues to regulate the rate of concurrent task execution for a particular user account. In some cases, the on-demand code execution system 110 may differentiate task execution priorities, such that task executions for a particular account or with a specified priority are bypassed or prioritized within the execution queue. In other cases, the on-demand code execution system 110 can execute the task immediately or substantially immediately after receiving a call for the task, and therefore, the execution queue can be omitted.

[0035] Front-end 120 may also include an output interface (not shown in FIG. 1) configured to output information about the execution of a task on the on-demand code execution system 110. Illustratively, the output interface may transmit data about task execution (e.g., the result of the task, errors associated with the task execution, or details of the task execution, such as the total time required to complete the execution, the total data processed via the execution, etc.) to user computing device 102 or auxiliary service 106, which may include, for example, billing or logging services. The output interface may also enable the transmission of data such as service calls to auxiliary service 106. For example, the output interface may be used during task execution to transmit API requests to external service 106 (e.g., to store data generated during task execution).

[0036] To perform tasks, the on-demand code execution system 110 includes one or more worker managers 140, which manage instances for serving incoming calls to perform tasks. Figure 1BIn the example shown, each worker manager 140 manages an activity pool of virtual machine instances 154A-154C, which are currently assigned to one or more users and implemented by one or more physical host computing devices 150A-150B. The physical host computing devices 150A-150B and the virtual machine instances 154A-154C may also implement one or more execution environments 158A-158F, which may contain and execute one or more user-submitted code instructions 160A-160G. As described herein, an execution environment can be a logical unit created within or on the instance or device using resources available on the virtual machine instance or host computing device. For example, each worker manager 140 may create a new execution environment or locate an existing execution environment 158A-158F and assign it to handle the execution of a task based on information specified in a call to execute a task. Each execution environment may correspond to the execution environment of a task, thereby providing at least a degree of isolation from other execution environments. For example, each execution environment may provide a file system isolated from other file systems on the device, and code executing in an execution environment may have limited or no access to other file systems or memory spaces associated with code executing outside the execution environment. As described herein, service providers 114 and / or host computing devices 150A, 150B may create, manage, and / or reset execution environments 158A-158F.

[0037] The execution environments 156A-156F, virtual machine instances 154A-154C, and host computing devices 150A-150B may also include additional support functions for the execution of language runtimes, code libraries, or user-submitted code 160A-160G. Figure 1B (Not shown in the image). The physical computing devices 150A-150B and virtual machine instances 154A-154C may also include operating systems 152A-152B and 156A-156C. In various embodiments, the operating systems 152A-152B and 156A-156C may be the same operating system, a variant of the same operating system, different operating systems, or a combination thereof.

[0038] Once frontend 120 has successfully processed the triggering event for executing a task, frontend 120 forwards the request to worker manager 140 to execute the task. In one embodiment, each frontend 120 may be associated with a corresponding worker manager 140 (e.g., a worker manager 140 co-located or geographically near frontend 120), and thus, frontend 120 may forward most or all requests to that worker manager 140. In another embodiment, frontend 120 may include a location selector configured to determine the worker manager 140 to which the execution request will be forwarded. In one embodiment, the location selector may determine the worker manager 140 receiving the call based on a call hash and distribute the call to the worker manager 140 selected based on the hash value (e.g., via a hash ring). Various other mechanisms for distributing calls among worker managers 140 will be apparent to those skilled in the art.

[0039] like Figure 1B As shown, various combinations and configurations of host computing devices 150A-150B, virtual machine instances 154A-154C, and execution environments 158A-158F can be used to facilitate the execution of user-submitted code 160A-160G. In the illustrated example, host computing device 150A implements two virtual machine instances 154A and 154B. Virtual machine instance 154A then implements two execution environments 158A and 158B, which respectively contain user-submitted code 160A and 160B. Virtual machine instance 154B implements a single execution environment 158C, which contains user-submitted code 160C. Host computing device 150B also implements virtual machine instance 154C and directly implements execution environments 158E and 158F, which contain user-submitted code 160F and 160G. Virtual machine instance 154C then implements execution environment 158D, which contains user-submitted code instructions 160D and 160E. It will be understood that these embodiments are illustrated for illustrative purposes, and many other embodiments are also within the scope of this disclosure.

[0040] Figure 2 It is possible Figure 1A A schematic diagram of an illustrative host computing device 150 used in environment 100. The host computing device 150 includes an arrangement of computer hardware and software components that can be used to rapidly provide an execution environment. Although regarding... Figure 2 The general architecture of the host computing device 150 is shown and described, but Figure 2 The general architecture can be used to implement other services and / or applications described herein. Those skilled in the art will understand that the host computing device 150 may include more than Figure 2The components shown may include more (or fewer) components. Furthermore, other computing systems described herein may include similar arrangements of computer hardware and software components.

[0041] The host computing device 150 may include a hardware processor 202, main memory 210, a memory management unit (MMU) 230, a network interface 204, a non-transitory computer-readable medium 206, and an input / output device interface 208, all of which can communicate with each other via a communication bus 224. The computer-readable medium 206 may also be referred to herein as a storage device. The main memory 210 and / or the memory management unit 230 may also be referred to herein as a memory device. As shown, the host computing device 150 is associated with or communicates with an optional display 218 and an optional input device 220. In other embodiments, the display 218 and the input device 220 may be included in... Figure 1A The user computing device 102 shown in the figure. A network interface 204 provides a host computing device 150 with connectivity to one or more networks or computing systems. The hardware processor 202 can therefore receive information and instructions from other computing systems (such as the user computing device 102) or services via the network 104. The hardware processor 202 can also communicate to and from memory 210 and also provides output information for an optional display 218 via an input / output device interface 208. The input / output device interface 208 can accept input from an optional input device 220 such as a keyboard, mouse, digital pen, touchscreen, accelerometer, gyroscope, or gestures recorded via motion capture and / or image recognition (e.g., placement and / or recognition of eyes, hands, head, and / or body parts). The input / output device interface 220 can also output audio data to a speaker or headphones (not shown).

[0042] Main memory 210 may contain computer program instructions that are executed by hardware processor 202 to implement a specific configuration of one or more embodiments of host computing device 150. Memory 210 generally includes RAM, ROM, and / or other persistent or non-transitory computer-readable storage media. Memory 210 may store operating system 214, which provides computer program instructions used by processing unit 202 in the general management and operation of host computing device 150. Memory 210 may also include other information for implementing various aspects of host computing device 150.

[0043] The hardware processor 202 may also be referred to as a central processing unit (CPU). The hardware processor 202 may include processor registers 212 and level 1 (L1), level 2 (L2), and level 3 (L3) caches 216. In some embodiments, although not shown, the processor 202 may include fewer or additional caches (such as an L4 cache). The processor registers 212 may be fast-access locations and may hold instructions, memory addresses, or any type of data (such as bit sequences or individual characters). The processor cache 216 is a hardware cache used by the processor 202 to reduce the average cost of accessing data from main memory 210. The memory management unit (MMU) 230 is a computer hardware device that communicates with one or more page tables 222 to map virtual page numbers to physical page numbers in main memory 210. Therefore, the MMU 230 performs the translation of virtual memory addresses to physical addresses.

[0044] refer to Figure 3A This illustrates the illustrative interactions used to provide a secure execution environment. Figure 3A Environment 300 may be related to Figure 1A or Figure 1B The environment is 100% similar. For example, Figure 3A The user computing device 102A may be Figure 1A The computing device of the user computing device 102. Similarly, Figure 3A The host computing device 150 can be connected with Figure 2 The host computing device 150 is similar. However, for ease of discussion, related figures (such as, Figure 1A , Figure 1B or Figure 2 Some components in Figure 3A The environment depicted in 300. Figure 3A The interactions shown are example interactions. Furthermore, the following is about... Figure 3B Additional example interactions are described in more detail. In other embodiments, other interactions (not shown) may be possible according to this disclosure. Similar to the communication depicted in Figure 1, not every possible communication is possible. Figure 3A As shown in the image.

[0045] Figure 3AThe interaction begins in step one (1), where service 114 can receive status from host computing device 150. The status of the execution environment of host computing device 150 can be received by service 114 before user code is invoked on host computing device 150. Examples of receivable status may include, but are not limited to, hardware processor status, storage device status, and / or operating system status. Hardware processor status may include the status of hardware processor register 212. Example storage device status may include image data from computer-readable medium 206. Example operating system status may include sockets, file descriptors, pipes, and / or queues of operating system 214. In some embodiments, the basic execution environment may be an image initially loaded onto host computing device 150. The image may include the status of the hardware processor 202, computer-readable medium 206, main memory 210, and / or other components of host computing device 150.

[0046] In step two (2), the user code instructions of the user computing device 102A can be executed in an execution environment on the host computing device 150. In particular, the user code instructions can be executed in an execution environment on a virtual machine instance of the host computing device 150. Although not shown, the host computing device 150 may be one of many computing devices in the on-demand code execution system 110.

[0047] In step two'(2'), when user code instructions are executed in the execution environment on host computing device 150, service 114 can receive indications of state changes and / or state changes from host computing device 150. Regarding main memory 210, if the execution of code results in a read or write to any memory page, service 114 can receive indications that such an operation has occurred. Similarly, regarding computer-readable medium 206, if the execution of code results in a read or write to any storage unit (e.g., page, block, or segment) of computer-readable medium 206, service 114 can receive indications that such an operation has occurred. Additional details regarding state changes and / or tracking of state changes will be provided below regarding... Figure 5 To describe in more detail.

[0048] After code execution on host computing device 150 (e.g., within a virtual machine instance) is completed in step three (3), providing service 114 may cause the execution environment on host computing device 150 to be reset in an efficient manner. Each of the hardware processors 202, including registers 212 and hardware processor cache 216, computer-readable medium 206, page tables 222, and / or main memory 210, may be reset or modified to restore to an initial execution state, as indicated by the number three. For example, the hardware processor 202, including registers 212, may be reset to the initial hardware processor state received in step one (1). The hardware processor cache 216 (e.g., L1, L2, L3, etc.) may be refreshed. The computer-readable medium 206 may be reset to the initial storage device state received in step one (1). For example, image data may be loaded to reset the computer-readable medium 206. Alternatively or additionally, if a mechanism is used during the execution of step two (2), it may only be necessary to restore the changes to the computer-readable medium 206. Similarly, regarding main memory 210, if a mechanism is used during the execution of step two'(2') to track accesses or changes to main memory 210, it may only be necessary to restore the changes to main memory 210. In particular, page table 222 can be modified to reset the execution environment. As shown, components of the host computing device 150, such as hardware processor 202 (including registers 212 and / or hardware processor cache 216), page table 222, computer-readable medium 206, and / or main memory 210 (including operating system 214), can be reset in step three (3). The following relates to Figure 5 Additional details regarding resetting the execution environment are described in more detail. Therefore, the execution environment on host computing device 150 (such as the execution environment on a virtual machine instance of host computing device 150) can be reset in an efficient manner, and the execution environment is ready to safely handle additional code execution requests.

[0049] refer to Figure 3B This illustrates additional illustrative interactions used to provide a secure execution environment. Figure 3B Environment 350 may be related to Figure 3A The environment is 300 times similar. For example, Figure 3B The host computing device 150 may be related to Figure 2 and / or Figure 3A It is similar to the host computing device 150. However, Figure 3B Environment 350 and Figure 3A The difference between environments 300 may be that the host computing device 150 of the previous environment 350 can reset its execution environment without receiving a reset command from service provider 114. Specifically, Figure 3BThe host computing device 150 can be configured to recognize the state, track the state, and reset its execution environment after the user code completes. Figure 3B The interaction shown is an example interaction. In other embodiments, other interactions (not shown) may be possible according to this disclosure. Figure 1A The communication descriptions are similar, but not every possible communication can be achieved. Figure 3B As described in the text.

[0050] Figure 3B The interaction begins in step one (1), where the host computing device 150 recognizes its own state. Before invoking user code on the host computing device 150, the host computing device 150 determines its execution state. As described herein, the execution environment state may include, but is not limited to, hardware processor state (such as the state of hardware processor register 212), storage device state (such as pages, blocks, segments, or image data of computer-readable medium 206), and / or operating system state (such as sockets, file descriptors, pipes, and / or queues of operating system 214). In some embodiments, the basic execution environment may be an image initially loaded onto the host computing device 150. The image may include the state of the host computing device 150's hardware processor 202, computer-readable medium 206, main memory 210, and / or other components.

[0051] In step two (2), the user code instructions of the user computing device 102A can be executed in the execution environment on the host computing device 150. In particular, the user code instructions can be executed in the execution environment on a virtual machine instance of the host computing device 150.

[0052] In step two'(2'), when the user code instructions are executed in the execution environment on the host computing device 150, the host computing device 150 can recognize state changes and / or indications of state changes. Regarding main memory 210, the host computing device 150 can recognize these operations if the execution of the code results in a read or write to any memory page. Similarly, regarding computer-readable medium 206, the host computing device 150 can recognize these operations if the execution of the code results in a read or write to any storage unit (e.g., page, block, or segment) of computer-readable medium 206. Additional details regarding recognizing state changes (such as tracking these state changes) will be provided below regarding... Figure 5 To describe in more detail.

[0053] After code execution on host computing device 150 (e.g., within a virtual machine instance) has completed in step three (3), host computing device 150 may be configured to reset the execution environment on host computing device 150 in an efficient manner. As indicated by the number three, host computing device 150 may reset or modify each of the hardware processors 202, including registers 212 and hardware processor cache 216, computer-readable medium 206, page tables 222 and / or main memory 210, to restore to an initial execution state. For example, as described herein, host computing device 150 may reset its own hardware processors 202 (including registers 212) to the initial hardware processor state identified in step one (1). Host computing device 150 may also refresh hardware processor cache 216 (e.g., L1, L2, L3, etc.). Host computing device 150 may reset computer-readable medium 206 to the initial storage device state identified in step one (1). Regarding main memory 210, if a mechanism is used during the execution of step two'(2') to track accesses or changes to main memory 210, it may only be necessary to restore the changes to main memory 210. Specifically, page table 222 can be modified to reset the execution environment. (The above and below discuss...) Figure 3A and Figure 5 Additional details regarding resetting the execution environment are described in more detail.

[0054] Specifically, hardware processor 202 can cause computer-readable medium 206, page table 222, and / or main memory 210 to return to their initial execution state. Furthermore, hardware processor 202 can reset itself. For example, as discussed below, hardware processor 202 may use a "big.LITTLE" architecture or something similar. Therefore, one or more of the hardware processors can be responsible for resetting, which may include resetting other hardware processors as well as computer-readable medium 206, page table 222, and / or main memory 210.

[0055] Figure 4 Another architecture for the host computing device 150C is shown. Figure 4 The mainframe computing device 150C can be connected with Figure 2 It is similar to the host computing device 150. However, Figure 4The host computing device 150C may include a reset device 402. The reset device 402 may be hardware on the host computing device 150C configured to perform some of the reset operations described herein. For example, the reset device 402 may be responsible for resetting the state of the hardware processor 202 or resetting the computer-readable medium 206 and / or main memory 210. The reset device 402 may be dedicated hardware for resetting. Example reset devices 402 may include cards (such as peripheral component internet (PCI) cards) and / or complex programmable logic devices (CPLDs) or field-programmable gate arrays (FPGAs) on bus 224, which may reside on the motherboard of the host computing device 150C.

[0056] In other embodiments (not shown), the host computing device 150C may include a plurality of hardware processors 202 or cores. In these embodiments, one or more of the hardware processors 202 or cores may be configured to perform a specific reset task, while other hardware processors 202 or cores may handle general computing tasks. For example, if the hardware processors 202 use a "big.LITTLE" architecture or a similar architecture, one or more of the hardware processors 202 or cores configured for a specific reset task may be smaller cores, and the remaining hardware processors 202 may be larger cores that can be reserved for more complex reset tasks.

[0057] Figure 5 This is a flowchart illustrating an example method 500 for securely processing code execution requests, implemented by a secure code execution system 105. As described herein, the secure code execution system 105 may include a service 114. In some embodiments, providing the service 114 and / or a host computing device 150 may implement aspects of method 500.

[0058] At box 501, an execution environment can be initialized. For example, if an execution environment does not exist on host computing device 150, such as in a virtual machine instance, service 114 and / or host computing device 150 can initially create an execution environment. As described herein, the basic execution environment may be an image initially loaded on host computing device 150. Therefore, multiple virtual machine instances and / or host computing devices can initially use and / or share the same basic execution environment.

[0059] In some implementations, the initialization of the host computing device 150 can be customized based on requests, sessions, and / or user profiles associated with code execution requests. As described herein, service 114 can initialize the execution environment as a basic execution environment on a virtual machine instance of the host computing device. In addition to basic initialization, service 114 can insert customized data for code instructions into the basic execution environment to create a first execution environment. Example customized data may include machine learning data models that can be used by the code instructions. Therefore, execution of the code instructions may result in access to the customized data.

[0060] In box 502, initial execution environment state may be received. For example, service 114 may receive initial execution environment state from host computing device 150. Specifically, service 114 may receive hardware processor state from hardware processor 202 of host computing device 150. Hardware processor state may include the state of processor register 212. Service 114 may receive storage device state from computer-readable medium 206 of host computing device 150. Storage device state may include image data of computer-readable medium 206. Service 114 may receive operating system state (such as state from Linux or Unix kernel) from operating system 214 of host computing device 150. As described herein, example operating system state may include sockets, file descriptors, pipes, and / or queues of operating system 214. The purpose of initial execution environment state may be to inform which execution environment should be reset to after a code execution task on host computing device 150 is completed. In some embodiments, initial execution environment state may be cached. For example, if a predetermined execution environment is loaded (e.g., from an image) onto host computing device 150, the initial execution environment may be known and pre-cached. Therefore, receiving the initial execution environment may include retrieving the state from the cache.

[0061] As described herein, in some embodiments, aspects of providing service 114 may be implemented by host computing device 150, such as identifying an initial state. For example, host computing device 150 may maintain an initial execution environment state from host computing device 150. In some embodiments, if the initial execution environment remains the same across multiple load and / or devices, the initial execution environment state may be cached.

[0062] In box 504, a code execution request may be received. For example, gateway service 112 may receive a code execution request from user computing device 102A. This request may be processed in part by service provider 114 and / or on-demand code execution system 110 as described herein.

[0063] In box 506, user code is executable. For example, the user code can be executed within the execution environment of host computing device 150. More specifically, code instructions can be caused to execute in the execution environment of a virtual machine instance on host computing device 150 in on-demand code execution system 110. The user code instructions can perform a requested task. The result of the user code processing, or a message associated with that result (such as a success message), can be transmitted to user computing device 102A.

[0064] Also at block 506, while user code instructions are executed in the execution environment, state from the host computing device can be maintained and / or received. For example, service 114 can receive state from the host computing device. Specifically, the state of the host computing device 150 can be updated as user code instructions are executed in the execution environment on the host computing device 150. For example, the hardware processor 202 of the host computing device 150 (including processor register 212 and / or processor cache 216) can change state. The computer-readable medium 206 of the host computing device 150 can change state, such as blocks, bits, segments, or pages of the computer-readable medium 206 being updated in response to reading, writing, deleting, or updating the device 206. The main memory 210 and / or associated components (such as page table 222) of the host computing device 150 can change state. Service 114 can receive state changes and / or indications of state changes from the host computing device 150. Much like the purpose of receiving the initial state of the execution environment, the purpose of receiving changes to the execution environment may be to further inform how to efficiently reset the execution environment after the code execution task on the host computing device 150 has completed. In some embodiments, aspects of providing service 114 may be implemented by the host computing device 150, such as maintaining state during user code execution. In particular, during user code execution, state (such as memory device state and / or the storage device state described below) may be maintained internally without having to communicate with providing service 114.

[0065] During code instruction execution, service 114 may receive memory device status from the host computing device's memory device (such as main memory 210). Example memory device status may include indications that memory pages have been accessed and / or modified. For example, if code execution causes a read or write to any memory page, service 114 may receive an indication that such an operation has occurred. Specifically, during code instruction execution, host computing device 150 may record in the host computing device a memory device status indicating the accessed or modified memory page. Recording the memory device status indicating the accessed memory page in the host computing device may include generating a copy of the accessed memory page, also known as an access-time copy. As described herein, an access-time copy can advantageously prevent some side-channel attacks because it prevents subsequent execution of code instructions from determining which memory pages were previously accessed—information that some malicious actors might use. Similarly, recording the memory device status indicating the modified memory page in the host computing device may include generating a copy of the modified memory page, also known as a write-time copy. The service provider 114 and / or host computing device 150 can track each first access to a page. In a Linux environment, the service provider 114 and / or host computing device 150 can use userfaultfd to track access to memory pages.

[0066] In some implementations, during code instruction execution, host computing device 150 may create a bitmap indicating what has been accessed or modified and what has not. Example memory device states may include indications, such as memory pages accessed and / or modified as stored in the bitmap, and the memory device state may be received by service provider 114. In some implementations, the bitmap may be custom-created for reset purposes in the on-demand code execution system 110. Alternatively, the bitmap may be an existing bitmap (such as the dirty bitmap used by the Linux kernel) that can be used for reset purposes. The bitmap may include, for example, indications of at least a first clean memory page and a second memory page that has been accessed or modified. In some of these implementations, clean memory pages may be stored on disk and used to recover dirty memory pages, which is further described in detail below in box 508C along with other mechanisms for recovering dirty memory pages. As described herein, host computing device 150 may maintain a bitmap indicating what has been accessed or modified and what has not been accessed or modified without having to communicate with service provider 114.

[0067] During code instruction execution, service 114 may receive storage device status from computer-readable medium 206 of the host computing device. Specifically, service 114 may receive indication that such an operation has occurred if the execution of the code results in a read or write to any storage unit (e.g., page, block, or segment) of the computer-readable medium 206. Host computing device 150 may use access-time copies and / or write-time copies to track storage units (e.g., pages, blocks, or segments) of the computer-readable medium 206 that have been accessed or modified. As described herein, host computing device 150 may maintain storage device status without necessarily communicating with service 114.

[0068] In some implementations, the secure code execution system 105 may allow a state to persist outside of a request or session. Such a feature may present some security risks; however, it may be advantageous to efficiently establish a cache or amortize the cost of certain actions (such as establishing a connection). The storage devices (such as computer-readable media 206) or memory devices (such as main memory 210) of the host computing device 150 may include trusted regions for storing data. Thus, during code instruction execution, data may be stored in trusted storage sector of the storage device and / or trusted memory region of the memory device. Service 114 may receive indications that data is stored in trusted storage sector or trusted memory region, such as storage device state or memory device status.

[0069] At box 508A, the execution environment can be reset. The execution environment on the virtual machine instance of host computing device 150 can be reset after the completion of code instructions. In some embodiments, host computing device 150 may notify service provider 114 when the execution of user code instructions is complete. Alternatively or additionally, service provider 114 may determine when the execution of code instructions is complete. Service provider 114 may reset the execution environment to the execution environment on the virtual machine instance of host computing device 150. As described herein, in some embodiments, host computing device 150 may reset itself without communicating with service provider 114. As part of resetting the execution environment at box 508A, the hardware processor 202, computer-readable medium 206, and / or memory devices of host computing device 150 may be reset at boxes 508B, 508C, and 508D below. Blocks 508B, 508C, 508D for resetting the hardware processor 202, computer-readable medium 206, and / or memory devices of the host computing device 150 may occur in a different order than shown, may occur at least partially simultaneously, and / or, depending on the implementation, may not execute all blocks 508B, 508C, 508D. When the reset is complete, the host computing device 150 may notify service provider 114.

[0070] As described herein, some aspects of providing service 114 can be implemented by host computing device 150, such as resetting the execution environment. Specifically, the host computing device can execute the following blocks 508B, 508C, 508D to reset the execution environment without having to communicate with providing service 114. As mentioned, host computing device 150 can be configured to reset itself.

[0071] At block 508B, hardware processor 202 can be reset. Specifically, service 114 can transmit a reset instruction to hardware processor 202 of host computing device 150. The reset instruction can be configured to cause hardware processor 202 of host computing device 150 to return to a hardware processor state received at the previous block 502. Returning hardware processor 202 to the previous hardware processor state may include restoring processor register 212 to some state of the previous hardware processor state. As described herein, host computing device 150 can transmit the reset instruction to hardware processor 202 without necessarily communicating with service 114. For example, reset device 402 can transmit the reset instruction.

[0072] In some implementations, the reset instruction may be further configured to refresh the processor cache 216 (e.g., L1, L2, L3, etc.) of the hardware processor 202. Refreshing the processor cache 202 also protects against side-channel attacks, such as spectral-type side-channel attacks that exploit branch prediction and speculative execution on modern hardware processors to read memory, which could potentially bypass access controls. While refreshing the cache to execute subsequent code instructions may not be absolutely necessary, if the processor cache 216 is not refreshed, sensitive processor data could be captured or leaked to subsequent malicious actors, such as by inspecting the branch predictor or cache 216 of the hardware processor 202. In some implementations, the processor cache 216 may be refreshed and / or other states may be reset when two concurrent calls occur on the host computing device 150 (e.g., multiple simultaneous virtual machine instances on the same host computing device) and the host computing device 150 switches between calls in different time slices.

[0073] In block 508C, the memory device can be reset. Specifically, service 114 can cause the memory device of host computing device 150 to be restored to an initial state, at least in part, based on the memory device state received in the preceding block 502. For example, service 114 can receive an indication of when memory pages in main memory 210 were accessed or modified during code execution. In the case of copy-on-access or copy-on-write, resetting main memory 210 can be accomplished by discarding the accessed or modified copied memory pages. By discarding the copied memory pages, the initial memory pages are loaded and made available in main memory 210, thereby restoring main memory 210 to its initial state. As described herein, host computing device 150 can reset the memory device without necessarily communicating with service 114.

[0074] In some embodiments where the host computing device 150 tracks which memory pages have been modified or accessed in a bitmap, service 114 may cause the memory devices of the host computing device 150 to be restored to an initial state, at least in part, based on the memory device state received at the previous block 502. For example, service 114 may use a bitmap to identify which memory pages are clean and which are dirty, such as a first clean memory page and a second clean memory page that have been accessed or modified. Because the first memory page is clean, it does not need to be replaced and can be maintained. Conversely, because the second memory page has been accessed or modified, the second memory page may be replaced with a clean memory page. Clean memory pages may be stored on a disk. Clean memory pages received or retrieved from the disk may be used to replace accessed or modified memory pages in main memory 210. Alternatively or additionally, service 114 may cause the host computing device 150 to modify page table 222 instead of replacing clean pages. Service 114 may modify page table 222 by changing which logical pages point to which physical pages. However, modifying page table 222 may depend on the hardware processor 202 and / or even the version of hardware processor 202. Therefore, another solution for modifying page tables in a Linux kernel environment may include initially using mmap before the user code is invoked, and then remapping main memory 210 to a clean copy after the code instructions complete. A clean copy of memory pages can be maintained by intercepting writes to these pages and making copies of these pages on disk; this is also known as a copy-on-write. Similarly, a clean copy of memory pages can be obtained through a copy-on-access. In the context of a Linux kernel environment, a device mapper and / or file system and user space (FUSE) can be used to maintain a clean copy of memory pages with a copy-on-write or copy-on-access. As described herein, host computing device 150 can cause the memory device to be restored to its initial state without having to communicate with service provider 114. For example, host computing device 150 can replace memory pages and / or modify page table 222 without receiving instructions from service provider 114.

[0075] In block 508D, computer-readable medium 206 can be reset. Specifically, in some embodiments, providing service 114 may cause computer-readable medium 206 to be restored to the initial storage device state received at the previous block 502. For example, image data may be loaded onto computer-readable medium 206. Alternatively or additionally, if a mechanism is used during execution to track changes to computer-readable medium 206, it may only be necessary to restore changes to computer-readable medium 206, which can be done via copy-on-access or copy-on-write methods. Therefore, instead of storing an entire snapshot of the storage device, providing service 114 only requires storing or causing incremental changes to the storage device. As described herein, host computing device 150 may cause computer-readable medium 206 to be restored to its initial storage device state without having to communicate with providing service 114.

[0076] In some implementations, at block 508A, additional components can be reset in the execution environment. For example, the operating system 214 or its components (such as sockets, file descriptors, pipes, and / or queues) can be reset to their initial state. As another example, additional physical components or peripherals can be reset to their initial state. Example additional peripherals to be reset may include a graphics processing unit (GPU) that may have states, registers, and / or caches to be cleared and / or reset.

[0077] In some implementations, as described herein, host computing device 150 may include reset device 402. Reset device 402 may include a processor configured to transmit reset instructions to hardware processor 202. As described herein, example reset device 402 may include a card (such as a Peripheral Component Internet (PCI) card) and / or a complex programmable logic device (CPLD) or field-programmable gate array (FPGA) on bus 224, which may reside on the motherboard of host computing device 150. Reset device 402 residing on host computing device 150 may be configured with specific reset instructions to reset storage devices and / or main memory 210. Storage devices, main memory 210, hardware processor 202, and / or components thereof may be configured to be powered off and on to restore at least a portion of their initial state. Some devices may require a minimum period of time to be powered off for reset.

[0078] In some implementations, as described herein, the secure code execution system 105 may allow a certain state to persist in trusted storage sector and / or trusted memory region of the storage device. When the storage device and / or memory region of the host computing device 150 is reset, the trusted storage sector and / or trusted memory region may be maintained rather than reset. Therefore, data stored in the trusted storage sector and / or trusted memory region may be available for subsequent requests or sessions during a second invocation of code instructions in the same execution environment. However, in some implementations, if a second invocation of code instructions in the same execution environment accesses data in the trusted storage sector and / or trusted memory region, service 114 may receive a state indicating that the data has been accessed.

[0079] After blocks 508A, 508B, 508C, and 508D are completed, the execution environment has been reset and is ready to accept additional code execution requests in an efficient manner. In block 510, additional requests can be processed. For example, a second code execution request can be processed, which may result in the execution of previous blocks 504, 506, and / or 508A, 508B, 508C, and 508D. Specifically, first code instructions can be received from a first user computing device. The secure code execution system 105 can receive second code instructions from a second user computing device different from the first user computing device. As described herein, after processing the first code instructions and resetting the execution environment, providing service 114 enables the second code instructions to be securely executed in the execution environment that has already been reset on the virtual machine instance of the host computing device.

[0080] refer to Figure 6 This illustrates the illustrative interactions used to provide a secure execution environment. Figure 6 Environment 600 may be related to Figure 1A or Figure 1B The environment is 100% similar. For example, Figure 6 The user computing device 102A may be Figure 1A The computing device of the user computing device 102. Similarly, Figure 6 The host computing device 150 can be connected with Figure 2 The host computing device 150 is similar. However, for ease of discussion, related figures (such as, Figure 1A , Figure 1B or Figure 2 Some components in Figure 6 The description of the environment in 600. Figure 6 The interaction shown is an example interaction. In other embodiments, other interactions (not shown) may be possible according to this disclosure. Figure 1A The communication descriptions are similar, but not every possible communication is possible. Figure 6 As shown in the image.

[0081] Figure 6 The interaction begins in step one (1), where service 114 provides multiple execution environments on different host computing devices (such as a first host computing device 150D and a second host computing device 150E). Example provision may include initially creating an execution environment from a base image. Initial execution environment state may be received from one or more of the first host computing device 150D and the second host computing device 150E. Additional details regarding the creation of execution environments and / or the receipt of environment states are provided above regarding... Figure 3A and Figure 5 As described herein, the on-demand code execution system 110 may include a number of host computing devices. Figure 6 The interaction may involve code execution and / or migration of environment states between host computing devices (such as the first host computing device 150D and the second host computing device 150E).

[0082] In step two (2), user computing device 102A may submit a code execution request that can be received by gateway service 112, which may be forwarded to service provider 114 and / or host computing devices 150D, 150E. In step three (3), user code instructions of user computing device 102A may be executed in an execution environment on at least the first host computing device 150D. For example, in the event of performance degradation, the code instructions may be executed on the first host computing device 150D and may eventually be migrated to the second host computing device 150E. In other cases and / or embodiments, the same code instructions may be executed on the first host computing device 150D and the second host computing device 150E to determine which host device is better at executing the code instructions.

[0083] In step four (4), service 114 manages the execution environment of host computing devices 150D and 150E. Similarly, in the event of performance degradation or poor performance of the first host computing device 150D, service 114 receives intermediate execution environment states (such as hardware processor, memory device, and / or storage device states) while the first host computing device 150D executes code instructions. Service 114 can suspend the execution of code instructions, which may include suspending the entire virtual machine instance. Service 114 can transfer the intermediate execution environment state to the second host computing device 150E. The execution environment on the second host computing device 150E can be initialized based on the intermediate execution environment state. Service 114 can cause the execution of code instructions to resume on the second host computing device 150E instead of the first host computing device 150D.

[0084] Management of the execution environment of host computing devices 150D and 150E may also include running code instructions on multiple host computing devices and determining which host device performs better, which may be referred to as A / B testing. Service 114 may collect performance data regarding the execution of code instructions on the first host computing device 150D. Similarly, service 114 may collect performance data regarding the execution of code instructions on the second host computing device 150E. Example performance metrics may include processor, memory, and / or storage device performance. Service 114 may compare performance data from host computing devices 150D and 150E to determine that one host computing device has a higher performance metric than the other relative to each other. In response to determining that the performance of one host computing device is worse than another, the execution of code instructions on the host computing device may be canceled. As described herein, canceling the execution of code instructions on a host computing device may cause the execution environment of that host to be reset.

[0085] Figure 7 This is a flowchart illustrating an example method 700 for securely handling code execution requests across multiple host computing devices, implemented by a secure code execution system 105. As described herein, the secure code execution system 105 may include a service 114. In some embodiments, the service 114 may implement aspects of method 700. In particular, method 700 may be able to migrate code execution from a first host computing device to a second host computing device, and / or determine which host computing device has better performance to continue processing code execution.

[0086] At box 701, multiple execution environments can be initialized. As described herein, the on-demand code execution system 110 may include a number of host computing devices. Service 114 provides multiple execution environments on different host computing devices. Figure 7 The box 701 used for initializing the execution environment may be related to Figure 5 Similar to box 501 for initializing the execution environment. For example, multiple virtual machine instances and / or host computing devices may initially use and / or share the same basic execution environment.

[0087] In box 702, the initial execution environment state can be received. Figure 7 Box 702, used to receive the initial execution environment state, may be related to... Figure 5 This is similar to box 502, which is used to receive the initial execution environment state. For example, service 114 may receive the initial execution environment state from one or more host computing devices.

[0088] In box 704, a code execution request may be received. For example, gateway service 112 may receive a code execution request from user computing device 102A. This request may be processed in part by service provider 114 and / or on-demand code execution system 110 as described herein.

[0089] In box 706, user code can be executed. For example, user code can be executed within the execution environment of a host computing device 150D or 150E. Figure 7 Box 706, used for executing user code, may be related to Figure 5 Similar to box 506 for executing user code. As described herein, in the event of performance degradation, code instructions may be executed on the first host computing device 150D and may eventually be migrated to the second host computing device 150E. In other cases and / or embodiments, the same code instructions may be executed on both the first host computing device 150D and the second host computing device 150E to determine which host device is better at executing the code instructions. Also at box 706, while user code instructions are being executed in the execution environment, service 114 may receive status from either host computing device 150D or 150E.

[0090] At box 707, the execution environment can be managed. Service 114 manages the execution environment of host computing devices 150D and 150E. Service 114 can determine that a host computing device, such as the first host computing device 150D, has performance problems associated with executing first code instructions on the host computing device. In this case (in the case of degraded or poor performance of the first host computing device 150D), service 114 can receive intermediate execution environment states. Service 114 can suspend the execution of the first code instructions in the execution environment on the virtual machine instance of the first host computing device 150D. Service 114 can then receive intermediate hardware processing states, intermediate memory device states, and / or intermediate storage device states. The intermediate execution environment states can be transferred to the second host computing device 150E. Service 114 can initialize the execution environment on the virtual machine instance of the second host computing device 150E based on the intermediate execution environment states (such as intermediate hardware processing states, intermediate memory device states, and / or intermediate storage device states). The service 114 can cause the execution of code instructions to resume on the second host computing device 150E instead of the first host computing device 150D, thereby completing the migration.

[0091] As described herein, managing an execution environment for multiple host computing devices may also include running code instructions on multiple devices and determining which host device performs better (i.e., A / B testing). After executing some code instructions on a first host computing device 150D, service 114 may collect first performance data regarding the execution of the code instructions. Similarly, after executing some code instructions on a second host computing device 150E, service 114 may collect second performance data regarding the execution of the code instructions. Service 114 may calculate performance metrics, such as processor, memory, and / or storage device performance, based on the performance data. Service 114 may compare performance data from host computing devices 150D and 150E to determine that, relative to each other, one host computing device has a higher performance metric than the other for executing the same or similar code instructions. In response to determining that the performance of one host computing device is worse than that of another, service 114 may cancel the execution of code instructions on the host computing device.

[0092] At box 708, the execution environment of multiple host computing devices can be reset. For example, if the execution of code instructions is canceled, the execution environment can be reused, and in this case, the execution environment should be reset as described herein. In another case, where code instructions are migrated to another execution environment on another host computing device, the execution environment may still need to be reset for reuse after the execution of the code instructions is completed. Figure 7 Box 708, used to reset the execution environment, may be related to... Figure 5 Similar to box 508 used to reset the execution environment.

[0093] It should be understood that not all objectives or advantages can be achieved according to any particular implementation described herein. Therefore, for example, those skilled in the art will recognize that certain implementations may be configured to operate in a manner that achieves or optimizes one or a set of advantages as taught herein, without necessarily achieving other objectives or advantages as may be taught or suggested herein.

[0094] All the processes described herein can be embodied in and fully automated via software code modules executed by a computing system comprising one or more computers or processors. These code modules can be stored in any type of non-transitory computer-readable medium or other computer storage device. Some or all of the methods can be embodied in dedicated computer hardware.

[0095] According to this disclosure, many other changes besides those described herein will be apparent. For example, depending on the implementation, certain actions, events, or functions of any of the algorithms described herein may be performed in a different order, added, combined, or omitted entirely (e.g., not all described actions or events are necessary for the practice of the algorithm). Furthermore, in some implementations, actions or events may be performed simultaneously (e.g., through multithreading, interrupt handling, or multiple processors or processor cores or other parallel architectures) rather than sequentially. Additionally, different tasks or processes may be performed by different machines and / or computing systems that can work together.

[0096] The various illustrative logic blocks and modules described in conjunction with the embodiments disclosed herein can be implemented or executed by a machine, such as a processing unit or processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. The processor may be a microprocessor, but alternatively, it may be a controller, a microcontroller, or a state machine, a combination thereof, etc. The processor may include circuitry configured to process computer-executable instructions. In another embodiment, the processor includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, a combination of one or more microprocessors and a DSP core, or any other such configuration. While this document primarily describes digital technologies, the processor may also primarily include analog components. For example, some or all of the signal processing algorithms described herein may be implemented in analog circuitry or a mixture of analog and digital circuitry. The computing environment may include any type of computer system, including (but not limited to) computer systems based on microprocessors, mainframe computers, digital signal processors, portable computing devices, device controllers, or computing engines within appliances (to name just a few).

[0097] Unless otherwise expressly stated, conditional languages ​​such as “can,” “may,” “possibly,” or “may,” in particular, should be understood in the context to generally convey that certain embodiments include certain features, elements, and / or steps, while other embodiments do not. Therefore, such conditional languages ​​are not generally intended to imply that the stated features, elements, and / or steps are necessary for one or more embodiments in any way, or that one or more embodiments must include logic for determining, with and without user input or prompting, whether to include these features, elements, and / or steps, or whether to perform these features, elements, and / or steps in any particular embodiment. The terms “comprising,” “including,” “having,” etc., are synonymous and used inclusively in an open form, and do not exclude additional elements, features, actions, operations, etc. Furthermore, as used herein, the term “each,” in addition to its ordinary meaning, may refer to any subset of the set of elements to which the term “each” is applied.

[0098] Unless otherwise expressly stated, connective language such as “at least one of X, Y or Z” is otherwise understood in the context to generally represent that an item, term, etc., may be X, Y or Z or any combination thereof (e.g., X, Y and / or Z). Therefore, such disjunctive language is generally not intended and should not imply that certain embodiments require the presence of at least one of X, at least one of Y or at least one of Z.

[0099] Any process description, element, or block described herein and / or shown in the flowcharts in the accompanying drawings should be understood as potentially representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or element in the process. As those skilled in the art will understand, alternative implementations are included within the scope of the embodiments described herein, wherein elements or functions may be omitted, or performed in a different order than shown or discussed, including substantially simultaneously or in reverse order, depending on the functionality involved.

[0100] Unless otherwise expressly stated, articles such as “a” or “an” should generally be understood to include one or more of the described items. Thus, phrases such as “a device configured to…” are intended to include one or more of the stated devices. Such one or more of the stated devices may also be configured collectively to perform the stated narrative. For example, “a processor configured to perform narratives A, B, and C” may include a first processor configured to work in conjunction with a second processor configured to perform narratives B and C to perform narrative A.

[0101] It should be emphasized that many changes and modifications can be made to the above embodiments, and these changes and modifications should be understood as existing in other acceptable examples. All such modifications and variations are intended to be included within the scope of this disclosure and are protected by the following claims.

[0102] Examples of embodiments of this disclosure may be described in light of the following terms.

[0103] Clause 1. A computer-implemented method comprising: receiving, under the control of a computer hardware processor configured with specific computer-executable instructions, a first hardware processor state from a host computing device in an on-demand code execution system; receiving, from the host computing device, a first storage device state from a storage device of the host computing device; causing code instructions to execute in an execution environment on a virtual machine instance of the host computing device; while causing the code instructions to execute in the execution environment on the virtual machine instance of the host computing device, receiving, from the host computing device, a storage device state from the host computing device, wherein the execution of the code instructions causes: the hardware processor of the host computing device to change to a second hardware processor state, the storage device of the host computing device to change to a second storage device state, and the storage device of the host computing device to change state; and resetting the execution environment on the virtual machine instance of the host computing device, wherein resetting the execution environment further comprises: transmitting a reset instruction to the hardware processor of the host computing device, wherein the reset instruction is configured to cause the hardware processor of the host computing device to return to the first hardware processor state; cause the storage device of the host computing device to return to the first storage device state; and causing the storage device of the host computing device to return to an initial state, at least in part based on the storage device state.

[0104] Clause 2. The computer-implemented method as described in Clause 1, wherein executing code instructions causes: a memory device state indicating a memory page being accessed or modified is recorded in the host computing device.

[0105] Clause 3. The computer-implemented method as described in Clause 2, wherein recording the state of the memory device indicating the accessed memory page further includes: generating a copy of the accessed memory page.

[0106] Clause 4. The computer-implemented method as described in Clause 2, wherein recording the state of the memory device indicating the accessed memory page further includes: generating a copy of the modified memory page.

[0107] Clause 5. A computer-implemented method as described in Clause 3 or 4, wherein causing the memory device of the host computing device to return to the initial state based at least in part on the memory device state further includes discarding the copied memory pages.

[0108] Clause 6. A computer-implemented method as described in any of the preceding clauses, wherein the reset instruction is further configured to refresh the cache of the hardware processor.

[0109] Clause 7. A system comprising: a data storage medium; and one or more computer hardware processors communicating with the data storage medium, the one or more computer hardware processors being configured to execute computer-executable instructions to at least: receive a first hardware processor state from a host computing device in an on-demand code execution system; cause the first code instructions to execute in an execution environment on a virtual machine instance of the host computing device; while causing the first code instructions to execute in the execution environment on the virtual machine instance of the host computing device, the one or more computer hardware processors are further configured to: receive a memory device state from a memory device of the host computing device, wherein the execution of the first code instructions causes: the hardware processor of the host computing device to change to a second hardware processor state, and the memory device of the host computing device to change state; and reset the execution environment on the virtual machine instance of the host computing device, wherein, in order to reset the execution environment, the one or more computer hardware processors are further configured to: transmit a reset instruction to the hardware processor of the host computing device, wherein the reset instruction is configured to cause the hardware processor of the host computing device to return to the first hardware processor state; and cause the memory device of the host computing device to return to an initial state, at least in part based on the memory device state.

[0110] Clause 8. The system as described in Clause 7, wherein, in order to cause the first code instruction to execute, the host computing device is further configured to: create a bitmap indicating at least a first clean memory page and a second memory page that have been accessed or modified, wherein the memory device state indicates that the second memory page has been accessed or modified.

[0111] Clause 9. The system as described in Clause 8, wherein, in order to restore the memory device of the host computing device to the initial state based at least in part on the memory device state, the one or more computer hardware processors are further configured to: identify a first clean memory page and a second memory page that have been accessed or modified using a bitmap; maintain the first clean memory page; and replace the accessed or modified second memory page with a clean second memory page.

[0112] Clause 10. A system as described in Clause 7 or 8, wherein at least a portion of the memory device is instructed to be de-energized and energized in order to restore the memory device of the host computing device to its initial state.

[0113] Clause 11. The system of any one of Clauses 7 to 10, wherein the host computing device further comprises a reset device, wherein the reset device comprises a processor of one or more computer hardware processors configured to transmit the reset instruction to the hardware processor of the host computing device.

[0114] Clause 12. The system of any one of Clauses 7 to 11, wherein the first code instruction is received from a first user computing device, and wherein the one or more computer hardware processors are further configured to: receive a second code instruction from a second user computing device other than the first user computing device; and cause the second code instruction to be executed in an execution environment on a virtual machine instance of the host computing device.

[0115] Clause 13. A system comprising: a data storage medium; and one or more computer hardware processors communicating with the data storage medium, the one or more computer hardware processors being configured to execute computer-executable instructions to at least: receive a first hardware processor state from a first host computing device in an on-demand code execution system; receive a memory device state from a memory device of the first host computing device while first code instructions are executed in a first execution environment on a first virtual machine instance of the first host computing device, wherein execution of the first code instructions causes: the hardware processor of the first host computing device to change to a second hardware processor state, and the memory device of the first host computing device to change state; and reset the first execution environment on the first virtual machine instance of the first host computing device, wherein, for resetting the execution environment, the one or more computer hardware processors are further configured to: transmit a reset instruction to the hardware processor of the first host computing device, wherein the reset instruction is configured to cause the hardware processor of the first host computing device to return to the first hardware processor state; and cause the memory device of the first host computing device to return to an initial state, at least in part based on the memory device state.

[0116] Clause 14. The system as described in Clause 13, wherein the one or more computer hardware processors are further configured to: suspend the execution of the first code instructions in the first execution environment on the first virtual machine instance of the first host computing device while the first code instructions are being executed in the first execution environment on the first virtual machine instance of the first host computing device; receive a second hardware processor state from the first host computing device; transmit the second hardware processor state and memory device state to the second host computing device; cause a second execution environment on the second virtual machine instance of the second host computing device to be initialized according to the second hardware processor state and memory device state; and resume the execution of the first code instructions in the second execution environment on the second virtual machine instance of the second host computing device.

[0117] Clause 15. The system as described in Clause 14, wherein the one or more computer hardware processors are further configured to: determine that there is a performance problem associated with executing the first code instructions on the first host computing device.

[0118] Clause 16. The system of any one of Clauses 13 to 15, wherein the one or more computer hardware processors are further configured to: collect first performance data relating to the execution of the first code instructions on the first host computing device; cause a second execution of the first code instructions in a second execution environment on a second virtual machine instance of the second host computing device; and collect second performance data relating to the execution of the first code instructions on the first host computing device.

[0119] Clause 17. The system as described in Clause 16, wherein the one or more computer hardware processors are further configured to: determine that the second performance data has a higher performance metric relative to the first performance data; and cancel the execution of the first code instruction on the first host computing device.

[0120] Clause 18. The system of any one of Clauses 13 to 17, wherein the first host computing device includes a storage device, the storage device including a trusted storage device sector, wherein the one or more computer hardware processors are further configured to: receive from the first host computing device a first storage device state indicating that the first data is stored in the trusted storage device sector when the first code instructions are executed in a first execution environment on a first virtual machine instance of the first host computing device, wherein, in order to reset the first execution environment, the one or more computer hardware processors are further configured to: maintain the first data in the trusted storage device sector.

[0121] Clause 19. The system as described in Clause 18, wherein the one or more computer hardware processors are further configured to: cause second code instructions to execute in a first execution environment on a first virtual machine instance of a first host computing device; and, while the second code instructions are executing in the first execution environment on the first virtual machine instance of the first host computing device, receive from the first host computing device a second storage device state indicating that first data has been accessed on a trusted storage device sector.

[0122] Clause 20. The system of any one of Clauses 13 to 19, wherein the one or more computer hardware processors are further configured to: initialize a basic execution environment on the first virtual machine instance of the first host computing device; and insert custom data for the first code instructions into the basic execution environment to obtain a first execution environment, wherein execution of the first code instructions in the first execution environment accesses the custom data.

Claims

1. A computer-implemented method, comprising: Under the control of a computer hardware processor configured with specific computer-executable instructions, Receive a first hardware processor state from the hardware processor of the host computing device in the on-demand code execution system; Receive a first storage device status from the storage device of the host computing device; This causes the code instructions to execute in the execution environment of the virtual machine instance on the host computing device; When the code instructions are caused to execute in the execution environment on the virtual machine instance of the host computing device, Receives a memory device state from the host computing device's memory device, wherein the execution of the code instructions results in: The hardware processor of the host computing device is changed to a second hardware processor state. The storage device of the host computing device is changed to a second storage device state, and The memory device of the host computing device changes state; as well as Resetting the execution environment on the virtual machine instance of the host computing device, wherein resetting the execution environment further includes: A reset instruction is transmitted to the hardware processor of the host computing device, wherein the reset instruction is configured to cause the hardware processor of the host computing device to return to the first hardware processor state; This causes the storage device of the host computing device to return to the state of the first storage device; and The memory device of the host computing device is restored to its initial state, at least in part, based on the state of the memory device.

2. The computer-implemented method of claim 1, wherein causing the code instructions to execute results in: The host computing device records the state of the memory device indicating which memory pages have been accessed or modified.

3. The computer-implemented method of claim 2, wherein recording the memory device state indicating the accessed memory page further comprises: Generate a copy of the accessed memory page.

4. The computer-implemented method of claim 3, wherein causing the memory device of the host computing device to return to the initial state based at least in part on the memory device state further includes discarding the copied memory pages.

5. A computer system comprising: Data storage media; as well as One or more computer hardware processors, the one or more computer hardware processors communicating with the data storage medium, the one or more computer hardware processors being configured to execute computer-executable instructions to at least: Receives a first hardware processor state from the hardware processor of the first host computing device in the on-demand code execution system; This causes the first code instruction to be executed in a first execution environment on a first virtual machine instance of the first host computing device; When the first code instructions are executed in the first execution environment on the first virtual machine instance of the first host computing device, the one or more computer hardware processors are further configured to: Receives a memory device state from the memory device of the first host computing device, wherein the execution of the first code instruction results in: The hardware processor of the first host computing device changes to a second hardware processor state, and The memory device of the first host computing device changes state; as well as Reset the first execution environment on the first virtual machine instance of the first host computing device, wherein, for resetting the first execution environment, the one or more computer hardware processors are further configured to: A reset instruction is transmitted to the hardware processor of the first host computing device, wherein the reset instruction is configured to cause the hardware processor of the first host computing device to return to the first hardware processor state. and The memory device of the first host computing device is restored to its initial state, at least in part, based on the state of the memory device.

6. The system of claim 5, wherein, for causing the first code instruction to execute, the first host computing device is further configured to: Create a bitmap indicating at least a first clean memory page and a second memory page that have been accessed or modified, wherein the memory device state indicates that the second memory page has been accessed or modified.

7. The system of claim 6, wherein, for restoring the memory device of the first host computing device to the initial state based at least in part on the memory device state, the one or more computer hardware processors are further configured to: The bitmap is used to identify the first clean memory page and the second memory page that have been accessed or modified. Maintain the first clean memory page; and Replace the accessed or modified second memory page with a clean second memory page.

8. The system of claim 5, wherein the first host computing device further includes a reset device, wherein the reset device includes a processor of the one or more computer hardware processors, the processor being configured to transmit the reset instruction to the hardware processor of the first host computing device.

9. The system of claim 5, wherein, in order to cause the memory device of the first host computing device to return to the initial state, at least a portion of the memory device is instructed to be de-energized and energized.

10. The system of claim 5, wherein the first code instruction is received from a first user computing device, and wherein the one or more computer hardware processors are further configured to: Receive second code instructions from a second user computing device different from the first user computing device; and This causes the second code instruction to be executed in the first execution environment on the first virtual machine instance of the first host computing device.

11. The system of claim 5, wherein the one or more computer hardware processors are further configured to: When the first code instruction is executed in the first execution environment on the first virtual machine instance of the first host computing device... Suspend the execution of the first code instruction in the first execution environment on the first virtual machine instance of the first host computing device; Receive the status of the second hardware processor from the first host computing device; Transmit the state of the second hardware processor and the state of the memory device to the second host computing device; This causes the second execution environment on the second virtual machine instance of the second host computing device to be initialized according to the state of the second hardware processor and the state of the memory device; and Resume execution of the first code instruction in the second execution environment on the second virtual machine instance of the second host computing device.

12. The system of claim 5, wherein the first host computing device includes a storage device, the storage device including trusted storage device sectors, wherein the one or more computer hardware processors are further configured to: When the first code instruction is executed in the first execution environment on the first virtual machine instance of the first host computing device... Receives from the first host computing device a first storage device state indicating that the first data is stored on the trusted storage device sector. In order to reset the first execution environment, the one or more computer hardware processors are further configured to: The first data is maintained in the sector of the trusted storage device.

13. The system of claim 12, wherein the one or more computer hardware processors are further configured to: This causes the second code instructions to execute in the first execution environment on the first virtual machine instance of the first host computing device; and When the second code instruction is executed in the first execution environment on the first virtual machine instance of the first host computing device... The first host computing device receives a second storage device status indicating that the first data has been accessed on the sector of the trusted storage device.

14. The system of claim 5, wherein the one or more computer hardware processors are further configured to: Initialize the basic execution environment on the first virtual machine instance of the first host computing device; and Custom data of the first code instruction is inserted into the basic execution environment to obtain the first execution environment, wherein the execution of the first code instruction in the first execution environment accesses the custom data.

Images