CN115640571A

CN115640571A - Method for a library operating system LibOS of a trusted execution environment TEE

Info

Publication number: CN115640571A
Application number: CN202211221087.6A
Authority: CN
Inventors: 吴行行; 邱鸿霖; 余逸荣
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-10-08
Filing date: 2022-10-08
Publication date: 2023-01-24

Abstract

The present disclosure relates to a method for a library operating system LibOS of a trusted execution environment TEE, comprising: providing a building tool, wherein the building tool comprises a TEE environment module, a software operation module, a software logic module and a software configuration module; receiving, by the software logic module, computational logic code developed by a user to be run in a TEE; receiving, by the software configuration module, configuration items for the computational logic code; starting corresponding components in the TEE environment module according to the TEE software development environment and the LibOS specified by the configuration items through the construction tool, starting corresponding components in the software operation module according to the software operation environment specified by the configuration items, and compiling the calculation logic codes; and packaging the compiled computational logic code, the corresponding component in the TEE environment module, the corresponding component in the software running module and the configuration item to generate an executable file corresponding to the computational logic code.

Description

Method for a library operating system LibOS of a trusted execution environment TEE

Technical Field

The embodiment of the disclosure belongs to the technical field of computers, and particularly relates to a library operating system LibOS method for a trusted execution environment TEE.

Background

Cloud computing, big data and artificial intelligence all need to process massive data. How to ensure the security of data and the privacy of users is a considerable issue. Privacy calculations, or Confidential Computing, may be used to solve this problem. The privacy computation utilizes a Trusted Execution Environment (TEE) technology to keep data always in an encrypted and strongly isolated state, thereby ensuring the security and privacy of user data. The privacy computing can solve the trust problem in many application scenarios, such as data fusion and joint analysis among multiple untrusted organizations, confidentiality protection of intelligent contracts on a block chain, defense of public cloud platforms against external or internal attacks, security protection of highly sensitive information (such as cryptographic materials, medical archives, etc.), and the like.

Disclosure of Invention

It is an object of the present disclosure to provide a method, a non-transitory computer-readable storage medium and a computing device for a library operating system LibOS of a trusted execution environment TEE.

According to a first aspect of the present disclosure, there is provided a method for a library operating system LibOS of a trusted execution environment TEE, comprising: providing a construction tool, wherein the construction tool comprises a TEE environment module, a software operation module, a software logic module and a software configuration module; receiving, by the software logic module, computational logic code developed by a user to be run in a TEE; receiving, by the software configuration module, a configuration item for the computational logic code, the configuration item specifying: a TEE software development environment for which the computational logic code is expected; the LibOS expected by the computational logic code; and a software execution environment expected by the computational logic code; starting corresponding components in the TEE environment module according to the TEE software development environment and the LibOS specified by the configuration items through the construction tool, starting corresponding components in the software operation module according to the software operation environment specified by the configuration items, and compiling the calculation logic codes; and packaging the compiled computational logic code, the corresponding component in the TEE environment module, the corresponding component in the software running module and the configuration item to generate an executable file corresponding to the computational logic code.

According to a second aspect of the present disclosure, there is provided a method for a library operating system LibOS of a trusted execution environment TEE, comprising: providing a build tool comprising a TEE environment module, a software execution module, a software logic module, and a software configuration module, wherein the TEE environment module comprises one or more TEE software development environment components corresponding to one or more versions of a TEE software development environment and one or more LibOS components corresponding to one or more versions of a library operating system LibOS established within the TEE, the software execution module comprising one or more software execution environment components corresponding to one or more software execution environments, one or more data input components corresponding to one or more data input policies, one or more data output components corresponding to one or more data output policies, and one or more software execution resource components corresponding to one or more software execution resource configurations; receiving, by the software logic module, computational logic code developed by a user to be run in the TEE, the computational logic code computing encrypted input data that is outside the TEE; receiving, by the software configuration module, a configuration item for the computational logic code, the configuration item specifying: a version of the TEE software development environment expected by the computational logic code; the version of LibOS expected by the computation logic code; a software runtime environment expected by the computational logic code; the desired data entry policy of the computational logic code; calculating a desired data output policy of the logic code; and software operating resources expected by the computational logic code; starting corresponding components in the TEE environment module according to the version of the TEE software development environment and the version of the LibOS specified by the configuration items through the construction tool, starting corresponding components in the software operation module according to the software operation environment specified by the configuration items, and compiling the calculation logic codes; and packaging the compiled computational logic code, the corresponding component in the TEE environment module, the corresponding component in the software running module and the configuration item to generate an executable file corresponding to the computational logic code.

According to a third aspect of the present disclosure, there is provided a method for a library operating system LibOS of a trusted execution environment TEE, comprising: receiving, by a build tool, computation logic code developed by a user to be run in a TEE, the computation logic code computing encrypted input data outside the TEE and/or the computation logic code invoking a dependency library outside the TEE; receiving, by the build tool, a configuration item for the computational logic code, the configuration item specifying a data entry policy and/or a runtime environment of a dependency library for the computational logic code; and starting a component corresponding to the data input strategy specified by the configuration item and/or a component corresponding to the running environment of the dependency base specified by the configuration item in the building tool through the building tool, and compiling and packaging the computational logic code to generate an executable file corresponding to the computational logic code.

According to a fourth aspect of the present disclosure, there is provided a non-transitory computer-readable storage medium having stored thereon a series of computer-executable instructions that, when executed by one or more computing devices, cause the one or more computing devices to: providing a build tool comprising a trusted execution environment TEE environment module, a software execution module, a software logic module, and a software configuration module, wherein the TEE environment module comprises one or more TEE software development environment components corresponding to one or more versions of a TEE software development environment, and one or more LibOS components corresponding to one or more versions of a library operating system LibOS established within the TEE, the software execution module comprising one or more software execution environment components corresponding to one or more software execution environments, one or more data input components corresponding to one or more data input policies, one or more data output components corresponding to one or more data output policies, and one or more software execution resource components corresponding to one or more software execution resource configurations; receiving, by the software logic module, computational logic code developed by a user to be run in the TEE, the computational logic code computing encrypted input data that is outside the TEE; receiving, by the software configuration module, a configuration item for the computational logic code, the configuration item specifying: a version of the TEE software development environment expected by the computational logic code; a version of LibOS expected by the computational logic code; a software runtime environment expected by the computational logic code; the desired data entry policy of the computational logic code; the expected data output strategy of the calculation logic code; and software operating resources expected by the computational logic code; starting corresponding components in the TEE environment module according to the version of the TEE software development environment and the version of the LibOS specified by the configuration items through the construction tool, starting corresponding components in the software operation module according to the software operation environment specified by the configuration items, and compiling the calculation logic codes; and packaging the compiled computational logic code, the corresponding component in the TEE environment module, the corresponding component in the software running module and the configuration item to generate an executable file corresponding to the computational logic code.

According to a fifth aspect of the present disclosure, there is provided a computing device comprising one or more processors and one or more memories configured to store a series of computer-executable instructions, wherein the series of computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: providing a build tool comprising a Trusted Execution Environment (TEE) environment module, a software execution module, a software logic module, and a software configuration module, wherein the TEE environment module comprises one or more TEE software development environment components corresponding to one or more versions of a TEE software development environment and one or more LibOS components corresponding to one or more versions of a library operating system (LibOS) established within the TEE, and the software execution module comprises one or more software execution environment components corresponding to one or more software execution environments, one or more data input components corresponding to one or more data input policies, one or more data output components corresponding to one or more data output policies, and one or more software execution resource components corresponding to one or more software execution resource configurations; receiving, by the software logic module, computational logic code developed by a user to run in a TEE, the computational logic code computing encrypted input data that is outside the TEE; receiving, by the software configuration module, a configuration item for the computational logic code, the configuration item specifying: a version of the TEE software development environment expected by the computational logic code; a version of LibOS expected by the computational logic code; a software execution environment expected by the computational logic code; the computing logic code expects a data input policy; calculating a desired data output policy of the logic code; and software operating resources expected by the computational logic code; starting corresponding components in the TEE environment module according to the version of the TEE software development environment and the version of the LibOS specified by the configuration items through the construction tool, starting corresponding components in the software operation module according to the software operation environment specified by the configuration items, and compiling the calculation logic codes; and packaging the compiled computational logic code, the corresponding component in the TEE environment module, the corresponding component in the software running module and the configuration item to generate an executable file corresponding to the computational logic code.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive labor.

