Methods, systems, and computer-readable media for managing containers

Abstract

Embodiments of the present disclosure relate to methods, systems, and computer-readable media for managing containers. A container corresponding to executable code may be received. In response to receiving the container, a container manager residing in a memory of a computing environment may be executed to verify the container. The container manager may be verified by a boot loader of the computing environment. Permission for the container to access resources of the computing environment may be determined after verification of the container by the container manager. Based on the permission of the container for resources of the computing environment, access to one or more resources of the computing environment may be provided by transferring control of the one or more resources from the container manager to the container.

Description

[0001] Related Applications

[0002] This application is a divisional application of the invention patent application with international application number PCT / US2016 / 046428, international application date August 10, 2016, date of entry into the Chinese national phase January 19, 2018, Chinese national application number 201680042707.6, and invention name “Methods, systems and computer-readable media for managing containers”. Technical Field

[0003] Embodiments of the present disclosure relate to methods, systems, and computer-readable media for managing containers. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The present disclosure will be more fully understood from the detailed description given below and the accompanying drawings of various implementations of the present disclosure.

[0005] Figure 1 An example secure computing environment with a boot loader, a container manager, and one or more containers is illustrated according to some embodiments of the present disclosure.

[0006] Figure 2 An example architecture of a secure computing environment in accordance with some embodiments is illustrated.

[0007] Figure 3 is a flow chart of an example method of providing a secure computing environment according to some embodiments of the present disclosure.

[0008] Figure 4 is a flow chart of an example method for executing a boot loader of a secure computing environment according to some embodiments.

[0009] Figure 5A is a flow chart of an example method for providing time-sharing of resources of a secure computing environment according to some embodiments of the present disclosure.

[0010] Figure 5B is a flow chart of an example method for executing a container manager of a secure computing environment according to some embodiments of the present disclosure.

[0011] Figure 6 is a flow chart of an example method of updating a container manager according to some embodiments of the present disclosure.

[0012] Figure 7 An example container manager interacting with one or more containers and memory locations is illustrated in accordance with some embodiments.

[0013] Figure 8An example method for providing interaction between containers according to some embodiments of the present disclosure is illustrated.

[0014] Fig. 9 An example of a container interacting with a memory is illustrated in accordance with some embodiments.

[0015] Fig.10 An exemplary method of a container interacting with a component external to a secure computing environment in accordance with some embodiments is illustrated.

[0016] Fig.11 Illustrated is a block diagram of an embodiment of a computer system in which some embodiments of the present disclosure may operate. DETAILED DESCRIPTION

[0017] Aspects of the present disclosure relate to a secure computing environment. A system or device may include a boot loader, a container manager, and one or more containers that may be used to provide a secure computing environment. The boot loader may be a hardware-based state machine that may be started or executed in response to initialization of the system or device. During execution of the boot loader, a container manager stored in a memory such as a read-only memory (ROM) of the system, or stored via an interconnection of the system or device (e.g., as represented by a netlist), or stored in flash memory or other storage on the system or device may be executed after the boot loader has performed an initialization process for the secure computing environment and after the container manager has been authenticated.

[0018] The boot loader may verify the container manager. The verification may include hashing the result and comparing the result to an expected result. For example, the hash may correspond to a secure hash algorithm (SHA) operation such as a SHA-2 or SHA-3 operation. Alternatively, the verification may include a boot loader using a public key cryptography. For example, the verification may be based on an elliptic curve cryptographic digital signature (ECDS) operation. After the container manager has been verified, the boot loader may allow the container manager to control a central processing unit (CPU) or other such processing device or hardware of a secure computing environment of a system or device. The container manager may be software of a system or device with higher or highest privileges that provides certain functionality for a subsequently received container corresponding to an unsecure user code. Thus, the boot loader may verify the container manager and authorize the container manager to control the CPU of the system or device after the container manager is verified.

[0019] The container manager can provide a framework for the execution of containers. Each container can correspond to executable code or instructions (e.g., received after the manufacture of the system or device) and permissions to access certain functions or resources of the system or device. The container manager can continuously receive and execute containers so that the resources of the secure computing environment of the system or device are shared or time-shared by the containers.

[0020] The framework provided by the container manager can further facilitate communication or interaction between containers. For example, the container manager can execute a first container and receive data from the first container to be stored in an inter-process communication (IPC) register or memory. The first container can also specify to the container manager the identity of a subsequent container that is authorized to receive the data. The container manager can then store the data received from the first container, the identity of the receiving container (e.g., the identity of the subsequent container to which the data is intended to be received), and the identity of the sender of the data in the IPC register or memory (e.g., the first container). The subsequent container can be executed by the container manager, and when the container manager executes the second container, the container manager can provide the data from the first container stored in the IPC register to the second container so that the data can be used during the execution of the second container. If the identity of the second container is different from the identity of the receiving container, the container manager can restrict access to the IPC register or memory. The container manager can store the sender container identity in the register or memory of the IPC itself so that the sender container can not provide an erroneous identity.

