Secure execution support for A.I. systems (and other heterogeneous systems)

A method for securing Secure Objects that are protected from other software on a heterogeneous data processing system including a plurality of different types of processors wherein different portions of a Secure Object may run on different types of processors. A Secure Object may begin execution on a first processor then, depending on application requirements, the Secure Object may make a call to a second processor passing information to the second processor using a special inter-processor function call. The second processor performs the requested processing and then performs an inter-processor “function return” returning information as appropriate to the Secure Object on the first processor.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is related to, makes reference to the following patent applications all of which are incorporated herein by reference: U.S. patent application Ser. No. 12/492,738, filed on Jun. 26, 2009, to Richard H. Boivie, entitled “Support for Secure Objects in a Computer System”, now issued as U.S. Pat. No. 8,819,446; U.S. patent application Ser. No. 12/878,696, filed on Sep. 9, 2010, to Richard H. Boivie, entitled “Cache Structure for a Computer System Providing Support for Secure Objects”, now issued as U.S. Pat. No. 9,298,894; U.S. patent application Ser. No. 13/033,367, filed on Feb. 23, 2011, to Boivie and Williams, entitled “Secure Object Having Protected Region, Integrity Tree and Unprotected Region”, now issued as U.S. Pat. No. 8,578,175; U.S. patent application Ser. No. 13/033,455, filed on Feb. 23, 2011, to Boivie and Williams, entitled “Building and Distributing Secure Object Software”, now issued as U.S. Pat. No. 8,954,752; U.S. patent application Ser. No. 13/226,079, filed on Sep. 6, 2011, to Boivie and Pendarakis, entitled “Protecting Application Programs from Malicious Software or Malware”, now issued as U.S. Pat. No. 9,846,789; and U.S. patent application Ser. No. 14/839,691, filed on Aug. 28, 2015, to Boivie et al, entitled “System and Method for Supporting Secure Objects Using a Memory Access Control Monitor”.

BACKGROUND OF THE INVENTION

Field of the Invention

The disclosed invention relates generally to an embodiment of secure execution support, and more particularly, but not by way of limitation, relating to a use of secure execution support for Artificial Intelligence (AI) systems and other heterogeneous systems.

Description of the Related Art

In recent years computers systems have been increasingly under attack by various forms of hacking and malware. To address this, the concept of a ‘Secure Object’ was introduced comprising code and data that is cryptographically protected from the other software on a computer system including any malware that an attacker may be able to introduce into a targeted computer system. Secure Objects and computer architectures for supporting these Secure Objects have been discussed previously in the patent applications incorporated herein by reference.

In the last few years computer systems have become more heterogeneous incorporating in addition to traditional CPUs (Central Processing Units), other kinds of special processors such as GPUs (Graphical Processing Units) and special-purpose processing units for Artificial Intelligence applications such as ANNs (Artificial Neural Networks) and TPUs (Google Tensor Processing Units).

As systems become more heterogeneous, there is a need to protect the security of applications that run on these heterogeneous systems.

SUMMARY OF INVENTION

In view of the foregoing and other problems, disadvantages, and drawbacks of the aforementioned background art, an exemplary aspect of the disclosed invention provides secure execution support for Artificial Intelligence (AI) systems and other heterogeneous systems.

One aspect of the present invention is to provide support for Secure Objects that are protected from other software on a heterogeneous data processing system comprising a plurality of different types of processors wherein different portions of a Secure Object may run on different types of processors. A Secure Object may begin execution on a first processor then, depending on application requirements, the Secure Object may make a call to a second processor passing information to the second processor using a special inter-processor function call. The second processor performs the requested processing and then performs an inter-processor “function return”, returning “return values” as appropriate to the Secure Object on the first processor. The processing on the second processor can be considered an “extension” of the Secure Object on the first processor.

Another aspect of the present invention provides a method for securing a data processing system including providing a Secure Object comprising code and data that is protected from the other software on the data processing system on a first processor which is a first type of processor, wherein the data processing system has a plurality of processors of different types, beginning execution of the Secure Object on the first processor, responsive to a portion of the Secure Object being needed to be executed on a second processor which is a second type of processor, by the first processor calling the second processor in a special call, returning by the second processor to the first processor a new value for an integrity root of the Secure Object, and retrieving, by the first processor, encrypted information from system memory using a crypto key and the integrity root.