FIG. 1 is a schematic illustration of an operational flow of an Intel SGX application according to an embodiment of the present disclosure;

fig. 2 is a system architecture schematic of Occlum according to an embodiment of the present disclosure;

FIG. 3 is a flow chart of a method for LibOS of a TEE according to an embodiment of the present disclosure;

FIG. 4 is a schematic diagram of a method of LibOS for TEE according to an embodiment of the present disclosure;

FIG. 5 is a schematic diagram of a method of LibOS for TEE according to an embodiment of the present disclosure;

fig. 6 is a schematic diagram of an on-chain node in a blockchain network including a TEE;

fig. 7 is a schematic diagram of a down-link node of a blockchain network including a TEE;

FIG. 8 is a schematic structural diagram of at least a portion of a computing device according to an embodiment of the present disclosure;

FIG. 9 is an exemplary block diagram applicable to a general purpose hardware system in accordance with embodiments of the present disclosure.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present disclosure, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the drawings in the embodiments of the present disclosure, and it is obvious that the described embodiments are only a part of the embodiments of the present disclosure, and not all the embodiments. It should be understood, however, that one or more embodiments of the present disclosure may be presented in a number of different ways and are not limited to the embodiments described below. It is also to be understood that one or more embodiments of the present disclosure can be combined in various ways to provide further additional embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments disclosed herein without making any creative effort, shall fall within the protection scope of the present disclosure.

It is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. All terms (including technical and scientific terms) used herein have the meaning commonly understood by one of ordinary skill in the art unless otherwise defined. Well-known functions or constructions may not be described in detail for brevity and/or clarity.

In this document, the term "coupled" is intended to encompass a physical, electrical, and/or communicative coupling of one feature to another, and may or may not have intervening features between the one feature and the other feature. When the connection is a communication connection, even though reference is made to a and B as being "directly connected," it is intended to emphasize that there is no feature or features emphasized by one or more embodiments of the present disclosure between the connection of a and B, but does not represent a limitation that the connection between a and B is not through any element, and those skilled in the art will understand that the connection between a and B may be through a cable, a router, a gateway, a channel, a link, a network, and the like. It should be noted that in the drawings of one or more embodiments of the present disclosure, a direct connection or an indirect connection between a and B is represented by a straight line or other graphic element connected between a and B.

Herein, the term "a or B" includes "a and B" and "a or B" rather than exclusively including only "a" or only "B" unless otherwise specifically stated.

In this document, the term "exemplary" means "serving as an example, instance, or illustration," and not as a "model" that is to be reproduced exactly. Any implementation exemplarily described herein is not necessarily to be construed as preferred or advantageous over other implementations. Furthermore, there is no intention to be bound by any expressed or implied theory presented in the preceding technical field, background, brief summary or the detailed description.

In this document, the term "substantially" is intended to encompass any minor variations due to design or manufacturing imperfections, tolerances of the devices or components, environmental influences and/or other factors. The term "substantially" also allows for differences from a perfect or ideal situation due to parasitics, noise, and other practical considerations that may exist in a practical implementation.

In addition, "first," "second," and like terms may also be used herein for reference purposes only, and thus are not intended to be limiting. For example, the terms "first," "second," and other such numerical terms referring to structures or elements do not imply a sequence or order unless clearly indicated by the context.

It will be further understood that the terms "comprises/comprising," "includes" and/or "including," when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should be noted that: in other embodiments, the steps of the respective methods are not necessarily performed in the order shown and described in the present disclosure. In some other embodiments, the method may include more or fewer steps than are described in the present disclosure. Moreover, a single step described in this disclosure may be broken down into multiple steps for description in other embodiments; while multiple steps described in this disclosure may be combined into a single step for description in other embodiments.

The TEE is a security extension based on CPU hardware and is completely isolated from the outside. TEE was originally a concept proposed by Global Platform to address the secure isolation of resources on mobile devices, providing a trusted, secure execution environment for applications parallel to the operating system. An application running in a TEE may be referred to as a Trusted APP (Tapp). As technology has evolved, TEEs have become more generalized TEEs than the concepts originally presented. For example, server chip vendors Intel, AMD, and others have introduced hardware-assisted TEE in tandem and enriched TEE concepts and features. The mention of TEE now is more generally directed to such hardware assisted TEE techniques. Unlike the mobile terminal, the cloud access requires remote access, and the end user is not visible to the hardware platform, so the first step of using the TEE is to confirm the authenticity and credibility of the TEE. Therefore, the current TEE technology introduces a remote attestation mechanism which is endorsed by a hardware manufacturer (mainly a CPU manufacturer) and ensures that a user can verify the TEE state through a digital signature technology. Meanwhile, the security requirement which cannot be met by only the security resource isolation is also met, and further data privacy protection is also provided. Commercial TEE's including Intel SGX, AMD SEV also provide memory encryption techniques, which restrict trusted hardware within the CPU, with data on the bus and memory being ciphertexts to prevent malicious users from snooping. For example, TEE technology such as Intel's software protection extensions (SGX) isolates code execution, remote attestation, secure configuration, secure storage of data, and trusted paths for executing code. Applications running in the TEE are secured and are almost impossible to access by third parties.

However, TEE technology, on which privacy computing relies, also introduces additional functional limitations and compatibility issues, as described below with the example of Intel SGX. SGX provides an enclosure (also known as an enclave), an encrypted trusted execution area in memory, that is protected from data theft by the CPU. Taking a CPU supporting SGX as an example, a part of an EPC (enclosure Page Cache, enclave Page Cache, or Enclave Page Cache) may be allocated in a Memory by using a newly added processor instruction, and data therein is encrypted by an Encryption Engine MEE (Memory Encryption Engine) in the CPU. The encrypted content in the EPC is decrypted into plaintext only after entering the CPU. In practical application, the private data can be encrypted and then transmitted to the enclosure in a ciphertext form, and the corresponding secret key is transmitted to the enclosure through remote certification. Then, the operation is performed by using the data under the encryption protection of the CPU, and the result is returned in the form of a ciphertext, as shown in fig. 1.

Since SGX applications are based on this partitioned architecture, application developers typically need to use some kind of SGX SDK, such as Intel SGX SDK, open Enclave SDK, google asso, or Apache Rust SGX SDK. However, no matter which SDK is used, developers of private computing programs encounter the following development dilemma: 1) The target application must be halved: the developer needs to decide which components should be placed inside the Enclave, which are placed outside the Enclave, and how the two parties communicate. For complex applications, determining an efficient, rational, and secure partitioning scheme is itself a challenging task, not to mention the amount of engineering required to implement the partitioning. 2) Is defined in a certain programming language: regardless of which SDK is developed as described above, one developer will be limited to the languages supported by the SDK, which typically means C/C + + (e.g., when using Intel SGX SDK, open Enclave SDK, or Google Asylo), but not the more friendly programming languages Java, python, go, etc. 3) Only very limited functionality is available: in Enclave, there is no direct access to the (untrusted) OS outside of Enclave, subject to hardware limitations and security concerns. Due to the lack of OS support in Enclave, various SDKs can only provide a small subset of functionality in a common untrusted environment, which makes many existing software libraries or tools unable to run in Enclave.

To better support applications running in Intel SGX enclaves, many approaches related to Library Operating System (LibOS) were designed and deployed. The LibOS is a special operating system that provides some resource management functions originally belonging to the operating system kernel, such as file disk I/O, network communication, etc., to the application program in the form of a library according to the modular requirement. The method can reasonably manage and control the related computer resources instead of an operating system kernel, directly expose the related computer resources to the application program, and enable the application program to directly access the underlying (virtual) hardware, so that the application program can run efficiently. In particular, it is linked together with the application program at compile time, forming a binary file with only a single address space and working at the application level. Compared with the shared kernel technology such as Container/VM, the LibOS is lighter in weight, consumes less running resources and provides kernel customization capability. The LibOS has better isolation, and can provide an independent OS for each application, so that the applications can run on different platforms.

Based on the above-described characteristics of LibOS, applications can run directly in SGX Enclave with little modification. Developers can be freed from writing any additional enclave-aware code. Open source LibOS supporting Intel SGX currently includes Granine, ocplus, SCONE, fortanix, etc.

Ocplus is a memory-safe, multi-process library operating system LibOS suitable for Intel SGX. As a LibOS, when the application program is transplanted to the SGX, only a small amount of modification is needed to be carried out on the source code of the application program, even no modification is needed, so that the confidentiality and the integrity of the user workload can be protected, and the development threshold of the SGX application can be greatly reduced.

