Abstract:
In one embodiment, the invention is a method and apparatus for secure and reliable computing. One embodiment of an end-to-end security system for protecting a computing system includes a processor interface coupled to at least one of an application processor and an accelerator of the computing system, for receiving requests from the at least one of the application processor and the accelerator, a security processor integrating at least one embedded storage unit and connected to the processor interface with a tightly coupled memory unit for performing at least one of: authenticating, managing, monitoring, and processing the requests, and a data interface for communicating with a display, a network, and at least one embedded storage unit for securely holding at least one of data and programs used by the at least one of the application processor and the accelerator.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is a continuation of co-pending U.S. patent application Ser. No. 12/621,570, filed Nov. 19, 2009, which in turn claims the benefit of U.S. Provisional Patent Application Ser. No. 61/169,475, filed Apr. 15, 2009. Both of these applications are herein incorporated by reference in their entireties. 
     
    
     BACKGROUND OF THE INVENTION 
       [0002]    The present invention relates generally to self-managed and self-healing computing environments, and relates more specifically to systems for providing end-to-end tolerance to field functional fails, virus attacks, spyware, and intrusions. 
         [0003]      FIG. 1  is a schematic diagram illustrating an exemplary computing environment  100 . As illustrated, the computing environment  100  comprises a plurality of connected subsystems  102 ,  104 , and  106 . 
         [0004]    Specifically, the first subsystem  102  comprises a plurality of endpoints  108   1 - 108   n  (hereinafter collectively referred to as “endpoints  108 ”), such as user devices. For instance, the endpoints  108  may include personal computers, telephones, mobile devices (e.g., cellular telephones, personal digital assistants, etc.), gaming consoles, navigation systems, workstations, and the like. Endpoints are typically protected by systems that focus on system access validation, such as systems relying on encryption. 
         [0005]    The second subsystem  104  comprises a communication network, where the network may include, for example, a plurality of interconnected nodes  110   1 - 110   n  (hereinafter collectively referred to as “nodes  110 ”). The channels connecting the nodes  110  are typically protected by communications security standards such as Internet Protocol Security (IPSec), Secure Sockets Layer (SSL), or High Assurance Internet Protocol Encryptor (HAIPE). 
         [0006]    The third subsystem  106  comprises a plurality of data centers  112   1 - 112   n  (hereinafter collectively referred to as “data centers  112 ”). The data centers  112  are typically protected by a combination of hardware and software security. 
         [0007]    Any of the subsystems  102 ,  104 , and  106  is susceptible to functional fails, virus attacks, spyware, and intrusions, among other security and reliability issues. Conventional means for securing these subsystems  102 ,  104 , and  106 , however, focus on the individual subsystems  102 ,  104 , and  106  and do not provide end-to-end security for the computing environment  100  as a whole. 
         [0008]    Thus, there is a need in the art for a method and apparatus for secure and reliable computing in an end-to-end manner. 
       SUMMARY OF THE INVENTION 
       [0009]    In one embodiment, the invention is a method and apparatus for secure and reliable computing. One embodiment of an end-to-end security system for protecting a computing system includes a processor interface coupled to at least one of an application processor and an accelerator of the computing system, for receiving requests from the at least one of the application processor and the accelerator, a security processor integrating at least one embedded storage unit and connected to the processor interface with a tightly coupled memory unit for performing at least one of: authenticating, managing, monitoring, and processing the requests, and a data interface for communicating with a display, a network, and at least one embedded storage unit for securely holding at least one of data and programs used by the at least one of the application processor and the accelerator 
         [0010]    In another embodiment, a method for processing a request made by a user of a computing system, the request comprising a request to load an application, run an application, load an operating system, configure an operating system, run an operating system, or access a hardware resource, includes receiving the request from the user, authenticating the request in accordance with at least one of a user access profile representing one or more normal patterns of use by the user, an application authentication profile representing normal behavior of an application associated with the requests, or a registered owner trace representing who created the application, granting the request if the request is authenticated, blocking the request if the request is not authenticated, and performing recovery operations if the request is confirmed to be a thread. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0011]    So that the manner in which the above recited features of the present invention can be understood in detail, a more particular description of the invention may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments. 
           [0012]      FIG. 1  is a schematic diagram illustrating an exemplary computing environment; 
           [0013]      FIG. 2  is a schematic diagram illustrating one embodiment of a security system for providing secure computing, according to the present invention; 
           [0014]      FIG. 3  is a flow diagram illustrating one embodiment of a method for booting an end-to-end security system, according to the present invention; 
           [0015]      FIG. 4  is a flow diagram illustrating one embodiment of a method for enabling end-to-end security, according to the present invention; and 
           [0016]      FIG. 5  is a high level block diagram of the present computing system security method that is implemented using a general or special purpose computing device. 
       
    
    
     DETAILED DESCRIPTION 
       [0017]    In one embodiment, the present invention is a method and apparatus for secure and reliable computing. Embodiments of the invention may be implemented in a variety of computing environment subsystems that use shared or distributed memory to run applications. Specifically, embodiments of the invention use a combination of hardware and software that recognize legitimate user requests and resource utilization trends, making it possible to detect functional fails, virus attacks, spyware, and intrusions among other security and reliability issues. This enables the protection of substantially all computing environment resources, even after authentication. 
         [0018]      FIG. 2  is a schematic diagram illustrating one embodiment of a security system  200  for providing secure computing, according to the present invention. In one embodiment, the security system is a secure virtualized memory management server (VMMS). The end-to-end security system  200  serves two major purposes: (1) to prevent attacks on the computing system  204  that it is designed to protect; and (2) to restore the computing system&#39;s configuration if an attack succeeds in part. As illustrated, the end-to-end security system  200  is integrated in a customizable computing system  204 . In one embodiment, the computing system  204  is the customized component of any of the computing environment subsystems  102 ,  104 , or  106  illustrated in  FIG. 1 . 
         [0019]    As illustrated, the computing system  204  is connected, via a network  206  such as the Internet, to a technical support location  208  and to a network-attached storage (NAS)  212  that stores data and application codes required by the computing system&#39;s software stacks (discussed in greater detail below). The technical support location  208  provides remote services for ensuring the reliability and security of the computing system  204 . To that end, the technical support location  208  is further connected to a trusted database  210  in which snapshots of configurations for the computing system  204  are stored. These snapshots may be used to securely and remotely restore the computing system configuration in the event that the computing system  204  is the victim of a partially successful attack. 
         [0020]    The computing system  204  comprises one or more application processor cores  214  (i.e., where applications run) and one or more accelerator cores  216  that are in communication with the integral security system  200 . In one embodiment, the computing system  204  further comprises a network or display interface in communication with the application processor cores  214  and accelerator cores  216 . In addition, the computing system  204  comprises a remote software stack  218  (including online applications) and a local software stack  220  (including desktop applications) that are also in communication with the security system  200 . 
         [0021]    The end-to-end security system  200  as a whole operates as an interface between the application processor cores  214  and the computing environment  100 . To this end, the security system  200  comprises a processor interface  222  with integrated embedded storage units, a security processor  224  with integrated embedded storage units, a data interface  226  with integrated embedded storage units, and a tightly coupled memory (TCM) unit  228 . The processor interface  222  interfaces the security processor  224  to the application processor cores  214  and the accelerator cores  216 . In one embodiment, the processor interface  222  comprises an adaptive arbiter. Similarly, the data interface  226  interfaces the security processor  224  to the remote software stack  218  and the local software stack  220  and manages communications between the security processor  224  and memory devices and/or networked devices. In one embodiment, the data interface  226  comprises an adaptive cache. In a further embodiment, the adaptive cache is configured as a coherent input/output (I/O) cache for improved performance efficiency. In an alternative embodiment, the adaptive cache is configured as a tightly coupled memory for improved power efficiency. In one embodiment, the TCM unit  228  holds data relating to user access profiles (UAPs), application authentication profiles (AAPs), and registered owner traces (ROTS), as described in further detail below. 
         [0022]    The security processor  224  manages authentification and application/hardware/software access requests from the processor interface  222  based on pattern rules and attribute profiles. The security processor  224  is programmed to initiate network connections across a network (such as the Internet) to the trusted database  210  or to another customized computing system that integrates the disclosed VMMS and that is part of the computing environment  100 . The security processor  224  is illustrated in cutaway and comprises an instruction cache  228 , a decoder  230 , a plurality of specialized execute units  232 , a data cache  234 , a secure boot loader  236 , secure data  238 , and a MMU  240 . In one embodiment, the secure boot loader  236  and secure data  238  are embedded non-volatile storage units that store a security program and profile data used by the security program, respectively. In one embodiment, the security processor  224  operates as a profile-based application layer firewall, as discussed in greater detail below 
         [0023]      FIG. 3  is a flow diagram illustrating one embodiment of a method  300  for configuring an end-to-end security system, according to the present invention. The method  300  may be implemented, for example, by the security system  200  of  FIG. 2  to enable end-to-end security of the computing system  204 . 
         [0024]    The method  300  is initialized at step  302  and proceeds to step  304 , where the security system determines whether to configure the end-to-end security system over a network connection (e.g., a connection to the network  206  of  FIG. 2 ). If the security system concludes in step  304  that it will configure the end-to-end security system over a network connection, the method  300  proceeds to step  306 , where the security system runs a security program from a remote software stack (e.g., remote software stack  218  of  FIG. 2 ). Alternatively, if the security system concludes in step  304  that it will not configure the end-to-end security system over a network connection, the method  300  proceeds to step  308 , where the security system runs a security program from a local software stack (e.g., local software stack  220  of  FIG. 2 ). 
         [0025]    Once the computing system has been booted from the remote software stack or the local software stack, the method  300  proceeds to step  310 , where the security system runs a health check of the computing system being protected. When running the health check, the security system generates a health report that identifies the current state of the computing system and takes a snapshot of the current system configuration. 
         [0026]    In step  312 , the security system stores the health report and system configuration snapshot in a remote trusted database (e.g., trusted database  210  of  FIG. 2 ). The security system then enables end-to-end security in step  314 . In one embodiment, the end-to-end security is enabled via the security processor (e.g., security processor  224  of  FIG. 2 ). The method  300  then terminates in step  316 . 
         [0027]    As discussed above, in one embodiment, end-to-end security is enabled via a profile-based application layer firewall. The firewall detects specific patterns outside of a normal profile, for example by applying a clustering scheme or an outlier detection algorithm. Any activity that deviates from the normal profile is tagged by the firewall as suspicious. 
         [0028]      FIG. 4  is a flow diagram illustrating one embodiment of a method  400  for enabling end-to-end security, according to the present invention. The method  400  may be implemented, for example, at the security system  224  of  FIG. 2 . 
         [0029]    The method  400  is initialized at step  302  and proceeds to step  304 , where the processor interface (e.g., processor interface  222  of  FIG. 2 ) receives a request (e.g., from a processor core  214 ) to load or run an application on the associated computing system from memory and/or to access hardware resources. The request, also referred to as a “virtual service request” or VSR, may be authorized or unauthorized; it is up to the security processor to make that determination as discussed further below. 
         [0030]    In step  406 , the security processor authenticates (validates and/or encrypts) the requested application. In one embodiment, the security processor authenticates a VSR by examining an AAP associated with the application. The AAP comprises attributes of the application that represent normal operations and/or request patterns for the application (e.g., the way the application requests resources, how the application runs, etc.). For instance, the AAP may be compiled based on one or more of: a user profile, typical request trends, request rates, and total memory size to be shared. In one embodiment, the AAP is stored in memory in the security processor (e.g., in the secure data flash memory  238  or the TCM unit  228 ). 
         [0031]    In step  408 , the security processor determines how “safe” the request is (e.g., whether the requested transaction is traceable). In one embodiment, this determination is made in accordance with at least one of: the AAP, an ROT, and a UAP that comprise attributes reflecting normal patterns of use by the user of the computing system. In further embodiments, the determination also considers a rate of requests per user and/or virus/intrusion signatures. In one embodiment, the determination is made using at least one of fuzzy logic, machine learning, or probabilistic reasoning (e.g., prior probability, distance delta covariance, or entropy-based rules). In one embodiment, an ROT is based on a public/private key derivative and indicates who created the requested application. In one embodiment, the UAP indicates who is requesting/running the application now and is based on at least one of: user login habits, user application requests, user fingerprint(s), digitized user voice segments, and a segmented image of the user. In one embodiment, the ROT and the UAP are stored in memory in the security processor (e.g., in the secure data flash memory  238  or the TCM unit  228 ). 
         [0032]    If the security processor concludes in step  408  that the requested transaction is not traceable, the method  400  proceeds to step  410 , where the security processor blocks the request before the method  400  returns to step  404  for processing of a next request. The method  400  then proceeds to step  420 , where the security processor determines whether a thread or incident has been detected. If the security processor concludes in step  420  that a thread or incident has been detected, the security processor performs recovery operations in step  422 . Alternatively, if the security processor concludes in step  420  that a thread or incident has not been detected, the method  400  returns to step  404  for processing of a next request. 
         [0033]    Alternatively, if the security processor concludes in step  408  that the requested transaction is traceable, the method  400  proceeds to step  411 , where the security processor optimizes the allocation of the adaptive arbiter (e.g., of the processor interface  216 ). This minimizes the bandwidth and throughput impact resulting from operations of the security system. 
         [0034]    In step  412 , the security processor fulfills the requested transaction while activating a pattern recognition algorithm (e.g., a least square support vector machine model). The pattern recognition algorithm operates while the requested application is running and monitors the behavior of the application against patterns representing normal behavior of the application. In one embodiment, the patterns are stored in memory in the security processor (e.g., in the secure data flash memory  238  or the TCM unit  228 ). In one embodiment, the requested transaction is not fulfilled and the pattern recognition is not activated until a final assessment is made based on the available bandwidth and the power of the computing system to update the AAP. 
         [0035]    In step  414 , the security processor optimizes allocation of the adaptive cache (e.g., of the data interface  226 ). This makes the security system substantially transparent to the normal operation of the application now running on the computing system. This in turn minimizes overhead and performance impact resulting from operation of the security system. In one embodiment, optimization is performed in accordance with system performance and power efficiency rules stored in memory in the security processor (e.g., in the secure data flash memory  238  or the TCM unit  228 ). Once the adaptive cache has been optimized, the security processor processes the current request in step  416 . 
         [0036]    In step  418 , the security processor checks to see if there are any other requests remaining to be processed. If the security processor concludes in step  418  that there is at least one request remaining to be processed, the method  400  returns to step  404  for processing of the next request. Alternatively, if the security processor concludes in step  418  that there are no requests remaining to be processed, the method  400  terminates in step  424 . 
         [0037]    It should be noted that a request receives by the security system could also be blocked during monitoring of the running application (i.e., while the pattern recognition algorithm is activated). For instance, if a pattern of use is detected in the running application that deviates from the normal patterns of use, the security processor may block the application at such a time. 
         [0038]      FIG. 5  is a high level block diagram of the present computing system end-to-end security method that is implemented using a general or special purpose computing device  500 . In one embodiment, a general purpose computing device  500  comprises an embedded storage (e.g., non-volatile static random memory) a processor  502 , a memory  504 , a security module  505  and various input/output (I/O) devices  506  such as a display, a keyboard, a mouse, an imaging device, a global positioning system, a modem, a microphone, a speaker, a network connection and the like. In one embodiment, at least one I/O device is a network device (e.g., a storage area network, a network attached storage, a disk drive, flash memory, an optical disk drive, a floppy disk drive). It should be understood that the security module  505  can be implemented as a physical device or subsystem that is coupled to a processor through a communication channel. 
         [0039]    Alternatively, the security module  505  can be represented by one or more software applications (or even a combination of software and hardware, e.g., using Application-Specific Integrated Circuits (ASIC)), where the software is loaded from an embedded storage  501  and/or an I/O device (e.g., network devices  506 ) and operated by the processor  502  from the memory  504  of the general or special purpose computing device  500 . Additionally, the software may run in a distributed or partitioned fashion on two or more computing devices similar to the general purpose computing device  500 . Thus, in one embodiment, the security module  505  for enabling end-to-end security in a computing environment described herein with reference to the preceding figures can be stored on a computer readable medium or carrier (e.g., RAM, magnetic or optical drive or diskette, and the like). 
         [0040]    It should be noted that although not explicitly specified, one or more steps of the methods described herein may include a storing, displaying and/or outputting step as required for a particular application. In other words, any data, records, fields, and/or intermediate results discussed in the methods can be stored, displayed, and/or outputted to another device as required for a particular application. Furthermore, steps or blocks in the accompanying Figures that recite a determining operation or involve a decision, do not necessarily require that both branches of the determining operation be practiced. In other words, one of the branches of the determining operation can be deemed as an optional step. 
         [0041]    While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. Various embodiments presented herein, or portions thereof, may be combined to create further embodiments, such as configuring the operating system software to run on the security processor  224  of  FIG. 2  instead of on the processor core  216  for improved performance and energy efficiency. Furthermore, terms such as top, side, bottom, front, back, and the like are relative or positional terms and are used with respect to the exemplary embodiments illustrated in the figures, and as such these terms may be interchangeable.