Another example aspect of the disclosed invention is to provide a computer readable medium storing a method for securing Secure Objects on a heterogeneous data processing system comprising a plurality of different types of processors wherein different portions of a Secure Object may run on different types of processors wherein a Secure Object may begin execution on a first processor then, depending on application requirements, the Secure Object may make a call to a second processor passing information to the second processor via a special inter-processor function call. The second processor performs the requested processing and then performs an inter-processor “function return”, returning “return values” as appropriate to the Secure Object on the first processor.

Another example aspect of the disclosed invention is to provide a computer readable medium storing a method for securing a data processing system including providing a Secure Object comprising code and data that is protected from the other software on the data processing system on a first processor which is a first type of processor, wherein the data processing system has a plurality of processors of different types, beginning execution of the Secure Object on the first processor, responsive to a portion of the Secure Object being needed to be executed on a second processor which is a second type of processor, by the first processor calling the second processor in a special call, returning by the second processor to the first processor a new value for an integrity root of the Secure Object, and retrieving, by the first processor, encrypted information from system memory using a crypto key and the integrity root.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

There is the concept of a Secure Object comprising code and data that is protected from the other software on a system. The Secure Object, like objects in other object-oriented programming languages, contains data and code that manipulates and provides access to that data. A Secure Object differs from objects in existing programming languages such as Java, in that the Secure Object's private code and data are cryptographically protected so that no other software can access the Secure Object's private information.

FIG.1provides an example of what a Secure Object100might look like in a high-level programming language. This Secure Object includes private data101and private methods102, as well as methods that allow access to the Secure Object through its public interfaces103,105. Secure Objects can be used by other software (that is, other software can “call” or “send messages” to a Secure Object) but other software can only access a Secure Object through its public interfaces103,105.

In one embodiment of a Secure Object based system, private information is almost always encrypted. It is encrypted while it is in memory and while it is on disk, whether it is in a paging system or in a file system.

FIG.2shows how the compiled version200of a Secure Object might appear in memory. A Secure Object's private information is “in the clear” only when: It is accessed from inside the Secure Object; and only while that information is inside the microprocessor.

Since no other code has access to a Secure Object's private information, a software attack that gets into a system through a vulnerability in another software module has no means of accessing the unencrypted version of the Secure Object's private information. As demonstrated inFIG.2, the private information that is encrypted can include private code as well as private data corresponding to the private code102and private data101inFIG.1.

For example, a design can include two new instructions that are used to enter and leave a method of a Secure Object, “esm” and “lsm”, for “enter secure method” and “leave secure method”, respectively.

The “esm” instruction loads crypto key information into special registers that are used to decrypt a Secure Object's private code and data as the code and data move from memory into the microprocessor. Other data such as the arguments passed to the method and the return address that was saved when the Secure Object was called are accessed without this decryption.

FIG.3is a block diagram300of a microprocessor301that provides support for Secure Objects. This microprocessor executes code much like microprocessors in common use today but includes a crypto-engine302for (1) decrypting sensitive information as that information moves from external memory303into the L1 cache304and (2) encrypting sensitive information as it moves from the L1 cache304to external memory303. This cryptography is used to ensure that other software including viruses, worms and other “attack software” will not be able to access the unencrypted version of sensitive information.

FIG.3also shows a block305labeled “keys” within the crypto engine that holds the keys that are used in the encryption and decryption processes. The keys block might include a set of crypto registers specifically designated for holding these keys. It is noted that the crypto engine302could be a coprocessor associated with the processor307, or the crypto engine could be a function executed by the CPU processor itself.

The “lsm” instruction, which can simply consist of an opcode, restores the previous state of the special crypto registers305, so that ordinary non-secure code can execute without this encryption and decryption when the secure method returns.

In the Secure Object system, the keys305that are used to decrypt a Secure Object's private information are available to the Secure Object but these keys are not available to any other code.

Turning now to example embodiments, Secure Objects can be used to protect the confidentiality and integrity of applications or sensitive portions of applications. Secure Objects can also be used to protect software containers such as Docker containers and to protect virtual machines on a system that supports the concurrent execution of multiple virtual machines.

As systems become more heterogeneous, incorporating in addition to CPUs other kinds of processors such as GPUs (Graphical Processing Units), ANNs (artificial neural networks), FPGAs (Field Programmable Gate Arrays), TPUs (Tensor Processing Units), IBM Q (Quantum) processors etc., there is a need to protect the confidentiality and integrity of applications that run on heterogeneous systems.

As discussed in the previous patent applications incorporated herein by reference, a CPU-based system can protect the confidentiality and integrity of a Secure Object from the other software on the system with cryptography and an integrity tree if the crypto key and the root of the integrity tree are protected from the other software. The crypto key and the integrity tree can be managed by hardware or by a combination of hardware and firmware. For example, the hardware and firmware can be in, or run in, the CPU.