[0021] The container manager may further provide the container with functionality for communicating with components or entities outside the secure computing environment. For example, the system may include a high-level operating system (HLOS) register or memory that may be used to provide an indication of a data request from the container and receive corresponding data for the container from an external entity outside the secure computing environment. For example, the container may send data to the container manager for storage at the HLOS register, the data indicating a request for a particular type of data. The external software application or component may access the HLOS register and may identify that the HLOS register currently indicates a request for a particular type of data. In response, the external software application or component may provide the requested data to the HLOS register, and the container manager may allow the container to retrieve the data received from the external software application or component that is currently stored in the HLOS register or memory.

[0022] In addition, the secure computing environment may allow the container to verify the container manager. For example, the boot loader may provide a version number or other such identification of the container manager when the boot loader is executed, and the version number may be stored in a specific register or memory location. The container executed by the container manager may include instructions to verify the version number of the container manager. For example, the container may be provided with access to the version number in a specific register or memory location, and may be executed based on the version number of the container manager. For example, if the version number of the container manager matches the authorized version number of the container manager from the instructions of the container, the container may be executed. However, if the version number of the container manager does not match the authorized version number of the container manager from the instructions of the container, the container may not further implement or execute the operation of its instructions.

[0023] Thus, aspects of the present disclosure may provide a secure computing environment in which a boot loader of a system or device may authenticate a container manager, which may further provide a framework for executing user code in the form of a container. In addition, the container may further authenticate the container manager so that execution of the container may be performed in the secure computing environment.

[0024] Figure 1 An example secure computing environment 100 is illustrated having a boot loader 110, a container manager 121 stored in a read-only memory 120, and one or more containers 130. In general, the secure computing environment 100 may correspond to a portion of a system or device that provides a secure computing environment for one or more containers 130.

[0025] like Figure 1As shown, the secure computing environment 100 may include a boot loader 110 that interacts with a container manager 121 stored in a read-only memory (ROM) 120 of a device that includes the secure computing environment 100. The boot loader 110 may be a hardware-based state machine that is executed in response to initialization (i.e., power-up) of the secure computing environment 100 or a device that includes the secure computing environment 100. In addition, the boot loader 110 may perform a series of power-on self-tests (e.g., programs that are executed immediately after power-up or boot-up) of the secure computing environment 100. The self-tests performed by the boot loader 110 may include verification or performance testing of hardware components of the secure computing environment 100. For example, the self-test may include testing of a CPU or processing device that is part of the secure computing environment 100. The boot loader 110 may further perform an integrity check of the contents of the ROM 120 of the secure computing environment 100. For example, the boot loader 110 may perform verification or integrity checking of the container manager 121 by retrieving the contents of the container manager 121 and calculating an integrity check value for the contents of the container manager 121. The calculated integrity check value may be compared with another stored integrity check value to determine the authenticity or verification of the container manager 121. The integrity check value may correspond to a hash value based on a hash function used to map digital data of an arbitrary size (e.g., the contents of the container manager 121) to digital data of a fixed size (e.g., the calculated integrity check value). Figure 3 To describe further details about the execution of the boot loader.

[0026] After the self-check is successfully completed, the boot loader 110 may start or execute the container manager 121 stored in the ROM 120. For example, the boot loader 110 may start the container manager 121 after verifying the CPU and the ROM 120 or other memory of the secure computing environment 100. Control of the CPU or other hardware resources of the secure computing environment 100 may then be provided to the container manager 121 from the boot loader 110. In some embodiments, the container manager 121 may correspond to a trusted embedded lightweight software that provides functionality to hardware resources and software resources of the secure computing environment. For example, the container manager 121 may provide an application programming interface (API) that defines functionality such as system calls to access software resources or hardware resources of the secure computing environment 100. The container manager 121 may also receive one or more containers 130 corresponding to untrusted user code that is received from outside the secure computing environment 100. The container manager 121 may verify the permission of the received container 130 to access resources of the secure computing environment 100, verify the authenticity of the received container 130, and provide a framework for communication between containers 130 and between containers 130 and external entities or components outside the secure computing environment 100. Figure 5A-10 Further details regarding the container manager 121 are disclosed.

[0027] The container manager 121 may be executed in response to receiving one of the containers 130 or in response to one of the containers 130 executing a system call to access resources of the secure computing environment 100. After verification of the received container, the container manager 121 may provide control of the CPU or processing device of the secure computing environment 100 to the received container. Each of the one or more containers 130 may also correspond to untrusted user code that provides instructions and / or data for accessing resources of the secure computing environment 100. As described in relation to Figure 5A As described in additional detail in , the containers 130 can be received in series so that resources of the secure computing environment 100 are shared among the containers 130 in a time-sharing manner.

[0028] Figure 2 An example architecture 200 of a secure computing environment is illustrated. In general, the architecture 200 may include components corresponding to Figure 1 The boot loader 110 of the boot loader 210 corresponds to Figure 1 The container manager 121 of the container manager 250, and the container manager 250 corresponding to Figure 1 One or more containers 130 of container 240.

[0029] like Figure 2As shown, the architecture 200 may include a boot loader 210 that controls a CPU 220 or other such processing device, a container manager 250 stored in a ROM or other such memory, and a container 240 stored in a static random access memory (SRAM) or other such memory. A memory bus 230 may couple the container 240 and the container manager 250 with the boot loader 210 and other resources 232A-H of the architecture 200.