For example, applications may be ported into the SGX via Occlum in the manner described below. First, the application is compiled using the compiler suite GCC toolchain (Occlum-GCC) provided by Occlum, and then an instance directory of Occlum is created for this program (e.g., occlum new command can be used), and some necessary files (e.g., occlum. Json configuration file) and subdirectories (e.g., image /) are prepared in this directory. Next, in the trusted development environment (as the upper half of fig. 2), an Enclave file of Occlum and a trusted image (for example, occluum build command can be used) are packaged and made based on the compiled program, and the trusted image uses a Merkel Hash Tree to ensure that the image cannot be tampered by an attacker after being uploaded to the untrusted deployment environment. The content of the trusted image is root file system rootfs loaded when Ocplus starts, the organization structure is similar to that of a common Unix operating system, and the specific content is determined by a user.

When the packaged application needs to be run, the user can use the occluum run command to start a new Occlum Enclave in the untrusted deployment environment (as the lower half of fig. 2), and the Occlum TEE OS in the Enclave loads and executes the corresponding application from the trusted image. Ocplus provides Linux-compatible system calls to applications so that applications can run in Enclave with no (or little) modification. The memory state of the application program is protected by Enclave, and the file I/O of the application program is automatically encrypted and decrypted by Ocplus, so that the confidentiality and the integrity of data in the memory and the external memory can be simultaneously protected.

Ocplus enables users to freely select programming languages (such as Java, python, go, etc.) without understanding the binary programming model of SGX, without or with little modification to application code. Using Occlum, application developers can focus valuable effort on writing applications, rather than application migration for SGX. But for complex applications, even with Occlum, some code modification work is still required. In a machine learning scenario, for example, the developer of an application needs to: 1. and (2) downloading the encrypted data sets of other participants, starting a python environment and running a python script (for example, aiming at a python program), executing an algorithm in the python environment, and (3) obtaining an output file and encrypting and sending the output file again. Here the developer needs to handle file downloads and decryption, as well as encryption operations on the output file. Because the data volume of training data for machine learning is huge, developers need to redesign the loading mode of data, for example, streaming loading is adopted; meanwhile, operations such as file caching, python virtual machine starting and the like are processed. If the Java program is switched to the Java program, the developer also needs to repeatedly realize the file processing of the Java version.

According to the method for the library operating system LibOS of the trusted execution environment TEE, provided by the embodiment of the disclosure, a modular construction tool is provided, and a required construction tool component is specified through user configuration, so that a developer of the trusted application Tapp can pay attention to the whole compiling and constructing process of the program without paying attention to the logic of the application program. A method 300 of LibOS for TEE according to an embodiment of the disclosure is described below in conjunction with fig. 3 and 4. In some embodiments, the method 300 may include operations S310 to S340.

In operation S310, the method 300 may provide a build tool. As shown in FIG. 4, the build tool may include a TEE environment module, a software execution module, a software logic module, and a software configuration module.

The TEE environment module may provide services associated with a TEE runtime support environment that is required by Tapp to run within the TEE. In some embodiments, the TEE environment module may provide one or more TEE environment components, such as one or more TEE software development environment (SDK) components corresponding to one or more versions of a SDK, one or more LibOS components corresponding to one or more versions of LibOS established within the TEE, and so forth. Such one or more components may be provided in the form of a packaged binary file.

The software runtime module may provide services associated with the runtime environment of the Tapp (e.g., java, python, c/c + +, etc.). In some embodiments, the software execution module may provide one or more software execution components, e.g., one or more software execution environment components corresponding to one or more software execution environments, and/or the like. Such one or more components may be provided in the form of a packaged binary file.

The software logic module may provide services associated with the software logic of the Tapp by providing a compiled application. The compiled application needs to be generated from the source code of the Tapp. The specific process is described later.

The software configuration module may provide services associated with the software configuration to which the Tapp is assigned. For example, configuration items specified by a developer of the Tapp are received, and corresponding configuration items are provided to the building tool during the building process of the Tapp, so that the building tool can complete corresponding functions according to the specified configuration items.

In operation S320, the method 300 may receive, through a software logic module, computational logic code developed by a user to be run in a TEE, such as source code of the Tapp.

In operation S330, the method 300 may receive a configuration item for the computation logic code through the software configuration module. For example, a configuration item may specify: a TEE software development environment (e.g., version of TEE SDK) to compute logic code expectations, a LibOS (e.g., occlum and its version) to compute logic code expectations, and a software runtime environment (e.g., java, python, c/c + +, etc.) to compute logic code expectations.

In operation S340, the method 300 may start, by the building tool, a corresponding component in the TEE environment module according to the TEE SDK and the LibOS specified by the configuration item, for example, the version of the TEE SDK expected by the computation logic code specified by the configuration item and the version of the LibOS expected by the computation logic code, and start a corresponding component in the software running module according to the software running environment specified by the configuration item, so as to compile the computation logic code; and packaging the compiled computational logic code, the corresponding component in the TEE environment module, the corresponding component in the software running module and the configuration item to generate an executable file corresponding to the computational logic code.

The software running environment specified according to the configuration item is related to the writing language of the computing logic code, such as java, python, c/c + + and the like, so that components corresponding to the specified running environment in the software running module are started to compile the computing logic code. It should be noted that even for an interpreted language, such as java, python, etc., the code needs to be converted into bytecode by a compiler (this process is referred to as "compiling" herein), and then interpreted and executed by an interpreter at runtime. For example, when the Python program is running, the result (i.e., the bytecode) compiled by the Python compiler is saved in the PyCodeObject in memory, and when the Python program is finished running, the Python interpreter writes the PyCodeObject back into the pyc file. When the python program is not run for the first time, a valid pyc file is found in the directory and if found, it is loaded directly. The building tool can start a Python environment component in the software running module according to the Python environment specified by the configuration item, and compile Python code, for example, generate a pyc file.

After the computational logic code is compiled, the program is packaged by a build tool to generate an executable file. The packaged file may include compiled computational logic code, a TEE SDK component, a LibOS component, a software runtime environment component, and configuration items (including configuration items of configuration related to Tapp operations). The software runtime environment component included in the packed executable may start a java, python, or c/c + + execution environment (e.g., load python or java virtual machine) at Tapp runtime, and the TEE SDK component and LibOS component provide the TEE runtime support environment required by Tapp to run within the TEE, enabling the executable to directly start execution in an environment in which the LibOS (e.g., occlum) is installed.

In some cases, tapp may involve complex computations in machine learning. The deep learning algorithm is composed of individual calculation units, which are called Operators (OP). In the network model, the computation logic in the operator correspondence Layer, for example, the Convolution Layer (constraint Layer) may be one operator; the weight summation process in the Fully-connected Layer (full-connected Layer) may also be an operator. The operators executed in the TEE are called Trusted Operators (TOP). The development of TOP may involve multiple application languages and complex password designs. For example, TOP oriented to machine learning and data analysis may involve the migration of existing python libraries, java libraries, C + + and other dependent libraries; while the input data has different formats and the encrypted input data needs to be given to the compute node to ensure confidentiality.

The method has the advantages that Ocplus is used for directly developing TOP, and the method has the disadvantages that some necessary transformation is required, such as the starting process of a python virtual machine and a java virtual machine, a developer in the process needs to calculate the whole resources required by the virtual machine according to the size of a request, the size of a processing file and the like, then limitation is carried out, and meanwhile, the necessary environment variables of a processing program need to be transmitted during starting, and the process is long, complex and easy to make mistakes; it is also necessary to know the specific design of TOP protocol, including not only the cryptographic scheme and encoding method, but also the processing of large files. It is not practical to decrypt large files directly inside the TEE because TEE memory is limited. And the integrity needs to be ensured by adopting a fragmentation mode. In addition, the performance is deeply influenced by the size of the fragments and the transmission size, the optimization is difficult to transfer to developers, and the development threshold is high by selecting a proper password solution. If the developer needs to deal with these problems, the development and application process of TOP is hindered.

In some embodiments, computational logic code, such as that of TOP, may call one or more dependent libraries, including standard libraries and third party libraries, among others. Such a dependent library is typically located outside the TEE and needs to be included in the generated executable file. In these embodiments, the method 300 may further include compiling the computational logic code by linking, for example, in operation S340, the corresponding dependency libraries (including downloading and importing dependency libraries) by the build tool according to the software execution environment specified by the configuration item.