However, in a heterogeneous system, other kinds of processors will need to be able to access the unencrypted form of a Secure Object's information and may need to access the Secure Object's crypto key and integrity root—while protecting that information from other software.

FIG.4illustrates an exemplary format of an executable file400that includes Secure Object-based software. The file contains (1) the Secure Object code and data in encrypted form401, (2) the initial version of an integrity tree402that will be used at run-time to protect the integrity of the Secure Object's code and data, and (3) loader code including an “esm” instruction (in403) to ‘Enter Secure Mode’. The “esm” instruction allows a Secure Object's sensitive information to be decrypted on the path from external memory into the CPU and encrypted on the path from CPU to external memory.

FIG.4also shows communication buffers in the unprotected region403. These will be discussed in more detail below. Thus, inFIG.4, the unshaded region403of the binary file is an unprotected region that includes a loader, the “esm” instruction including the “esm” operand (or handle), and communication buffers. The shaded regions include the integrity tree402and the encrypted region401that includes one or more of code, data, stack, and heap data. This file might be in a standard executable format, such as ELF. The code and data are encrypted so that only the target CPU can read the encrypted region and only in secure mode.

The binary file for the secure object contains the encrypted code and data401of the secure object, the initial integrity tree402, and the unprotected region403including communication buffers, the loader code and the “esm” instruction that will be used to enter secure mode at run-time.

In a first example embodiment of the current invention, shown inFIG.5, a system500will consist of a system memory502that is accessible by various kinds of processors, such as one or more CPUs (central processing units)510, GPUs (Graphical Processing Units)512, ANNs (artificial neural networks), FPGAs (Field Programmable Gate Arrays)514, TPUs (Tensor Processing Units), IBM Q (Quantum) processors or other Quantum processors516, ECC (Elliptic Curve Cryptography) processors518etc. A Secure Object's private information will be cryptographically protected while it is in this system memory502and this information will only be available in unencrypted form to a processor that has the Secure Object's crypto key. Moreover, this private information will only be writable in a way that does not later cause an integrity exception, by a processor that has both the Secure Object's crypto key and the root of its integrity tree.

System memory502may also include “unprotected memory”504which a Secure Object can use for communications buffers to communicate with other entities. Information in this unprotected memory504is not protected by the Secure Object protection mechanisms although a Secure Object will normally protect information that it puts in this area of unprotected memory504by other means such as SSL/TLS (Security Socket Layer/Transport Security Layer), IPsec (Internet Protocol Security) or dm-crypt (a transparent disk encryption subsystem) as discussed in the previous patent applications.

In this example embodiment, a Secure Object will begin execution on a CPU (Central Processing Unit)510. When some portion of the processing is to be done on a special processor such as a GPU (Graphic Processing Unit)512or a TPU (Tensor Processing Unit), for example, the CPU510will “call” the special processor512to518via a “hardware subroutine call”. This “call” will include an indication of the processor that is being called, an indication of the specific function that is being called, the address(es) in system memory of the data to be processed and the address(es) in system memory502where return values can be stored. The “call” will also securely pass the Secure Object's crypto key and integrity root to the special processor so that the special processor can access and update the Secure Object's cryptographically-protected information in system memory510. In this embodiment, the special processors, such as a GPU (Graphics Processing Unit)512, FPGA (Field-programmable gate array)514, Q Processor (Quantum Processor)516, and ECC (Elliptic Curve Cryptography) Processor518, include crypto engines520,522,524,526, and528, respectively, that decrypt information and check integrity when reading from system memory502and encrypt information and update integrity values when writing system memory502as discussed in the previous applications. When the special processor512to518completes the requested processing, it will “return” to the CPU510any return values as well as a new value for the root of the Secure Object's integrity tree. At this point, the Secure Object can resume execution on the CPU510and access and update its cryptographically-protected information in system memory502, including any information that was written by the special processor (512to518) and the CPU510will be able to do this without getting an integrity exception.

The CPU510will also be able to “call” other special processors512to518as necessary. The “calls” and “returns” can be implemented as inter-processor interrupts. The information passed to or returned from a “hardware subroutine call” can be passed in cryptographically-protected system memory506and the crypto key and the root of the integrity tree can be securely passed via a standard communications security mechanism like TLS (Transport Layer Security) under a key negotiated between the CPU and the special processor at system boot. The TLS packets can be transferred via an inter-processor communications mechanism like PCIe (Peripheral Component Interconnect Express) or through “unprotected” system memory504.