[0030] The architecture 200 may include a resource implementation core 260 that implements control or access to resources 232A-H of the architecture 200. Such resources may include, but are not limited to: one-time programmable (OTP) memory write or burn, OTP read, feature read, feature write, cryptographic key read, cryptographic key update, general purpose input / output (GPIO) read, GPIO write, the ability to execute code or instructions via or on the CPU 220, access to executable areas of SRAM, read access to a specific portion of any such memory, write access to a specific portion of such memory, etc. Access may be fine-grained. For example, the resource implementation core may allow write access to one byte of the OTP, but not allow write access to the next byte. Other resources may include access to the functions of the core 251 stored in ROM. Such a core 251 may correspond to elliptic curve cryptography (ECC) key generation, ECC signature verification, ECC signature generation, cryptographic key exchange, RSA key generation, RSA encryption or decryption, advanced encryption standard (AES) encryption or decryption, SHA-2 or SHA-3 functions, etc. In some embodiments, the resource enforcement core 260 may be programmed by the container manager 250 prior to the execution of each container 240. For example, the container 240 may include an identification of permissions for features or resources 232A-H, and the container manager 250 may program registers or memories of the resource enforcement core 260 based on the permissions of the container 240 to be executed. Thus, the resource enforcement core 260 may implement access to the resources 232A-H via the secure bus 231 for containers 240 that have been verified by the container manager 250. In some embodiments, one or more of the resources 232A-H may be coupled to external components of a device including the architecture 200. For example, the resource 232B may be coupled to another system on chip (SoC), OTP memory, random number generator component, or other such component external to the secure computing environment.

[0031] Figure 3is a flow chart of an example method 300 for providing a secure computing environment. In general, the method 300 may be performed by processing logic, which may include hardware (e.g., a processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, integrated circuit, etc.), software (e.g., instructions running or executed on a processing device), or a combination thereof. In some embodiments, the method 300 corresponds to Figure 1 or Figure 2 The boot loader 110 or 210, Figure 1 or 2 container manager 121 or 250, and Figure 1 or 2. The execution flow between the containers 130 or 240.

[0032] like Figure 3 As shown, method 300 may begin with: processing logic performs verification of the secure computing environment in response to initialization of a system or device including a secure computing environment (block 310). For example, the boot loader may perform a self-test of the secure computing environment to verify hardware resources and the container manager. After verification of the secure computing environment, the processing logic may further provide access to the CPU to the container manager (block 320). For example, control of the CPU may be transferred from the boot loader to the container manager, and the container manager may be started or executed. The processing logic may further receive a container (block 330). For example, an executable code may be received. The processing logic may then execute the container manager in response to receiving the container (block 340). For example, the container manager may execute each time a container is received. Therefore, in some embodiments, the containers may be received in series so that the containers share the resources of the secure computing environment in a time-sharing manner. The container manager may execute separately each time one of the containers is received. Therefore, if a first container is received and a subsequent container is received, the container manager is executed for the first time in response to receiving the first container, and the container manager may be executed for the second time in response to receiving the subsequent container. In this way, the container manager may be executed on demand based on the reception of the container. In some embodiments, the container manager may execute after the received container initiates a system call to access resources of the secure computing environment. The processing logic may verify the container based on the container manager (block 350). In response to the container manager verifying the container, the processing logic may further execute the container (block 360). For example, control or access to the CPU may be provided so that the instructions of the container are executed. Thus, access or control to the CPU may be provided from the container manager to the container.

[0033] Figure 4is a flow chart of an example method 400 for executing a boot loader of a secure computing environment. In general, the method 400 may be performed by processing logic, which may include hardware (e.g., a processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, integrated circuit, etc.), software (e.g., instructions running or executed on a processing device), or a combination thereof. In some embodiments, the method 400 corresponds to Figure 1 or 2 of the execution flow of the boot loader 110 or 210.

[0034] like Figure 4 As shown, method 400 may begin with processing logic detecting initialization of a secure computing environment (block 410). For example, a device or system including the secure computing environment may be powered on or started after a reset. Processing logic may then perform a self-test of the secure computing environment (block 420). For example, a hardware-based state machine may perform a series of steps or tests of one or more components of the secure computing environment. Examples of such components include, but are not limited to, a CPU or memory of the secure computing environment. Processing logic may further retrieve the contents of a container manager and a stored integrity check value (block 430). For example, the contents of the container manager may be retrieved from a ROM of the secure computing environment, and the stored integrity check value may be retrieved from the same ROM or another memory location within the secure computing environment. Processing logic may then calculate a container manager integrity check value based on the contents of the container manager (block 440). For example, a hash function may be performed on the contents of the container manager or a portion of the contents to determine the container manager integrity check value.

[0035] The processing logic may then compare the stored integrity check value to the container manager integrity check value (block 450). Furthermore, the processing logic may provide the container manager with access to a CPU or other such processing device or hardware resource of the secure computing environment based on the comparison of the integrity check value (block 460). For example, if the container manager integrity check value matches the stored integrity check value, the container manager may be considered verified or authenticated, and access or control of the CPU may be provided to the container manager from the boot loader. However, if the container manager integrity check value does not match the stored integrity check value, the container manager may be considered unauthenticated or unauthorized, and access or control of the CPU may not be provided to the container manager from the boot loader.