In some embodiments, computation logic code, such as the code of TOP, computes encrypted input data that is outside the TEE. In these embodiments, in addition to specifying the version of TEE SDK and LibOS, and the software runtime environment, the configuration item may also specify a data input policy, a data output policy, and software runtime resources expected by the computing logic code, and the method 300 may further include launching, by the software runtime module, a software runtime environment for the computing logic code according to the software runtime environment specified by the configuration item, such as loading a python or java virtual machine; configuring a data interaction mode between the TEE and the outside according to the data input strategy and the data output strategy specified by the configuration item, for example, data interaction may be performed through an encrypted file (for example, external data of the TEE may be downloaded to a local disk and then read, etc.), or data may be directly received through a network interface (for example, data interaction may be performed through socket connection, etc.); and limiting the resources of the calculation logic code during operation according to the software operation resources specified by the configuration items so as to generate a calculation instance which corresponds to the calculation logic code and runs in the LibOS.

In some embodiments, the data input policies desired by the computational logic code specified in the configuration entry may include loading/slicing into/streaming into the TEE directly, and/or caching in the TEE, the data output policies may include whether all output files are outgoing, and/or caching all output files, and the software execution resources may include one or more of parallelism, maximum file size, heap space size, stack space size, memory mapped space size, and process space size.

One specific example of a configuration that may be provided by a developer of computing logic code (or Tapp) is shown below, taking TOP as an example. The lines of code in this example may be recorded in, for example, a file top. Config to provide to the build tool.

{

"top_type":"serverless",

"top_env":"py37",

"entrypoint":"src/xgb.py",

"intfile_policy":"dump_no_cache",

"outtfile_policy":"pickup",

"concurrenty":"1",

"max_tfile_size":"1GB",

"heap_size":"1GB",

"mmap_size":"1GB",

"stack_size":"1GB"

}

The build tool may receive the configured lines of code through a software configuration module and then convert them into respective configuration items for the Tapp. The TOP _ type specifies whether the TOP is a service operator, for example, the service operator is automatically started and resides in a memory when a system is started, and is suitable for real-time calculation requests; and the non-service operator can be elastically pulled up when the scheduling engine needs, so that the off-line calculation request is suitable. Designated in this example is the unserviceable operator. top _ env specifies the software runtime environment, which may for example specify the environment python3.7 or java 11. Designated in this example as python3.7.entrypoint specifies the computation logic code (e.g., by its directory and file name). The intfile _ policy and outfile _ policy specify the data input policy and the data output policy, respectively, expected by the computation logic code, for example, whether the input/output file is cached or not. consturentspecifies the parallelism of the TOP, max _ tfile _ size, heap _ size, mmap _ size, and stack _ size specify the software execution resources expected by the compute logic code, e.g., specifying the limits of the files, heap, mmap, and stack supportable by the TOP, respectively. Further, with respect to the TEE software development environment and LibOS for which logic code is expected, the build tool may provide, for example, a configuration interface for selection by a TOP developer and receive these selections through a software configuration module to receive these configuration items specified by the TOP developer.

As mentioned above, TOP usually requires computation of a large amount of input data, and in the case of a TEE performing data interaction with the outside through an encrypted file, if a file containing a large amount of data is read into the TEE and then decrypted inside the TEE, it is almost impossible to implement due to the limited memory of the TEE. Therefore, the data interaction can be carried out in a slicing transmission mode. At this point, the integrity of the transmitted data needs to be guaranteed. In some embodiments, each slice (slice) of the input data file may be subject to a separate checksum decryption. When reading the data file into the TEE, downloading a meta file of the input data file, wherein the meta file comprises the check value of each slice of the input data file; and then, downloading each slice in sequence, and performing processing logics such as verification and the like. In this case, the build tool may set parameters such as the file slice line width size, slice size, and meta file size of the input data file according to the memory capability, network conditions, and processing speed of the TEE.

In some cases, process restrictions may be placed on the developed applications that run in LibOS. At present, libOS can only receive a resource limit, which all processes of an application need to follow. For example, if two processes are running in an application, one is a more complex machine learning logic process and one is a simpler input output process. Wherein, the machine learning logic process may need 10G of stack resources, but the input and output process may only need 1G of stack resources. However, with the current LibOS implementation, only 10G stack resources can be configured for each process. For example, occlum specifies the use limit of a program on resources such as a stack by configuring Occlum. But this limitation is for all processes and cannot be configured individually for a process.

In some embodiments, the software operating resources specified by the configuration item received by the construction tool through the software configuration module include resources required to operate one or more processes involved in computing the logic code, i.e., the required operating resources are individually specified in the configuration item for each process of the Tapp. For example, the developer of the Tapp may declare in the configuration file top. Config resource limitations of the heap, mmap, stack, threads, and files required by the various processes of the Tapp. The method 300 may further include: and calculating the total resources required by the computing instance of the Tapp according to the resources required by the one or more processes and the resources required by the TEE environment module and the software running module through the construction tool, and limiting the resources of the Tapp when the Tapp runs according to the total resources required by the computing instance. And in response to starting a new process, performing process resource limitation on the new process according to the resources required by one or more processes specified by the configuration item during Tapp operation. For example, when Tapp is TOP and LibOS is Occlum, the construction tool extracts configuration items of software running resources of each process in TOP. During TOP execution, a process is initiated by a spawn system call. At this time, the resource of the process is restricted according to the resource configuration item of the process in top. spawn and rlimit are standard interfaces of Linux, wherein a process resource limit (resource limit) refers to a limit of resources that can be obtained by a process in the execution process of the process, such as a maximum value of a core file of the process, a maximum value of a virtual memory, and the like. Config allows setting respective resource limits for respective processes in top, and calculates the total resource limit of Tapp by a construction tool, so that resource management of development of Tapp becomes flexible and simple.

For Tapp, which would normally involve confidential calculations, two levels of auditing are typically required to ensure its trustworthiness: one is auditing a source code to check whether the source code has a logical vulnerability, such as whether the source code has a risk of revealing privacy and the like (for example, the source code can be sent to an auditor on line for manual auditing); its two are checks (or "verifications") of the Tapp's binary file (e.g., the executable file generated in the previous embodiment), such as a check metric value (which may be, for example, a hash value of the binary file) to prevent its binary file from being tampered with (e.g., the TEE needs to check the Tapp before executing the Tapp). For example, the value of the source code of the audited Tapp is compared with the hash value of the executable file corresponding to the Tapp to be run in the TEE, if the two values are equal, the executable file to be run in the TEE is the executable file of the audited Tapp, and the executable file is not tampered, and the executable file can be executed in the TEE after verification.

The computing logic of a Tapp such as TOP may need to be modified more often, and each time the change of the logical code of the Tapp is performed, the binary file of the generated Tapp will be different, the measurement values will be different, and the verification using the previous measurement values will certainly fail. But at this time, it cannot be known whether the verification caused by the tampering of the binary file cannot pass or the verification caused by the modification of the code cannot pass. Also, since Tapp involves not only the logic of the application itself, but also TEE environments, libOS, software execution environments, and the like, tapp files are generally large. It is not practical to fully examine the Tapp file to locate whether the file was tampered with or code modified.

In some embodiments, each of the one or more TEE software development environment components and the one or more LibOS components in the TEE environment module of the build tool is: audited corresponding first source code, audited generic construction tool (GCC) constructed, generated first executable file. Each of the one or more software runtime components in the software runtime module is: the audited corresponding second source code, the generated second executable file, and a corresponding build tool (occlium-gcc) provided by a corresponding LibOS component of the audited one or more LibOS components. For decoupling between the individual modules, the first source code of the components in the TEE environment module does not comprise code related to the functionality of the software execution module, nor does it comprise code related to the functionality of the computational logic code; the second source code of the component in the software execution module does not include code related to the functionality of the TEE environment module, nor does it include code related to the functionality of the computational logic code. Also, the computational logic code does not include code related to the functionality of the TEE environment module, nor does it include code related to the functionality of the software execution module. Therefore, the code in the TEE environment module, the software execution module, the software logic module and the software configuration module of the construction tool are independently audited independently of other modules, as there is no dependency relationship between each other. The codes in the TEE environment module and the software running module are relatively fixed, and frequent auditing is not required. For example, after one audit, as long as the TEE SDK or LibOS code is not updated, a further audit is not required. If the user updates the computational logic code, only an audit of the code is required.

Fig. 5 is a schematic diagram of a method of LibOS for TEE according to an embodiment of the present disclosure. In the particular example shown, the trusted execution environment TEE is Intel SGX, the library operating system LibOS is occium, and the trusted application Tapp is the trusted operator TOP. The TEE environment module provides TEE environment components including one or more TEE SDK components (shown in the figure as SGX SDKs) corresponding to one or more versions of Intel SGX SDKs, and one or more Occlum components corresponding to one or more versions of LibOS Occlum built within the TEE.