Of course, this example embodiment is not limited to special ‘Artificial Intelligence’ processors. It can also support other kinds of special processors. The design can include an ECC (Elliptic Curve Cryptography) processor, as shown in FIG.5or an RSA (Rivest Shamir Adleman) processor for generating and validating digital signatures.

In a second example embodiment, shown inFIG.6, a Secure Object's sensitive information is unencrypted in system memory602but access control mechanisms are used to control access to this memory602as discussed in U.S. patent application Ser. No. 14/839,691. In this second example embodiment, a memory page is labeled with the ID of the Secure Object that owns the page and when a Secure Object “calls” a special processor512to518, the Secure Object's ID is securely passed to the special processor512to518. This Secure Object ID allows the special processor512to518to access the Secure Object's memory and since the memory is unencrypted, the special processor512to518can read and write the Secure Object's protected information in system memory602without having to decrypt or encrypt that information and without having to check or generate integrity values. When protected information is accessed by a special processor512to518, or by a CPU thread of the CPU510, that does not have the appropriate Secure Object ID, a CPU510exception will occur which will allow firmware on the CPU510to intervene and handle the exception. For example, if a disk driver or disk firmware attempts to read a protected memory page to page it out to disk, say, firmware on the CPU510can catch the exception and encrypt the page before allowing the disk driver or disk firmware to read the page to page it out.

The example embodiments described above are sufficient if special processors (such as512to518) contain only trustworthy hardware and firmware. However, if applications can load their own software into a special processor512to518, additional mechanisms are needed to make sure that this potentially malicious software cannot compromise the private information of other secure applications. For example, when one Secure Object on a special processor512to518acquires the information needed to access a secure Object's private information in system memory such as the crypto key and integrity root in the first example embodiment or the Secure Object's ID in the second example embodiment, this information, which will be called, in the remainder of this patent application the “access key” for accessing a Secure Object's private information, should not be available to other software that may run on the special processor.

When a Secure Object on a CPU510makes a “call” to a special processor512to518, the “access key” that is needed to access the Secure Object's private information in system memory502or602can be securely passed from trusted firmware on the CPU510to trusted firmware on the special processor512to518. The trusted firmware on the special processor512to518can use this information to make the data in system memory502or602that is to be processed available to the “called” function. The firmware can do this for example by getting the information from system memory502or602and passing it on to the “called” function, or by configuring access control hardware or crypto hardware on the special processor512to518so that the “called” function can access the Secure Object information in system memory502or602directly.

However, the trusted firmware will not give the “access key” to any untrusted software. Moreover, when the “called” function on a special processor512to518“returns” to the CPU510, the trusted firmware can clear any registers and any memory on the special processor that was used by the “called” function to remove any traces of the Secure Object's private information to protect that information from any untrusted software that may subsequently run on the special processor512to518. Prior to the “return” to the CPU510, the trusted firmware can also delete the “access key” on the special processor512to518.

If a special processor512to518can process multiple requests concurrently, the special processor512to518should also have a means of protecting/isolating the data and processing of one “call” from that of other “calls”. This can be done via standard memory management mechanisms for example or via the Secure Object mechanisms discussed in previous applications.

A Secure Object can limit the amount of private information that it exposes to a special processor512to518by passing length information along with the address(es) of arguments. Trusted firmware on the special processor512to518can make sure that the function “called” on the special processor512to518only sees the data that it's supposed to see. In the second example embodiment above, the firmware can do this by appropriately configuring access control mechanisms on the special processor512to518. In the first example embodiment above, the trusted firmware can decrypt the appropriate block or blocks in system memory and then pass on to the called function just those bytes that were specified in the “call”.

The trusted firmware on a special processor512to518can be “built-in”, e.g. in a ROM (Read-Only Memory) on the special processor512to518. Alternatively, a TPM (Trusted Platform Module defined by the Trusted Computing Group) can be used to securely boot the Special Processor512to518with trusted firmware via techniques that are well known in the industry. The Secure Boot process guarantees that appropriate firmware and data are loaded into the Special Processor512to518. The data that is loaded can include public keys and/or digital certificates that the Secure Processor can use to authenticate other entities such as the CPU510in a heterogeneous system500or600. Since the TPM can also “seal” secrets to a trusted state, the Secure Boot process can also provide the Secure Processor with secrets, such as a private key that the Secure Processor can use to prove its identity to other entities such as the CPU510. The public keys or digital certificates and the private key can be used to establish a secure channel that the CPU510and the Special Processor512to518can use at run-time to securely communicate sensitive information such as the encryption keys, integrity roots and Secure Object IDs discussed above.