[0036] In this way, the boot loader can perform a self-check of the resources of the secure computing environment and a verification of the container manager. After a successful self-check and successful verification of the container manager, control or access to a CPU or processing device of the secure computing environment can be provided to the container manager. In some embodiments, providing control or access to a CPU or processing device for the container manager can correspond to using the CPU or processing device for operations of the container manager.

[0037] Figure 5A 1 is a flow chart of an example method 500 for providing time-sharing of resources of a secure computing environment. In general, the method 500 may be performed by processing logic, which may include hardware (e.g., a processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, integrated circuit, etc.), software (e.g., instructions running or executed on a processing device), or a combination thereof. In some embodiments, the method 500 may be performed by Figure 1 or Figure 2 The container manager 121 or 250 executes.

[0038] like Figure 5A As shown, method 500 may begin with: processing logic receiving a first container (box 501). For example, a container manager may receive the container after initialization or execution of the container manager. In some embodiments, the container manager may be executed after a system call for access to resources of a secure computing environment has been received. Processing logic may also provide access to resources of the secure computing environment to the first container (box 502). For example, access to a CPU may be provided to the first container from the container manager. Providing control or access to a CPU or processing device for a container may correspond to using a CPU or processing device for operations or instructions for the container. Processing logic may then execute the first container (box 503). For example, the instructions of the first container may be executed by a CPU of the secure computing environment. For further details on the execution of the container, refer to Figure 5B Give a description.

[0039] The processing logic may subsequently receive a second container after completion of execution of the first container (block 504). For example, the second container may be received by the container manager after the first container. The processing logic may then provide the second container with access to resources of the secure computing environment (block 505), and may execute the second container (block 506).

[0040] In this way, the resources of the secure computing environment can be shared among a series of containers in a time-sharing manner. For example, a portion of the resources can be provided to a first container at a first time, and the portion or another portion of the resources can be provided to a subsequent second container at a second time after the first time.

[0041] Figure 5B5 is a flow chart of an example method 509 for executing a container manager of a secure computing environment. In general, the method 509 may be executed by processing logic, which may include hardware (e.g., a processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, integrated circuit, etc.), software (e.g., instructions running or executed on a processing device), or a combination thereof. In some embodiments, the method 509 may be executed by Figure 1 or Figure 2 The container manager 121 or 250 executes.

[0042] like Figure 5BAs shown, method 509 may begin with: processing logic initializing a container manager (block 510). For example, the container manager may be started by a boot loader. The startup of the container manager may perform an initial setup or initialization routine of the container manager. The processing logic may also receive a first container (block 520). In addition, the processing logic may execute the container manager by providing the container manager with control or access to the CPU in response to receiving the first container (block 530). The processing logic may then verify the first container (block 540). For example, the container manager may verify the signature of the first container. For example, the container manager may access a public key and verify the signature of the first container created by a corresponding private key (e.g., a public-private key pair). For example, the container manager may access a symmetric key and may use a hash message authentication code (HMAC) operation to verify the signature of the first container created by the corresponding key. For example, the container manager may unconditionally consider the first container to be verified. In some embodiments, the container manager may further verify other attributes of the container, such as the format of the container, the version of the container, etc. In some embodiments, the verification of the container may further include a determination of the permission of the container to access resources of the secure computing environment. After verification of the container, one or more registers accessed by the resource implementation core may be updated to reflect the permissions associated with the container accessing resources of the secure computing environment. In some embodiments, the container manager may dynamically modify registers in the resource implementation core while the container is executing. Such dynamic modification may dynamically change the permissions granted to the container. For example, the container manager may provide an application programming interface (API) for the container to facilitate the updating of the registers. The processing logic may then execute the first container (block 550) by providing the first container with control or access to the CPU in response to the verification of the first container. For example, if the container satisfies certain cryptographic properties (e.g., the cryptographic signature is valid), the instructions of the first container may be executed by the CPU. The processing logic may further detect the completion of the execution of the first container (block 560). Subsequently, the processing logic may provide the container manager with control of the CPU (block 570). For example, control or access to the CPU may be returned from the container to the container manager. The processing logic may also store the state information of the first container in a memory (block 580). For example, the first container may store some data in an IPC memory or register for use by subsequent containers. For example, the first container may allow subsequent containers to operate with some permissions attributed to the first container. For example, the container manager may track the number of containers run so far and may provide this information to container or HLOS memory or registers.

[0043] The container manager can use the container's identity to determine which resources the container can access. For example, the container's identity can be its hash (e.g., SHA-2 or SHA-3). For example, the identity can be a public key cryptographic signature of the container (e.g., ECSDA), or a public key corresponding to a private key used to generate a signature. For example, the identity can be an HMAC of the container. Optionally, the identity can also include a version number or revision number of the container, which identifies the revision history of the executable code of the container. Optionally, the identity can be a hash of various field combinations (e.g., the identity is the result of a SHA-2 operation of the public key and the revision number of the container).