The software running module provides a software running component, and the software running component is derived from a software running environment MyTF TOP. MyTF TOP is a verifiable computing engine for TOP, referred to herein simply as "MyTF TOP". MyTF TOP allows TOP to be executed in the TEE and can prove to anyone that TOP is indeed executed in the TEE as intended by the user. MyTF TOP assigns each TOP running therein a set of keys for encryption and authentication of the trusted interactive content of the application itself. MyTF is a verifiable computing engine that utilizes TEE and WASM virtual machines, among other technologies. The Tapp runs in the WASM virtual machine through MyTF, and the calculation task of the Tapp can be executed by uploading WASM byte codes to MyTF and calling the WASM codes to obtain a calculation result. And the MyTF TOP in the software running module does not require the user to upload the WASM bytecode of the TOP to the compute engine by oneself. The MyTF TOP not only includes the function of a verifiable computing engine, but also integrates the functions of starting of different software operating environments, processing of input and output files, configuration of resources and the like.

The software logic module provides a compiled TOP application that is derived from the logical code and dependent libraries of TOP operators developed by the user (if needed).

The software configuration module provides the configuration item of the TOP specified by the user. Configuration items include configuration items required during the construction of the TOP as described above, e.g., the version of SGX SDK required for the TOP, the version of Occlum required, and the required software runtime environment such as java, python, c/c + +, etc. and versions thereof; in addition, the configuration items also include configuration items required in the running process of the TOP, such as an input file processing strategy, an output file processing strategy, a resource configuration strategy and the like required by the TOP.

In the specific example shown in FIG. 5, the dashed boxes represent the various modules of the build tool, the solid boxes represent the source code, the solid lines with arrows represent the build tool, and the circular boxes represent the build results. In each solid line box, source code other than the dependent libraries is audited, such as logic code for SGX SDK, occlum, myTF TOP, TOP operators. These code audits are followed by generation of respective metric values that do not change if the source code is not modified. Solid arrowed lines in the figure, labeled GCC and Java/Python, represent an open source auditable build tool. After being audited, the tools need to compile the audited SGX SDK and Occlum and the dependency base respectively. The solid line with arrows in the figure, labeled occum-gcc, represents the building tool obtained after the audit of the Occlum code. Because the construction tool is obtained by using audited Occlum code and audited GCC construction tool, the construction tool Occlum-GCC does not need to be audited.

And constructing the SGX SDK and Ocplus source codes of one or more audited versions through an audited GCC construction tool to generate respective executable files, namely the TEE environment components. And constructing the source code of the MyTF TOP of one or more audited versions and the audited occlium-gcc construction tool to generate corresponding executable files, namely software running components. The standard relying library or third party relying library is generally considered trusted and therefore its source code does not need to be audited. The dependent library is constructed by an audited open source Java/Python construction tool, the logic code of the audited TOP operator is constructed by an audited occlium-gcc construction tool, and a compiled TOP program is generated. And according to the configuration items provided by the software configuration module, packaging the compiled TOP program, the corresponding TEE environment component and the corresponding software running component determined according to the configuration items by using an audited packaging tool (such as Occlean Package) so as to generate the executable file of the TOP. Since both the source code and the build tool are audited, the build results (e.g., the elements shown in the circled box of FIG. 5) that are built are also audited.

According to the embodiment of the disclosure, the building tool is divided into modules, so that each module can be audited independently. After the source code of a certain module is modified, the source code of the module only needs to be audited again. In addition, when performing verification according to the metric values, if the metric values of the final TOP executable files are different, the metric values of the TEE environment component, the software running component, the compiled TOP program and the software configuration module can be verified respectively. In this way it can easily be located which module's source code has been modified/tampered with, and then just check the source code of that module.

The inventor of the present application finds that, in some cases, even if the source code is not modified, the executable files obtained in different compiling processes may be different, for example, unfixed information such as a time stamp at compiling time may be introduced into a pyc file compiled in a python environment. In order to make the above mentioned TEE's verification of the Tapp metric value hold, it is necessary to ensure that the same binary executable file compiled each time by the same source code is also the same.

Methods according to some embodiments of the present disclosure provide solutions to this problem. The method according to these embodiments comprises: providing a first software runtime environment component corresponding to the specific python system library and the specific python virtual machine and a second software runtime environment component corresponding to the specific java system library and the specific java virtual machine in the software runtime module; starting a first software running environment component or a second software running environment component through a construction tool according to the software running environment specified by the configuration item, and linking a corresponding specific dependency library according to the software running environment specified by the configuration item to compile the computational logic code; and adjusting variable information generated by compiling into specific information to generate the executable file, wherein the variable information comprises one or more of a timestamp, an author and a class file ordering mode.

For example, for the python runtime environment: 1) In the construction tool (for example, in the software running module) provided in the method according to the embodiment of the present disclosure, a specific python system library and a specific python virtual machine implementation are transplanted, so that the software logic module uses the specific python system library and the specific python virtual machine when constructing the computation logic code, thereby fixing the compiling tool of python. 2) The external dependency libraries required by the developers of Tapp are also automatically scanned for analysis and fixed down in the build tool (e.g., in the software runtime module). Such as a developer relying on numpy libraries, if a particular version is not specified, then the version of the externally dependent library of the default link may be different at different times, according to the prior art, which may cause the constructed binary file to be non-reproducible. In addition, the numpy library may also have child dependencies, so that the construction tool needs to analyze the whole dependency tree and fix the versions of all dependencies involved in the whole dependency tree. I.e., in the case where the external dependent library specified by the source code of the Tapp is not changed, so that the same version of the particular external dependent library (including sub-libraries) is used for each compilation. 3) Variable information (non-fixed information) which may be introduced by the compiling process, such as a timestamp which is introduced by a pyc file compiled by python, and the like, needs to be fixed, for example, adjusted to specific information. For example, for the java runtime environment, we also fix the system library version, the java virtual machine version, and the dependency tree version. In addition, when java is packaged into jar application, the timestamp, author and class file ordering modes are all variable information which needs to be adjusted and fixed.

Through the fixation of the system library, the virtual machine version, each dependency library version in the dependency tree and various variable information, the same binary executable file can be obtained by each construction of the same source code, and therefore the verifiable construction of java and python application programs can be achieved.

In the presently disclosed embodiments described above, in some cases, the trusted execution environment may be created in an on-chain node device in a blockchain network, such as in the first blockchain node shown in fig. 6. In these cases, the application may be an intelligent contract to be deployed in a blockchain network. The first block link point can be divided into a conventional execution environment and a trusted execution environment, a transaction submitted by a client (taking the transaction submitted by the client as an example) firstly enters a transaction/query interface in the conventional execution environment for type identification, the identified transaction which can be processed in a clear text is left in the conventional execution environment for processing, and the identified transaction which needs privacy processing (referred to as the "privacy transaction" for short) is transferred to the trusted execution environment for processing.

If the transaction type identified by the transaction/query interface in the regular execution environment is a private transaction, the private transaction is passed to the trusted execution environment of the first blockchain node, which decrypts the private transaction in the trusted execution environment. Assuming that the above-described private transaction is generated by a user at a certain client, the client may first generate clear text transaction content, which is then encrypted with a key. The encryption can adopt symmetric encryption or asymmetric encryption. Accordingly, the first block link point may decrypt the private transaction with the corresponding key to obtain the clear text transaction content. The transactions in the present disclosure may be used to implement relatively simple processing logic, e.g., similar to transfer logic in the related art. In these cases, the clear text transaction content may contain fields such as to, value, data, etc. in the ethernet lane network to indicate the transaction recipient address, the number of targets for the transaction transfer, and other data that the transaction may carry, respectively. The transactions in the present disclosure may also be used to implement relatively complex processing logic, such as may be implemented by means of smart contracts. In these cases, the clear text transaction content may contain code of the intelligent contract for creating the intelligent contract in the blockchain; the clear text transaction content may contain a contract address of a certain intelligent contract that has been created in the blockchain for invoking the intelligent contract.