Other kinds of information can also be loaded into a Special Processor512to518such as the microcode that might be used for computing digital signatures on a special-purpose RSA (Rivest Shamir Adleman) public key crypto engine, the programming for an FPGA, or the connectivity, weights and thresholds of an ANN (artificial neural network) model etc.

This “functionality” can be loaded into a Special Processor512to518at system boot using standard techniques such as the ‘Trusted Boot’ or ‘Secure Boot’ procedures defined by the Trusted Computing Group. Functionality can also be loaded at run-time via a “call” from a Secure Object or from an ordinary application on the CPU510. In this case the “call” would specify the address(es) and length(s) of information in system memory that should be loaded into the Special Processor512to518and firmware on the Special Processor512to518would then load this information into the Special Processor512to518. Subsequent calls from the Secure Object or ordinary application could then make use of the functionality loaded into the Special Processor512to518to process other data. This allows a Secure Object to load and use sensitive functionality on a special processor, such as sensitive ANN models, as well as sensitive data, while protecting both the functionality and the data from other software.

FIG.7illustrates an example method of the system500and600(with reference toFIGS.5and6). A method for securing a Secure Object on a heterogeneous data processing system500or600comprising a plurality of different types of processors wherein different portions of a Secure Object may run on different types of processors includes: Building a Secure Object for a Heterogeneous System (in step702), Beginning execution of the Secure Object on a first processor such as CPU510(step704) then, depending on application requirements, the Secure Object may make an inter-processor function call to a second processor (e.g. specialized processor512-518) passing information to be processed to the second processor via the inter-processor function call (step706).

Then the second processor performs the requested processing (step708) and performs an inter-processor function return, returning information as appropriate to the Secure Object on the first processor (step710). The Secure Object then resumes execution on the first processor (step712).

The special call can include an indication of the second processor (specialized processor512to518) that is being called, an indication of the specific function that is being requested and the data that should be processed. The call can include a crypto key and an integrity value for the Secure Object in the first embodiment illustrated inFIG.5. The call can include a Secure Object ID in the second embodiment illustrated inFIG.6. The data processing system can be an artificial intelligence system. The second type of processor can be a specialized processor such as a GPU or a TPU, or other specialized processors512to518. Other alternatives or changes can be made in the steps700of the systems500or600.

Another Exemplary Hardware Implementation

FIG.8illustrates another hardware configuration of an information handling/computer system1100in accordance with the invention and which preferably has at least one processor or central processing unit (CPU)1110that can implement the techniques of the invention in a form of a software program.

The CPUs1110are interconnected via a system bus1112to a random access memory (RAM)1114, read-only memory (ROM)1116, input/output (I/O) adapter1118(for connecting peripheral devices such as disk units1121and tape drives1140to the bus1112), user interface adapter1122(for connecting a keyboard1124, mouse1126, speaker1128, microphone1132, and/or other user interface device to the bus1112), a communication adapter1134for connecting an information handling system to a data processing network, the Internet, an Intranet, a personal area network (PAN), etc., and a display adapter1136for connecting the bus1112to a display device1138and/or printer1139(e.g., a digital printer or the like).

In addition to the hardware/software environment described above, a different aspect of the invention includes a computer-implemented method for performing the above method. As an example, this method may be implemented in the particular environment discussed above.

Thus, this aspect of the present invention is directed to a programmed product, comprising signal-bearing storage media tangibly embodying a program of machine-readable instructions executable by a digital data processor incorporating the CPU1110and hardware above, to perform the method of the invention.

This signal-bearing storage media may include, for example, a RAM contained within the CPU1110, as represented by the fast-access storage for example.

Alternatively, the instructions may be contained in another signal-bearing storage media1200, such as a magnetic data storage diskette1210or optical storage diskette1220(FIG.9), directly or indirectly accessible by the CPU1110.

Whether contained in the diskette1210, the optical disk1220, the computer/CPU1110, or elsewhere, the instructions may be stored on a variety of machine-readable data storage media, such as DASD storage (e.g., a conventional “hard drive” or a RAID array), magnetic tape, electronic read-only memory (e.g., ROM, EPROM, or EEPROM), an optical storage device (e.g. CD-ROM, WORM, DVD, digital optical tape, etc.), paper “punch” cards, or other suitable signal-bearing storage media, including memory devices in transmission media, such as communication links and wireless devices, and in various formats, such as digital and analog formats. In an illustrative embodiment of the invention, the machine-readable instructions may comprise software object code.

These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.