[0044] In this way, the container manager can be executed in response to receiving the container and any other subsequent containers. In response to the container manager's verification of the container, the container can be provided with control or access to the CPU or other hardware resources of the secure computing environment. After the completion of the execution of the container, control or access to the CPU can be returned to the container manager, and state information of the executed container can be stored in the memory of the secure computing environment.

[0045] Figure 6 is a flow chart of an example method 600 for updating a container manager. In general, the method 600 may be performed by processing logic, which may include hardware (e.g., a processing device, a circuit, dedicated logic, programmable logic, microcode, hardware of a device, an integrated circuit, etc.), software (e.g., instructions running or executed on a processing device), or a combination thereof. In some embodiments, the method 600 may be performed by Figure 1 or Figure 2 The container manager 121 or 250 or another component of the secure computing environment is executed.

[0046] like Figure 6 As shown, method 600 may begin when processing logic receives a request to update a container manager (block 610). For example, the request to update the container manager may identify a specific instruction or operation of the container manager and a memory address location of the content of the instruction or operation. Processing logic may further retrieve a function table associated with the container manager (block 620). The function table may correspond to an ordered pair of entries, wherein a first entry of a pair identifies a specific type of instruction or operation and a second entry of the pair identifies a memory address location that includes the content of the instruction or operation. Processing logic may then update at least one field of the function table corresponding to the memory address (block 630). For example, the function table may be stored in a memory, wherein the memory may be modified to change the memory address location to a new memory address location.

[0047] The execution of the container manager may be based on the use of the function table. For example, the container manager may be used together with the function table to execute instructions or operations based on memory address locations corresponding to the instructions or operations. Thus, an update of the container manager may result in a change in the memory address location for at least one instruction or operation of the container manager.

[0048] refer to Figure 6 , the processing logic may increment a version number associated with the container manager in response to the update of the function table (block 640). For example, in response to the update of the container manager, a version number located in a memory location may be incremented or increased. In some embodiments, the version number may be stored by the boot loader in an OTP or other non-volatile medium (NVM). The boot loader may restrict execution of any container if the current version number is not greater than or equal to the maximum of all previously stored version numbers. In some embodiments, the version number of the container manager may be provided to the container. Each container may retrieve the version number of the container manager and may compare the version number of the container manager to the version number identified within the container. If the version number of the container manager does not match the version number identified within the container, the container may not execute (e.g., the instructions of the container manager may not be executed). However, if the version number of the container manager matches the version number identified within the container, the container may execute. In this way, the version number of the container manager may be used by the container to verify the container manager prior to execution of the container.

[0049] Figure 7 An example environment 700 of a container manager interacting with one or more containers is illustrated. In general, the environment 700 may include Figure 1 or Figure 2 The container manager 720 corresponds to the container manager 121 or 250 .

[0050] like Figure 7 As shown, environment 700 may include a container manager 720 that receives one or more containers 710. Container manager 720 may be further coupled to a high level operating system (HLOS) register or memory 730, and an inter-process communication (IPC) register or memory 740. Container manager 720 may execute one of containers 710, and may provide an indication of a data request from the executed container to a component external to the secure computing environment via HLOS memory 730. Container manager 720 may then retrieve data from HLOS memory 730 and provide the data to the executed container. Fig.10 Further details regarding HLOS memory 730 are described.

[0051] The container manager may further provide access to IPC memory 740 to provide communication between at least two of the containers 710. For example, data may be received from a first container received and executed by the container manager 720, and the data may be stored in IPC memory 740 for retrieval by a subsequent second container received by the container manager 720. Further details regarding IPC memory 740 will be provided in conjunction with Figure 8-9 Give a description.

[0052] Figure 8 An example method 800 for providing interaction between containers is illustrated. In general, the method 800 may be performed by processing logic, which may include hardware (e.g., a processing device, a circuit, dedicated logic, programmable logic, microcode, hardware of a device, an integrated circuit, etc.), software (e.g., instructions running or executed on a processing device), or a combination thereof. In some embodiments, the method 800 may be performed by Figure 1 or Figure 2 The container manager 121 or 250 or another component of the secure computing environment is executed.

[0053] like Figure 8 As shown, method 800 may begin with processing logic receiving data from a first container during execution of the first container (block 810). Processing logic may also receive a recipient identification of the data from the first container (block 820). For example, the recipient identification may correspond to an identification of another container. Processing logic may then store the received data, the recipient identification of the other container, and the sender identification of the data corresponding to the first container in an inter-process communication (IPC) memory or register (block 830). Processing logic may then execute a second container (block 840). For example, the second container may be received after receipt and execution of the first container. Processing logic may identify that the identification of the second container matches the recipient identification of the data stored in the IPC memory (block 850). In addition, processing logic may provide access to the data and sender identification at the IPC memory to the second container (block 860).

[0054] In some embodiments, the second container may execute instructions using data from the IPC memory based on a condition associated with a sender identification of the data. For example, if the sender identification matches a specific sender identification from the second container, the instruction may be executed, or if the sender identification does not match the specific sender identification from the second container, the instruction may not be executed.

[0055] In this way, data from the first container can be stored in a memory location of the secure computing environment. A second container executed after the first container can be provided access to the data at the memory location.