An application built using a method according to an embodiment of the present disclosure may be deployed into a TEE at each chain node in the blockchain network to deploy the intelligent contract in the blockchain network for privacy transactions. After deploying the intelligent contract, the intelligent contract may be invoked. In response to the smart contract being invoked, the first block link point may allocate a portion of the EPC to the memory using a processor command added to the CPU, and encrypt the plaintext code into the EPC through an encryption engine MEE in the CPU. The encrypted content in the EPC enters the CPU and is decrypted into a plaintext. In the CPU, the code of the plaintext is operated to complete the execution process of the intelligent contract. Generally, after the CPU executes the plaintext code, the account status or contract status changes. The account status or contract status is stored in the blockchain and is written to a database, such as a local database, from the perspective of the blockchain link point. The database, which is typically stored on a storage medium, is more commonly a persistent storage medium. The persistent storage medium may be a magnetic disk, a floppy disk, or a memory or the like which can restore data after being powered on so as to be persistently stored. The first block chain node encrypts the plaintext execution result into a ciphertext execution result through the key, and the ciphertext execution result is decrypted only through the trusted execution environment, so that the ciphertext execution result can be ensured to be sufficiently safe. On the basis, the first block link point can execute the storage function code outside the trusted execution environment, and store the ciphertext execution result to an external storage space outside the trusted execution environment. The first block chain node may execute write cache function code within the trusted execution environment to store the plaintext execution results in a write cache within the trusted execution environment, e.g., the write cache may correspond to a "cache" as shown in fig. 6. Further, the first block link point may encrypt the data in the write cache and output the encrypted data from the trusted execution environment to be stored in the external storage space.

In some cases, the trusted execution environment may be created in a down-link node device outside of the blockchain network, as shown in fig. 7. In these cases, the operation of the down-link node device may be similar to that described above in connection with fig. 6 for the first blockchain node. Operations similar to those in the above case are omitted here for the sake of simplicity. There may be one or more of the node devices in the chain. Each of the down-link node devices may be connected to an on-link node in at least one blockchain network to receive computation requests from the on-link node. When a plurality of devices of the node under the chain form a cluster, the cluster can be connected to the node on the chain through a controller, and the controller can be responsible for message forwarding between the node on the chain and the node under the chain. It should be appreciated that the node devices under the chain do not need to perform a consensus process between the devices, and thus, each node device under the chain can perform its own computation task, and the controller can perform scheduling of computation resources among the plurality of node devices under the chain. The blockchain network may send a transaction request to the down-chain node device, such as a transaction request received by the controller from the up-chain node 4 as shown in fig. 7, which may be a computing request, for example, invoking an application program that has been deployed into the down-chain node device. In response to a request by the blockchain network, the downlinker node device executes an executable file constructed according to the method of an embodiment of the present disclosure in the trusted execution environment to perform the privacy calculations and return the calculation results to the blockchain network, for example to the upline node 4 via the controller. The returned calculation result can be stored in the block chain network.

Fig. 8 is a schematic structural diagram of at least part of a computing device 800 (which may be, for example, a node device in the above embodiments) according to an embodiment of the present disclosure. The computing device 800 may be, for example, the above-described on-chain node device or the off-chain node device. The computing device 800 includes one or more processors 810, one or more memories 820, and other components (not shown) typically present in a computer or the like. Each of the one or more memories 820 may store content accessible by the one or more processors 810, including instructions 821 executable by the one or more processors 810, and data 822 retrievable, manipulable, or stored by the one or more processors 810.

The instructions 821 may be any set of instructions to be executed directly, such as machine code, or indirectly, such as scripts, by one or more processors 810. The terms "instructions," "applications," "processes," "steps," and "programs" in this disclosure may be used interchangeably. The instructions 821 may be stored in an object code format for direct processing by the one or more processors 810, or in any other computer language, including scripts or collections of independent source code modules that are interpreted or compiled in advance, as needed. Other portions of this disclosure explain the functions, methods, and routines of the instructions 821 in more detail.

The one or more memories 820 may be any temporary or non-temporary computer-readable storage medium capable of storing content accessible by the one or more processors 810, such as a hard drive, memory card, ROM, RAM, DVD, CD, USB memory, writable and read-only memories, etc. One or more of the one or more memories 820 may comprise a distributed storage system, where the instructions 821 and/or data 822 may be stored on a plurality of different storage devices, which may be physically located at the same or different geographic locations. One or more of the one or more memories 820 may be connected to the one or more first devices 810 via a network and/or may be directly connected to or incorporated into any of the one or more processors 810.

The one or more processors 810 may retrieve, store, or modify the data 822 according to the instructions 821. Although the subject matter described in this disclosure is not limited by any particular data structure, data 822 may also be stored in a computer register (not shown) as a table or XML document having many different fields and records in a relational database. The data 822 may be formatted in any computing device readable format, such as, but not limited to, binary values, ASCII, or unicode. Further, the data 822 can include any information sufficient to identify the relevant information, such as a number, descriptive text, proprietary code, pointer, reference to data stored in other memory, such as at other network locations, or information used by a function to calculate the relevant data.

The one or more processors 810 may be any conventional processor, such as a commercially available Central Processing Unit (CPU), graphics Processing Unit (GPU), or the like. Alternatively, one or more processors 810 may also be special-purpose components, such as an Application Specific Integrated Circuit (ASIC) or other hardware-based processor. Although not required, one or more of processors 810 may include specialized hardware components to perform particular computing processes faster or more efficiently.

Although one or more processors 810 and one or more memories 820 are schematically illustrated in fig. 8 within the same block, computing device 800 may actually comprise multiple processors or memories that may reside within the same physical housing or within different physical housings. Thus, references to a processor, computer, computing device, or memory are to be understood as including references to a collection of processors, computers, computing devices, or memories that may or may not operate in parallel.

Fig. 9 is an exemplary block diagram of a generic hardware system 900 that may be applied in accordance with one or more exemplary embodiments of the present disclosure. A system 900 will now be described with reference to fig. 9, which is an example of a hardware device that may be applied to aspects of the present disclosure. The computing device 800 in the various embodiments described above may comprise all or part of the system 900. System 900 may be any machine configured to perform processing and/or computing, and may be, but is not limited to, a workstation, a server, a desktop computer, a laptop computer, a tablet computer, a personal data assistant, a smart phone, a vehicle computer, or any combination thereof.

System 900 may include components connected to bus 902 or in communication with bus 902, possibly via one or more interfaces. For example, the system 900 may include a bus 902, as well as one or more processors 904, one or more input devices 906, and one or more output devices 909. The one or more processors 904 may be any type of processor and may include, but are not limited to, one or more general purpose processors and/or one or more special purpose processors (e.g., special purpose processing chips). Various operations and/or steps of the methods described above may be implemented by one or more processors 904 executing instructions.

Input device 906 may be any type of device that can input information to a computing device, which may include, but is not limited to, a mouse, a keyboard, a touch screen, a microphone, and/or a remote control. Output device 909 may be any type of device that can present information and may include, but is not limited to, a display, speakers, a video/audio output terminal, a vibrator, and/or a printer.

System 900 may also include a non-transitory storage device 910 or be connected to a non-transitory storage device 910. The non-transitory storage device 910 may be any storage device that is non-transitory and that can enable storage of data, and may include, but is not limited to, a magnetic disk drive, an optical storage device, solid state memory, a floppy disk, a hard disk, a magnetic tape, or any other magnetic medium, an optical disk, or any other optical medium, a ROM (read only memory), a RAM (random access memory), a cache memory, and/or any other memory chip/chip set, and/or any other medium from which a computer can read data, instructions, and/or code. The non-transitory storage device 910 may be removable from the interface. The non-transitory storage device 910 may have data/instructions/code for implementing the methods, operations, steps, and processes described above.

System 900 may also include a communication device 912. The communication device 912 may be any type of device or system capable of communicating with external devices and/or with a network and may include, but is not limited to, a modem, a network card, an infrared communication device, a wireless communication device, and/or a chipset, such as a bluetooth device, an 802.11 device, a WiFi device, a WiMax device, a cellular communication device, a satellite communication device, and/or the like.

The bus 902 may include, but is not limited to, an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus. In particular, for on-board devices, the bus 902 may also include a Controller Area Network (CAN) bus or other architecture designed for application on a vehicle.

System 900 may also include a working memory 914, which may be any type of working memory that can store instructions and/or data useful to the operation of processor 904, which may include, but is not limited to, a random access memory and/or a read-only memory device.

Software elements may reside in working memory 914, including but not limited to an operating system 916, one or more application programs 919, drivers, and/or other data and code. Instructions for performing the methods, operations, and steps described above may be included in one or more application programs 919. Executable code or source code for the instructions of the software elements may be stored in a non-transitory computer-readable storage medium, such as the storage device 910 described above, and may be read into the working memory 914 by compilation and/or installation. Executable or source code for the instructions of the software elements may also be downloaded from a remote location.