[0056] Fig. 9An example of a container interacting with a storage device is shown. In general, it may correspond to Figure 1 or Figure 2 The container manager 910 of the container manager 121 or 250 may provide interaction between containers based on the IPC memory 940 .

[0057] like Fig. 9 As shown, the container manager 910 may be coupled to the IPC memory 940 and the container pipeline 924. The container pipeline 924 may include a first container 920'A', a second container 921'B', and a third container 922'C'. The container manager 910 may receive the first container 920'A', which may be executed. The instructions of the first container 920'A' may specify data A to be stored in the IPC memory 940 for the third container 922'C'. For example, the container manager 910 may store an entry in the IPC memory 940, the entry including the data A, an identification of the first container 920 (e.g., sender 'A'), and a recipient of the data (e.g., recipient 'C'). The container manager 910 may then receive the second container 921'B' after the completion of the execution of the first container 920'A'. When the identifier of the second container 921 (e.g., 'B') does not match the identifier of the recipient of the data (e.g., 'C'), the second container 921 'B' may not be allowed to access the data in the IPC storage 940. At a later time, the container manager 910 may receive the third container 922 'C'. Since the identifier of the third container 922 (e.g., 'C') matches the identifier of the recipient of the data in the IPC storage 940, the container manager 910 may provide the third container 922 having the identifier 'C' with access to the data in the IPC storage 940.

[0058] Fig.10 An example method 1000 of a container interacting with a component outside of a secure computing environment is illustrated. In general, the method 1000 may be performed by processing logic, which may include hardware (e.g., a processing device, a circuit, dedicated logic, programmable logic, microcode, hardware of a device, an integrated circuit, etc.), software (e.g., instructions running or executed on a processing device), or a combination thereof. In some embodiments, the method 1000 may be performed by Figure 1 or Figure 2 The container manager 121 or 250 or another component of the secure computing environment is executed.

[0059] like Fig.10As shown, method 1000 may begin with: processing logic receiving a request for data outside the secure computing environment from a container (block 1010). For example, the data may correspond to data received from a component of a device that is not within the secure computing environment. The processing logic may then provide an indication of the request from the container in a high-level operating system (HLOS) memory or register (block 1020). For example, the container manager may modify the contents of the HLOS memory to indicate that a component within the secure computing environment has requested data from a component coupled to the HLOS memory. The processing logic may then receive data from an entity outside the secure computing environment via the HLOS memory (block 1030). For example, a component that is not within the secure computing environment may provide the requested data by storing the data in the HLOS memory. In addition, the processing logic may provide data from the HLOS memory to the container (block 1040). For example, the container manager may retrieve data that has been stored in the HLOS memory and may provide the data to the container for execution by the container.

[0060] In some embodiments, the HLOS memory may be the only memory location within the secure computing environment that is accessible to entities or components outside of the secure computing environment.

[0061] Fig.11 An example machine of a computer system 1100 is shown within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed. In alternative implementations, the machine may be connected (e.g., connected to a network) to other machines in a LAN, an intranet, an extranet, and / or the Internet. The machine may operate in the capacity of a server or a client machine in a client-server network environment, as a peer machine in a peer-to-peer (or distributed) network environment, or as a server or a client machine in a cloud computing infrastructure or environment.

[0062] The machine may be a personal computer (PC), a tablet computer, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a network appliance, a server, a network router, a switch or a bridge, or any machine capable of executing a set of instructions (sequentially or otherwise) that specify actions to be taken by the machine. In addition, while a single machine is illustrated, the term "machine" should also be understood to include any collection of machines that individually or jointly execute one (or more) sets of instructions to perform any one or more of the methodologies discussed herein.

[0063] The example computer system 1100 includes a processing device 1102, a main memory 1104 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM RDRAM), etc.), a static memory 1106 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 1118 that communicate with each other via a bus 1130.

[0064] The processing device 1102 represents one or more general-purpose processing devices, such as a microprocessor, a central processing unit, etc. More specifically, the processing device can be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor that implements other instruction sets, or a processor that implements a combination of instruction sets. The processing device 1102 can also be one or more special-purpose processing devices, such as an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), a network processor, etc. The processing device 1102 is configured to execute instructions 1126 for performing the operations and steps discussed herein.

[0065] The computer system 1100 may also include a network interface device 1108 for communicating over a network 1120. The computer system 1100 may also include a video display unit 1110 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 1112 (e.g., a keyboard), a cursor control device 1114 (e.g., a mouse), a graphics processing unit 1122, a signal generating device 1116 (e.g., a speaker), a graphics processing unit 1122, a video processing unit 1128, and an audio processing unit 1132.

[0066] The data storage device 1118 may include a machine-readable storage medium 1124 (also referred to as a computer-readable medium) on which is stored one or more sets of instructions or software 1126 that implement any one or more of the methodologies or functions described herein. The instructions 1126 may also reside, completely or at least partially, within the main memory 1104 and / or within the processing device 1102 during execution by the computer system 1100, the main memory 1104 and the processing device 1102 also constituting machine-readable storage media.

[0067] In one implementation, instructions 1126 include instructions for implementing instructions corresponding to a container manager (e.g., Figure 1or 2) of the container manager 121 or 200). Although the machine-readable storage medium 1124 is shown as a single medium in the example implementation, the term "machine-readable storage medium" should be understood to include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) that store one or more sets of instructions. The term "machine-readable storage medium" should also be understood to include any medium that can store or encode a set of instructions executed by a machine and cause the machine to perform any one or more of the methods of the present disclosure. The term "machine-readable storage medium" should therefore be considered to include, but is not limited to, solid-state memories, optical media, and magnetic media.

[0068] Some portions of the previous detailed description have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the art of data processing to most effectively convey the substance of their work to others skilled in the art. An algorithm is generally considered in this article to be a self-consistent sequence of operations that leads to a desired result. These operations are those that require physical manipulation of physical quantities. Typically, but not necessarily, these quantities take the form of electrical or magnetic signals that can be stored, combined, compared, and otherwise manipulated. Mainly for common reasons, it has proven convenient to sometimes refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc.

[0069] It should be remembered, however, that all of these and similar terms are associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless otherwise noted, as will be apparent from the above discussion, it should be understood that throughout this specification, discussions utilizing terms such as "identifying" or "determining" or "executing" or "implementing" or "collecting" or "creating" or "sending" refer to the actions and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other such information storage devices.

[0070] The present disclosure also relates to an apparatus for performing the operations herein. The apparatus may be specially constructed for the intended purpose, or may include a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but not limited to, any type of disk including a floppy disk, an optical disk, a CD-ROM, and a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), an EPROM, an EEPROM, a magnetic card or an optical card, or any type of medium suitable for storing electronic instructions, each medium coupled to a computer system bus.

[0071] The algorithms and displays presented herein are not inherently related to any particular computer or other device. According to the teachings herein, various general purpose systems can be used together with the program, or it may prove convenient to build a more specialized device to perform the method. The structure of various these systems will be set forth in the following description. In addition, the present disclosure is not described with reference to any particular programming language. It should be understood that various programming languages ​​may be used to implement the disclosed teachings described herein.

[0072] The present disclosure may be provided as a computer program product or software, which may include a machine-readable medium having instructions stored thereon, which may be used to program a computer system (or other electronic device) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., computer) readable storage medium, such as a read-only memory ("ROM"), a random access memory ("RAM"), a magnetic disk storage medium, an optical storage medium, a flash memory device, etc.

[0073] In the foregoing disclosure, implementations of the present disclosure have been described with reference to specific example implementations of the present disclosure. It will be apparent that various modifications may be made thereto without departing from the broader spirit and scope of the implementations of the present disclosure as set forth in the claims. Accordingly, the disclosure and the accompanying drawings are to be regarded as illustrative rather than restrictive.

Claims

1. A method for managing a container, include: Receiving, at a first time, a first container corresponding to the executable code; In response to the receiving of the first container, executing, by a processing device of a secure computing environment, a container manager resident in a memory of the secure computing environment to authenticate the first container; providing, by the processing device, access to one or more resources of the secure computing environment by transferring control of the processing device from the container manager to the first container based on permissions of the first container for resources of the secure computing environment; receiving data from the first container, wherein the data is for a second container; storing the data and the identification of the second container in another memory of the secure computing environment; receiving, at a second time after the first time, the second container corresponding to the additional executable code; providing, by the processing device, access to the one or more resources based on permissions of the second container for the resources of the secure computing environment by transferring control of the processing device from the container manager to the second container; as well as In response to the identification of the second container matching the identification of the second container in the other memory of the secure computing environment, providing data from the other memory of the secure computing environment to the second container.

2. The method according to claim 1, further comprising: include: upon verification of the first container by the container manager, updating one or more registers of a resource implementation core of the secure computing environment according to the permissions of the first container, wherein the resource implementation core is used to implement access to the one or more resources of the secure computing environment, wherein providing the access to the first container comprises using the one or more registers according to the permissions of the first container; as well as After the container manager authenticates the second container, one or more registers of the resource implementation core of the secure computing environment are updated according to the permissions of the second container, wherein providing the access to the second container includes using the one or more registers according to the permissions of the second container.

3. The method of claim 1 , wherein the container manager is to verify the permissions of the first container and to verify the authenticity of the first container, wherein the container manager is to verify the permissions of the second container and to verify the authenticity of the second container, wherein the container manager is verified by a boot loader of the secure computing environment.

4. The method according to claim 1, further comprising: include: receiving a third container at a third time after the first time; as well as Access to the one or more resources is provided by the processing device based on permissions of the third container for the resources of the secure computing environment by transferring control of the processing device from the container manager to the third container.

5. The method according to claim 4, further comprising: include: In response to the identification of the third container not matching the identification of the second container in the other memory of the secure computing environment, access to the data from the other memory of the secure computing environment to the third container is prohibited.

6. The method according to claim 1, further comprising: include: receiving a version number associated with the container manager; as well as The first container is executed based on a comparison of the version number associated with the container manager and another version number associated with the container manager stored in the first container.

7. The method according to claim 1, further comprising: include: receiving, from the first container, a request to receive data from a component external to the secure computing environment; as well as An indication of the request to receive data is stored in another memory of the secure computing environment, wherein the another memory is accessible by the component external to the secure computing environment.