It is also to be understood that variations may be made in accordance with specific requirements. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. In addition, connections to other computing devices, such as network input/output devices, may be employed. For example, some or all of the methods or apparatus according to embodiments of the present disclosure may be implemented by programming hardware (e.g., programmable logic circuitry including Field Programmable Gate Arrays (FPGAs) and/or Programmable Logic Arrays (PLAs)) in assembly or hardware programming languages such as VERILOG, VHDL, C + +, using logic and algorithms according to the present disclosure.

It should also be understood that the components of system 900 may be distributed across a network. For example, some processes may be performed using one processor, while other processes may be performed by another processor remote from the one processor. Other components of the system 900 may also be similarly distributed. As such, system 900 may be interpreted as a distributed computing system performing processing at multiple locations.

Although aspects of the present disclosure have been described thus far with reference to the accompanying drawings, the above-described methods, systems and apparatuses are merely exemplary examples, and the scope of the present disclosure is not limited by these aspects, but is only limited by the following aspects: the appended claims and their equivalents. Various elements may be omitted or equivalent elements may be substituted. In addition, the steps may be performed in a different order than described in the present disclosure. Further, the various elements may be combined in various ways. It is also important that as technology develops many of the elements described can be replaced by equivalent elements which appear after the present disclosure.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as ABEL (Advanced Boolean Expression Language), AHDL (alternate Hardware Description Language), traffic, CUPL (core universal Programming Language), HDCal, jhddl (Java Hardware Description Language), lava, lola, HDL, PALASM, rhyd (Hardware Description Language), and vhigh-Language (Hardware Description Language), which is currently used in most popular applications. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium that stores computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be conceived to be both a software module implementing the method and a structure within a hardware component.

The systems, apparatuses, modules or units described in the above embodiments may be specifically implemented by a computer chip or an entity, or implemented by a product with certain functions. One typical implementation device is a server system. Of course, this application does not exclude that with future developments in computer technology, the computer implementing the functionality of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle mounted human interaction device, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device or a combination of any of these devices.

Although one or more embodiments of the disclosure provide method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When implemented in an actual device or end product, can be executed sequentially or in parallel according to the methods shown in the embodiments or figures (e.g., parallel processor or multi-thread processing environments, even distributed data processing environments). The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in processes, methods, articles, or apparatus that include the recited elements is not excluded. For example, if the terms first, second, etc. are used to denote names, they do not denote any particular order.

For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, when implementing one or more of the present disclosure, the functions of each module may be implemented in one or more software and/or hardware, or the modules implementing the same functions may be implemented by a plurality of sub-modules or sub-units, etc. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The present disclosure is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, may implement the information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

One skilled in the art will appreciate that one or more embodiments of the present disclosure may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present disclosure may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

One or more embodiments of the disclosure may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present disclosure may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The embodiments in the disclosure are described in a progressive manner, and the same and similar parts among the embodiments can be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment. In the description of the present disclosure, reference to the description of "one embodiment," "some embodiments," "an example," "a specific example," or "some examples" or the like means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present disclosure. In this disclosure, the schematic representations of the terms used above are not necessarily intended to be the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this disclosure can be combined and combined by one skilled in the art without contradiction.

The above description is merely exemplary of one or more embodiments of the present disclosure and is not intended to limit the scope of one or more embodiments of the present disclosure. Various modifications and alterations to one or more embodiments of the present disclosure will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present disclosure should be included in the scope of claims.

Claims

1. A method for a library operating system LibOS of a trusted execution environment TEE, comprising:

providing a building tool, wherein the building tool comprises a TEE environment module, a software operation module, a software logic module and a software configuration module;

receiving, by the software logic module, computational logic code developed by a user to run in a TEE;

receiving, by the software configuration module, a configuration item for the computational logic code, the configuration item specifying:

a TEE software development environment for which the computational logic code is expected;

the LibOS expected by the computation logic code; and

a software runtime environment expected by the computational logic code;

starting corresponding components in the TEE environment module according to the TEE software development environment and the LibOS specified by the configuration items through the construction tool, starting corresponding components in the software operation module according to the software operation environment specified by the configuration items, and compiling the calculation logic codes; and packaging the compiled computational logic code, the corresponding component in the TEE environment module, the corresponding component in the software running module and the configuration item to generate an executable file corresponding to the computational logic code.

2. The method of claim 1, wherein the computational logic code invokes a dependency library that is external to the TEE, the method further comprising:

and linking the corresponding dependency libraries according to the software running environment specified by the configuration item through the construction tool so as to compile the calculation logic code.

3. The method of claim 1, wherein the computational logic code computes encrypted input data that is outside of a TEE, wherein,

the configuration item further specifies:

the desired data entry policy of the computational logic code;

the expected data output strategy of the calculation logic code; and

software operating resources expected by the computational logic code;

the method further comprises the following steps:

starting a software running environment aiming at the computational logic code through the software running module according to the software running environment specified by the configuration item, configuring a TEE and external data interaction mode according to the data input strategy and the data output strategy specified by the configuration item, and limiting resources in the running of the computational logic code according to the software running resources specified by the configuration item so as to generate a computational instance which corresponds to the computational logic code and runs in the LibOS.

4. A method according to claim 3, wherein the software execution resources specified by the configuration item include resources required to execute one or more processes involved in the computational logic code, the method further comprising:

and calculating the total resources required by the computing instance according to the resources required by the one or more processes and the resources required by the TEE environment module and the software running module through the construction tool, and limiting the resources of the computing logic code during running according to the total resources required by the computing instance.

5. The method of claim 4, further comprising:

and responding to the starting of a new process when the computing instance runs, and performing process resource limitation on the new process according to the resources required by the one or more processes specified by the configuration item.

6. The method of claim 1, wherein,

the TEE environment module includes one or more TEE software development environment components corresponding to one or more versions of a TEE software development environment and one or more LibOS components corresponding to one or more versions of a library operating system LibOS established within the TEE,

the software execution module includes one or more software execution environment components corresponding to one or more software execution environments,

the configuration item specifies:

a version of the TEE software development environment expected by the computational logic code;

a version of LibOS expected by the computational logic code; and

a software runtime environment expected by the computational logic code;

the method further comprises the following steps:

the building tool starts corresponding TEE software development environment components in the one or more TEE software development environment components according to the version of the TEE software development environment specified by the configuration item, starts corresponding LibOS components in the one or more LibOS components according to the version of the LibOS specified by the configuration item, starts corresponding software operation environment components in the one or more software operation environment components according to the software operation environment specified by the configuration item, and compiles the calculation logic code; and packaging the compiled computational logic code, the corresponding TEE software development environment component, the corresponding LibOS component, the corresponding software operation environment component and the configuration item to generate the executable file.

7. The method of claim 6, wherein,

each of the one or more TEE software development environment components and the one or more LibOS components is: the audited corresponding first source code, built with the audited generic building tool, the generated first executable file,

each of the one or more software runtime environment components is: and the audited corresponding second source code is constructed by the corresponding construction tool provided by the corresponding LibOS component in the audited one or more LibOS components, and the generated second executable file is obtained.

8. The method of claim 7, wherein,

the first source code does not include code related to the functionality of the software execution module, nor does it include code related to the functionality of the computational logic code;

the second source code does not include code related to functionality of the TEE environment module nor code related to functionality of the computational logic code;

the computational logic code does not include code related to the functionality of the TEE environment module, nor does it include code related to the functionality of the software execution module.

9. The method of claim 1, wherein the software runtime environment comprises java or python, the method further comprising:

providing in the software runtime module a first software runtime environment component corresponding to a particular python system library and a particular python virtual machine, and a second software runtime environment component corresponding to a particular java system library and a particular java virtual machine;

starting the first software running environment component or the second software running environment component through the construction tool according to the software running environment specified by the configuration item, and linking a corresponding specific dependency library according to the software running environment specified by the configuration item so as to compile the computational logic code;

adjusting variable information generated by compiling to specific information to generate the executable file,

wherein the variable information comprises one or more of a timestamp, an author, and a sorting manner of the class file.

10. The method of claim 1, wherein the TEE is implemented in a down-link node device outside of a blockchain network, the down-link node device configured to perform privacy calculations in the TEE and return results of calculations to the blockchain network in response to a request by the blockchain network, wherein the privacy calculations execute the executable file.

11. A method for a library operating system LibOS of a trusted execution environment TEE, comprising:

providing a build tool comprising a TEE environment module, a software execution module, a software logic module, and a software configuration module, wherein the TEE environment module comprises one or more TEE software development environment components corresponding to one or more versions of a TEE software development environment and one or more LibOS components corresponding to one or more versions of a library operating system LibOS established within the TEE, and the software execution module comprises one or more software execution environment components corresponding to one or more software execution environments, one or more data input components corresponding to one or more data input policies, one or more data output components corresponding to one or more data output policies, and one or more software execution resource components corresponding to one or more software execution resource configurations;

receiving, by the software logic module, computational logic code developed by a user to be run in the TEE, the computational logic code computing encrypted input data that is outside the TEE;

a version of LibOS expected by the computational logic code;

a software runtime environment expected by the computational logic code;

the desired data entry policy of the computational logic code;

calculating a desired data output policy of the logic code; and

software operating resources expected by the computational logic code; and

starting corresponding components in the TEE environment module according to the version of the TEE software development environment specified by the configuration item and the version of the LibOS through the construction tool, starting corresponding components in the software running module according to the software running environment specified by the configuration item, and compiling the calculation logic code; and packaging the compiled computational logic code, the corresponding component in the TEE environment module, the corresponding component in the software running module and the configuration item to generate an executable file corresponding to the computational logic code.

12. The method of claim 11, wherein the software runtime environment comprises one or more of java, python, and C/C + +.

13. The method of claim 11, wherein the data entry policy includes loading directly into the TEE/slice streaming loading into the TEE, and/or whether to cache in the TEE.

14. The method of claim 11, wherein the data export policy includes whether all export files are to be exported and/or whether all export files are to be cached.

15. The method of claim 11, wherein the software execution resources include one or more of parallelism, maximum file size, heap space size, stack space size, memory map space size, and process space size.

16. The method of claim 11, wherein the computational logic code comprises code for implementing an operator in machine learning.

17. The method of claim 11, wherein the computational logic code invokes a dependency library outside of a TEE, the method further comprising:

18. The method of claim 11, further comprising:

starting a software running environment aiming at the computational logic code through the software running module according to the software running environment specified by the configuration item, configuring a data interaction mode of the TEE and the outside according to the data input strategy and the data output strategy specified by the configuration item, and limiting resources of the computational logic code during running according to the software running resources specified by the configuration item so as to generate a computational instance which corresponds to the computational logic code and runs in the LibOS.

19. The method of claim 18, wherein the software execution resources specified by the configuration item include resources required to execute one or more processes involved in the computing logic code, the method further comprising:

20. The method of claim 19, further comprising:

and responding to starting a new process when the computing instance runs, and carrying out process resource limitation on the new process according to the resources required by the one or more processes specified by the configuration item.

21. The method of claim 11, wherein,

each of the one or more TEE software development environment components and the one or more LibOS components is: the audited corresponding first source code, constructed by the audited generic construction tool, the generated first executable file,

22. The method of claim 21, wherein,

the second source code does not include code related to the functionality of the TEE environment module nor code related to the functionality of the computational logic code;

23. The method of claim 11, further comprising:

providing a first software runtime component corresponding to a specific python system library and a specific python virtual machine and a second software runtime component corresponding to a specific java system library and a specific java virtual machine in the software runtime module;

24. The method of claim 11, wherein the TEE is implemented in a down-link node device outside of a blockchain network, the down-link node device configured to perform privacy calculations in the TEE and return results of calculations to the blockchain network in response to a request by the blockchain network, wherein the privacy calculations execute the executable file.

25. A method for a library operating system LibOS of a trusted execution environment TEE, comprising:

receiving, by a build tool, computation logic code developed by a user to be run in a TEE, the computation logic code computing encrypted input data outside the TEE and/or the computation logic code invoking a dependency library outside the TEE;

receiving, by the build tool, a configuration item for the computational logic code, the configuration item specifying a data entry policy and/or a runtime environment of a dependency library for the computational logic code; and

and starting a component corresponding to the data input strategy specified by the configuration item and/or a component corresponding to the running environment of the dependency base specified by the configuration item in the construction tool through the construction tool, and compiling and packaging the computation logic code to generate an executable file corresponding to the computation logic code.

26. A non-transitory computer-readable storage medium having stored thereon a series of computer-executable instructions that, when executed by one or more computing devices, cause the one or more computing devices to:

providing a build tool comprising a trusted execution environment TEE environment module, a software execution module, a software logic module, and a software configuration module, wherein the TEE environment module comprises one or more TEE software development environment components corresponding to one or more versions of a TEE software development environment, and one or more LibOS components corresponding to one or more versions of a library operating system LibOS established within the TEE, the software execution module comprising one or more software execution environment components corresponding to one or more software execution environments, one or more data input components corresponding to one or more data input policies, one or more data output components corresponding to one or more data output policies, and one or more software execution resource components corresponding to one or more software execution resource configurations;

receiving, by the software logic module, computational logic code developed by a user to run in a TEE, the computational logic code computing encrypted input data that is outside the TEE;

the version of LibOS expected by the computation logic code;

a software runtime environment expected by the computational logic code;

the computing logic code expects a data input policy;

the expected data output strategy of the calculation logic code; and

software operating resources expected by the computational logic code; and

starting corresponding components in the TEE environment module according to the version of the TEE software development environment and the version of the LibOS specified by the configuration item through the construction tool, starting corresponding components in the software operation module according to the software operation environment specified by the configuration item, and compiling the calculation logic code; and packaging the compiled computational logic code, the corresponding component in the TEE environment module, the corresponding component in the software running module and the configuration item to generate an executable file corresponding to the computational logic code.

27. The non-transitory computer readable storage medium of claim 26, wherein the software execution environment includes one or more of java, python, and C/C + +.

28. The non-transitory computer readable storage medium of claim 26, wherein the data entry policy comprises loading directly into the TEE/slice streaming into the TEE, and/or whether cached in the TEE.

29. The non-transitory computer readable storage medium of claim 26, wherein the data export policy includes whether all export files are exported and/or whether all export files are cached.

30. The non-transitory computer readable storage medium of claim 26, wherein the software execution resources include one or more of a parallelism, a maximum file size, a heap space size, a stack space size, a memory map space size, and a process space size.

31. The non-transitory computer-readable storage medium of claim 26, wherein the computational logic code comprises code for implementing an operator in machine learning.

32. The non-transitory computer-readable storage medium of claim 26, wherein the computational logic code invokes a dependency library that is outside of the TEE, wherein the series of computer-executable instructions, when executed by one or more computing devices, further cause the one or more computing devices to:

and linking the corresponding dependency libraries according to the software running environment specified by the configuration item through the construction tool, thereby compiling the computational logic code.

33. The non-transitory computer-readable storage medium of claim 26, wherein the series of computer-executable instructions, when executed by one or more computing devices, further cause the one or more computing devices to:

34. The non-transitory computer readable storage medium of claim 33, wherein the software execution resources specified by the configuration items include resources required to execute one or more processes involved in the computing logic code, wherein the series of computer executable instructions, when executed by one or more computing devices, further cause the one or more computing devices to:

35. The non-transitory computer-readable storage medium of claim 34, wherein the series of computer-executable instructions, when executed by one or more computing devices, further cause the one or more computing devices to:

36. The non-transitory computer-readable storage medium of claim 26,

37. The non-transitory computer-readable storage medium of claim 36,

38. The non-transitory computer-readable storage medium of claim 26, wherein the series of computer-executable instructions, when executed by one or more computing devices, further cause the one or more computing devices to:

39. A computing device comprising one or more processors and one or more memories configured to store a series of computer-executable instructions, wherein the series of computer-executable instructions, when executed by the one or more processors, cause the one or more processors to:

providing a build tool comprising a Trusted Execution Environment (TEE) environment module, a software execution module, a software logic module, and a software configuration module, wherein the TEE environment module comprises one or more TEE software development environment components corresponding to one or more versions of a TEE software development environment and one or more LibOS components corresponding to one or more versions of a library operating system (LibOS) established within the TEE, and the software execution module comprises one or more software execution environment components corresponding to one or more software execution environments, one or more data input components corresponding to one or more data input policies, one or more data output components corresponding to one or more data output policies, and one or more software execution resource components corresponding to one or more software execution resource configurations;

a version of LibOS expected by the computational logic code;

a software execution environment expected by the computational logic code;

the computing logic code expects a data input policy;

calculating a desired data output policy of the logic code; and

software operating resources expected by the computational logic code; and