8. A system for managing containers, include: Memory; as well as a processing device operatively coupled to the memory to: Receiving, at a first time, a first container corresponding to the executable code; In response to receiving the first container, executing a container manager resident in the memory of the secure computing environment to authenticate the first container; providing access to one or more resources of the secure computing environment by transferring control of the processing device from the container manager to the first container based on permissions of the first container for resources of the secure computing environment; receiving data from the first container, wherein the data is for a second container; storing the data and the identification of the second container in another memory of the secure computing environment; receiving, at a second time after the first time, the second container corresponding to the additional executable code; providing access to the one or more resources by transferring control of the processing device from the container manager to the second container based on permissions of the second container for the resources of the secure computing environment; as well as In response to the identification of the second container matching the identification of the second container in the other memory of the secure computing environment, providing the data from the other memory of the secure computing environment to the second container.

9. The system of claim 8, wherein the processing device is further configured to: updating, after verification of the first container by the container manager, one or more registers of a resource implementation core of the secure computing environment according to the permissions of the first container, wherein the resource implementation core is used to implement access to the one or more resources of the secure computing environment, wherein the access to the first container is provided using the one or more registers according to the permissions of the first container; and After validating the second container by the container manager, one or more registers of the resource implementation core of the secure computing environment are updated according to the permissions of the second container, wherein the access to the second container is provided using the one or more registers according to the permissions of the second container.

10. The system of claim 8, wherein the container manager is to verify the permissions of the first container and to verify the authenticity of the first container, wherein the container manager is to verify the permissions of the second container and to verify the authenticity of the second container, and wherein the container manager is authenticated by a boot loader of the secure computing environment.

11. The system of claim 8, wherein the processing device is further configured to: receiving a third container at a third time after the first time; and Based on permissions of a third container for the resources of the secure computing environment, access to the one or more resources is provided by transferring control of the processing device from the container manager to the third container.

12. The system of claim 11, wherein the processing device is further configured to: In response to the identification of the third container not matching the identification of the second container in the other memory of the secure computing environment, access to the data from the other memory of the secure computing environment to the third container is prohibited.

13. The system of claim 8, wherein the processing device is further configured to: receiving a version number associated with the container manager; and The first container is executed based on a comparison of the version number associated with the container manager and another version number associated with the container manager stored in the first container.

14. The system of claim 8, wherein the processing device is further configured to: receiving, from the first container, a request to receive data from a component external to the secure computing environment; and An indication of the request to receive data is stored in another memory of the secure computing environment, wherein the another memory is accessible by the component external to the secure computing environment.

15. A non-transitory computer-readable medium comprising instructions that, when executed by a processing device in a secure computing environment, cause the processing device to perform operations, the operations include: Receiving, at a first time, a first container corresponding to the executable code; In response to the receiving of the first container, executing a container manager resident in a memory of the secure computing environment to authenticate the first container; providing access to one or more resources of the secure computing environment by transferring control of the processing device from the container manager to the first container based on permissions of the first container for resources of the secure computing environment; receiving data from the first container, wherein the data is for a second container; storing the data and the identification of the second container in another memory of the secure computing environment; receiving, at a second time after the first time, a second container corresponding to the additional executable code; providing access to the one or more resources by transferring control of the processing device from the container manager to the second container based on permissions of the second container for the resources of the secure computing environment; as well as In response to the identification of the second container matching the identification of the second container in the other memory of the secure computing environment, providing the data from the other memory of the secure computing environment to the second container.

16. The non-transitory computer readable medium of claim 15, wherein the operation further comprises: include: updating, after the container manager authenticates the first container, one or more registers of a resource implementation core of the secure computing environment according to the permissions of the first container, wherein the resource implementation core is used to implement access to the one or more resources of the secure computing environment, wherein providing the access to the first container includes using the one or more registers according to the permissions of the first container; as well as After the container manager authenticates the second container, one or more registers of the resource implementation core of the secure computing environment are updated according to the permissions of the second container, wherein providing the access to the second container includes using the one or more registers according to the permissions of the second container.

17. The non-transitory computer-readable medium of claim 15, wherein the container manager is to verify the permissions of the first container and to verify the authenticity of the first container, wherein the container manager is to verify the permissions of the second container and to verify the authenticity of the second container, and wherein the container manager is authenticated by a boot loader of the secure computing environment.

18. The non-transitory computer readable medium of claim 15, wherein the operation further comprises: include: receiving a third container at a third time after the first time; as well as Based on permissions of the third container for the resources of the secure computing environment, access to the one or more resources is provided by transferring control of the processing device from the container manager to the third container.

19. The non-transitory computer readable medium of claim 18, wherein the operation further comprises: include: In response to the identification of the third container not matching the identification of the second container in the other memory of the secure computing environment, access to the data from the other memory of the secure computing environment to the third container is prohibited.

20. The non-transitory computer readable medium of claim 15, wherein the operation further comprises: include: receiving a version number associated with the container manager; as well as The first container is executed based on a comparison of the version number associated with the container manager and another version number associated with the container manager stored in the first container.

Images