Abstract:
Example embodiments of the present invention relate to a system, apparatus and methods for preserving the integrity of a code to prevent it from being modified, maliciously or inadvertently, while it is in execution in the RAM of a computer platform. This method also may be referred to as code hardening. Code to be hardened in example embodiments of the present invention may be referred to as protected code. Example embodiments of the present invention are able to externally detect unauthorized stoppage of the hypervisor by employing (1) a launch-time metric of the protected code; (2) a run-time metric of the protected code; and (3) a liveliness indicator of the protected code.

Description:
[0001]    A portion of the disclosure of this patent document may contain command formats and other computer language listings, all of which are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. 
       CLAIM OF PRIORITY 
       [0002]    This application claims priority from China application number 201010601493.6 filed on Dec. 23, 2010. 
       TECHNICAL FIELD 
       [0003]    This application relates to validating integrity of executed protected code in memory of a computer platform. 
       BACKGROUND 
       [0004]    A hypervisor (i.e., a Virtual Machine Monitor) manages the sharing of a hardware platform among multiple guest systems and generally is adopted as privileged software in Infrastructure as a Service (IaaS) in cloud computing. Hypervisors have a relatively small code base and limited interaction with the external world and, therefore, were assumed to be well-protected and easily verifiable. 
       SUMMARY 
       [0005]    Example embodiments of the present invention relate to a method and apparatus for validating integrity of executed protected code in memory of a computer platform. The method includes receiving a launch-time metric of stored protected code from the computer platform, obtaining a run-time metric of the executed protected code from the computer platform, and obtaining a liveliness indicator of the executed protected code from the computer platform. The integrity of the executed protected code is then validated according to the launch-time metric, the run-time metric and the liveliness indicator. 
         [0006]    Other example embodiments relate to a method and apparatus for validating integrity of executed protected code in memory with an external verifier by providing a launch-time metric of stored protected code to the external verifier, a run-time metric of executed protected code to the external verifier in response to a request for the run-time metric from the external verifier, and a liveliness indicator of the executed protected code to the external verifier in response to a request for the liveliness indicator from the external verifier, the request for the liveliness indicator sent from the external verifier if comparing the launch-time metric and the run-time metric at the external verifier succeeds. 
         [0007]    Example embodiments of the present invention also include a system and a computer program product for carrying out method steps. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0008]    The above and further advantages of the present invention may be better under stood by referring to the following description taken into conjunction with the accompanying drawings in which: 
           [0009]      FIG. 1  is a diagram illustrating an example environment in which example embodiments of the present invention maybe employed; 
           [0010]      FIG. 2  is a block diagram illustrating an example embodiment system and apparatus of the present invention for validating integrity of protected code in execution in memory of a computer platform; 
           [0011]      FIGS. 3A-3B  are a flow diagram illustrating an example embodiment method of the present invention performed at a computer platform for validating integrity of executed protected code in memory with an external verifier; 
           [0012]      FIGS. 4A-4B  are a flow diagram illustrating an example embodiment method of the present invention performed at an external verifier for validating integrity of executed protected code in memory of a computer platform; and 
           [0013]      FIG. 5  is diagram illustrating an example embodiment method of the present invention embodied as program code or a program product. 
       
    
    
     DETAILED DESCRIPTION 
       [0014]    Hypervisors are not completely secure and are vulnerable to many attacks, such as hypervisor code and data being modified at runtime. Hypervisors face similar integrity threats as conventional operating systems so they require protection, measurement and verification of their integrity. Verifying the integrity of the hypervisor at system boot may be accomplished through conventional techniques such as a trusted boot. Likewise, conventional techniques for verifying the integrity of the hypervisor at runtime have been developed. However, such conventional techniques do not verify the integrity of the hypervisor while in execution in random access memory (RAM) of a computer platform. For example, such conventional techniques only protect the software version and cannot prevent the time-of-check-to-time-of-use (TOC2TOU) attack. In the TOC2TOU attack, the integrity of code may be compromised during an attack window from the time the integrity of the code is checked to the time the code is used. In many cases, the attack window can be an extended period. 
         [0015]    Further, such conventional techniques are not suitable for use in a datacenter in which servers may be network booted. Network booting is the process of booting a computer from a network rather than a local drive. Without verification of the network boot source, integrity of the network boot source cannot reliably be assumed and, therefore, all booted servers may not be trusted. 
         [0016]      FIG. 1  is a diagram illustrating an example environment  100  in which example embodiments of the present invention maybe employed. The environment  100  may be a cloud computing environment for Infrastructure as a Server (IaaS). The environment  100  includes a plurality of servers  110 - 1 - 110 -N ( 110 , generally) and a plurality of clients  120 - 1 - 120 -N ( 120 , generally) connected over a network  130 , such as the Internet. Each server  110  may be a computer platform running a hypervisor (i.e., a Virtual Machine Monitor) that manages the sharing of the hardware platform among multiple guest systems (e.g., clients  120 ). 
         [0017]    In certain scenarios it may be desirable to perform automatic load balancing of a plurality of processes between the servers  110  (i.e., hypervisors in a preferred embodiment) for virtual machines supporting the plurality of clients  120 . The inventors have critically recognized that virtual machines may not be distributed evenly or advantageously across a plurality of hypervisors. Because of this, it is desirable to adjust the utilization of the hypervisors to more-efficiently balance the load of running hypervisors and virtual machines. Hypervisors are not completely secure and are vulnerable to many attacks, such as hypervisor code and data being modified at runtime. Therefore, before transferring the process of a virtual machine from one server to another and, likewise, from one hypervisor managing the virtual machine to another, it is advantageous to verify the status of the hypervisor and that its servicing conditions have not changed since the hypervisor started running. 
         [0018]      FIG. 2  is a block diagram illustrating an example embodiment system  200  of the present invention for validating integrity of protected code in execution in memory of a computer platform. The system  200  includes a computer platform  210  and an external verifier  245  connected over a network  205 , such as the Internet. 
         [0019]    The computer platform  210  may include open-architecture computing hardware (e.g., Intel X86 architecture) and software components. The computer platform  210  includes storage  215  for storing stored protected code  217  and memory  220 , for storing executed protected code  222  and program logic  223  for validating integrity of executed protected code  222  in memory  220  with an external verifier  245 , and a processor  225  for loading the stored protected code  217  into memory  220  and executing the executed protected code  222  and the program logic  223 . 
         [0020]    The computer platform  210  also includes a launch-time unit  230 , a run-time unit  235  and a liveliness unit  240 . The external verifier  245  includes a comparator unit  250  and a verification unit  255 . 
         [0021]    The launch-time unit  230  may be a trusted mechanism that includes a physically protected environment, such as Trusted Computing Group (TCG) technology or Trusted Execution Technology (TXT). At the launch time of the computer platform  210 , the launch-time unit  230  measures the stored protected code  217 . The measured result is referred to as a launch-time metric  232  and may be a hash of the stored protected code  217  stored in the storage  215 . The launch-time unit  230  securely stores the launch-time metric  232  at the launch-time unit  230  for future attestation. In alternative embodiments, such as network boot servers, the launch-time metric  232  may be stored in physically secured network storage, such as in a Storage Area Network (SAN) (not shown). 
         [0022]    The run-time unit  235  may be a trusted mechanism that includes a physically protected environment, such as a Direct Memory Access—(DMA) capable device with on-device information integrity protection capabilities. The run-time unit  235  can read the content of locations in the memory  220  after the computer platform  210  has launched. At the run time of the executed protected code  222 , the run-time unit  235  reads the location in memory  220  storing the executed protected code  222  and measures the executed protected code  222  in response to an authorized instruction. The measured result is referred to as a run-time metric  237  and may be a hash of the executed protected code  222  stored in the memory  220 . 
         [0023]    The authorized instruction causing the run-time unit  235  to measure the executed protected code  222  and generate the run-time metric  237  may be a request for the run-time metric  252  sent by the comparator unit  250  of the external verifier  245 . The comparator unit  250  is also configured to compare the launch-time metric  232  and the run-time metric  237  to determine whether the integrity of the stored protected code  217  was compromised at a time between the launch of the computer platform  210  and the runtime of the executed protected code  222 . 
         [0024]    The liveliness unit  240  manages a liveliness protocol mechanism between the computer platform  210  and the external verifier  245 , such as the RSA SecureID® from RSA, The Security Division of EMC of Bedford, Mass., in a preferred embodiment. The liveliness unit  240  is initialized in such a manner that the computer platform  210  and the external verifier  245  share a secret, such as an initialization seed  242  (i.e., token). The shared secret is coded into a one-way function together with a reliable event, such as a time value, which is reliably known to both the computer platform  210  and the external verifier  245 . At any time when the executed protected code  222  is in execution, the computer platform  210  may be requested by the external verifier  245  to generate a liveliness indicator  243  according to the liveliness protocol to detect whether the executed protected code  222  is in a liveliness synchronization with the mutually known reliable event (i.e., the executed protected code  222  has not been stopped or altered). 
         [0025]    A comparator unit  250  of the external verifier  245  receives the launch-time metric  232  and receives the run-time metric  237  from the computer platform  210  in response to sending a request for the run-time metric  252  to the computer platform  210 . The comparator unit  250  also compares the launch-time metric  232  and the run-time metric  237  and determines whether the launch-time metric  232  and the run-time metric  237  match. A verification unit  255  of the external verifier  245  may send a request for a liveliness indicator  257 . The verification unit  255  is also configured to receive the initialization seed  242  sent by the liveliness unit  240  and the liveliness indicator  243  sent by the liveliness unit  240  and determine whether the liveliness indicator  243  conforms to the liveliness protocol instituted by the one-way function into which the initialization seed  242  is coded. The external verifier  245  also includes memory  260  for storing program logic  262 , for validating integrity of executed protected code  222  in memory  220  of the computer platform  210 , and a processor  265  for executing the program logic  262 . 
         [0026]    When the program logic  223 ,  262  is loaded into memory  220 ,  226  and executed by a machine (e.g., computer platform  210  or external verifier  245 ) the machine becomes an apparatus for practicing the invention. When implemented on one or more general-purpose processors (e.g., processors  225  and  265 , respectively), the program logic  223 ,  262  combines with such a processor to provide a unique apparatus that operates analogously to specific logic circuits. As such, a general purpose digital machine can be transformed into a special purpose digital machine. Further, the processors  225 ,  265  running the program logic  223 ,  262  enable a new computer process for performing example embodiments of the present invention. 
         [0027]      FIGS. 3A-3B  and  4 A- 4 B are flow diagrams illustrating example embodiment methods of the present invention performed at a computer platform (e.g., computer platform  210  of  FIG. 2 ) and an external verifier (e.g., external verifier  245  of  FIG. 2 ), respectively.  FIGS. 3A-3B  and  4 A- 4 B will be described together, with concurrent references being made to elements in both  FIG. 3A  and  FIG. 4A  and, likewise,  FIG. 3B  and  FIG. 4B , to illustrate, for example, the interaction between the method performed at the computer platform  210  (i.e.,  FIGS. 3A-3B ) and the method performed at the external verifier  245  (i.e.,  FIGS. 4A-4B ). Reference also will be made to elements in  FIG. 2  to illustrate, for example, communications  222 ,  242 ,  262 ,  263 ,  252 ,  297  made between the computer platform  210  and the external verifier  245  in an example embodiment system  200  for validating integrity of executed protected code  222  in memory  220  of the computer platform  210 . 
         [0028]    At the launch time of the computer platform  210 , the launch-time unit  230  measures the stored protected code  217  ( 300 ). The measured result is referred to as a launch-time metric  232  and may be a hash of the stored protected code  217 . The launch-time unit  230  securely stores the launch-time metric  232  at the launch-time unit  230  for future attestation. The launch-time unit  230  also sends the launch-time metric  232  to the external verifier  245  ( 305 ). The liveliness unit  240  then sends an initialization seed  242  to the external verifier  245  ( 310 ) and initializes a liveliness protocol at the computer platform  210  ( 315 ). 
         [0029]    The external verifier  245  receives the launch-time metric  232  from the computer platform  210  ( 405 ). The external verifier  245  also receives the initialization seed  242  from the computer platform  210  ( 410 ) and initializes the liveliness protocol at the external verifier  245  ( 415 ). Thus, the liveliness protocols at the computer platform  210  and the external verifier  245  are initialized in such a manner that the computer platform  210  and the external verifier  245  share a secret, such as the initialization seed  242  (i.e., token). As will be described further below, the shared secret may be coded into a one-way function together with a reliable event, such as a time value, which is reliably known to both the computer platform  210  and the external verifier  245 . 
         [0030]    The stored protected code  217  may reside in the storage  215  of the computer platform  210  for a period of time before it is executed. Thus, the computer platform  210  determines whether the stored protected code  217  is has been run ( 320 ). If the stored protected code  217  has not been run ( 322 ) then the computer platform  210  continues to wait. 
         [0031]    However, if the stored protect code  217  has been run ( 323 ), the method continues to wait for a request for a run-time metric  252  to be sent from the external verifier ( 425 ). When the computer platform  210  receives the request for the run-time metric  252  from the external verifier  245  ( 325 ), the run-time unit  235  reads the content of the location in the memory  220  storing the executed protected code  222  and measures the executed protected code  222  ( 330 ) as the run-time metric  237 . The run-time unit  235  then sends the run-time metric  237  to the external verifier  245  ( 335 ). The run-time metric  237  may be a hash of the executed protected code  222 . 
         [0032]    The comparator unit  250  then receives the run-time metric  237  from the computer platform  210  ( 435 ) and determines whether the launch-time metric  232  and the run-time metric  237  match ( 440 ). If the launch-time metric  232  and the run-time metric  237  do not match ( 442 ), the comparator unit  250  reports an alarm and halts ( 475 ). For example, the reported alarm may be reviewed by an operator of the external verifier  245 , or a management server (not shown) to which the external verifier  245  reports the alarm, to check the status of the computer platform  210 . However, if the launch-time metric  232  and the run-time metric  237  do match ( 443 ), the external verifier  245  continues to validate the integrity of the executed protected code  222  at a later time ( 445 ), as described below. 
         [0033]    At any time when the executed protected code  222  is in execution at the computer platform  210 , the external verifier  245  can determine that it should validate the integrity of the executed protected code  222  at the computer platform  210  ( 440 ). If validation is not necessary ( 447 ), the external verifier  245  continues to wait for an indication that it should validate the integrity of the executed protected code  222 . For example, the external verifier  245  may define integrity validation rules, such as requiring the computer platform  210  to report the status of the protected code at an interval (e.g., five seconds). 
         [0034]    If the external verifier  245  determines that it should validate the integrity of the executed protected code  222  ( 448 ), the verification unit  255  sends a request for a liveliness indicator  257  from the computer platform  210  ( 450 ), generated by the liveliness unit  240  according to the liveliness protocol, to detect whether the executed protected code  222  is in a liveliness synchronization with the mutually known reliable event (i.e., the executed protected code  222  has not been stopped). Therefore, the computer platform  210  determines whether it has received a request for a liveliness indicator  257  ( 350 ). 
         [0035]    If a request for a liveliness indicator  257  has not been received ( 352 ), then the computer platform  210  continues to wait. However, if a request for a liveliness indicator  257  has been received ( 353 ), the liveliness unit  240  calculates the requested liveliness indicator  243  ( 355 ) and sends the requested liveliness indicator  243  to the external verifier  245  ( 355 ). 
         [0036]    The verification unit  255  then receives the liveliness indicator  243  from the computer platform  210  ( 460 ) and examines the liveliness indicator  243  to determine whether the received liveliness indicator  243  conforms to the liveliness protocol ( 465 ). As described above, the liveliness unit  240  was initialized in such a manner that the computer platform  210  and the external verifier  245  share a secret, such as the initialization seed  242  (i.e., token). Thus, the result of coding the shared secret in the one-way function together with the reliable event at the computer platform  210 , which was sent to the external verifier  245  as the liveliness indicator  243 , should correspond to the result of coding the shared secret in the one-way function together with the reliable event at the external verifier  245 . 
         [0037]    Therefore, if the received liveliness indicator  243  does not conform to the liveliness protocol ( 467 ), the verification unit  255  reports an alarm and halts ( 475 ). However, if the received liveliness indicator  243  does conform to the liveliness protocol ( 468 ), then the verification unit  255  reports a successful validation of the executed protected code  222  in memory  220  of the computer platform  210  and continues ( 470 ). For example, the external verifier  245  can wait for a further indication that it should validate the integrity of the protected code ( 445 ) or receive another run-time metric  237  ( 435 ) indicating that the executed protected code  222  has stopped and has been restarted. 
         [0038]    The methods and apparatus of this invention may take the form, at least partially, of program code (i.e., instructions) embodied in tangible non-transitory media, such as floppy diskettes, CD-ROMs, hard drives, random access or read only-memory, or any other machine-readable storage medium. 
         [0039]      FIG. 5  illustrates program logic  520  embodied on a computer-readable medium  510  as shown, and wherein the program logic  520  is encoded in computer-executable code configured for carrying out the method illustrated in  FIGS. 1-4  and thereby forming a computer program product  500 . 
         [0040]    The logic for carrying out the method may be embodied as part of the aforementioned system, which is useful for carrying out a method described with reference to embodiments shown in, for example,  FIGS. 1-4 . For purposes of illustrating the present invention, the invention is described as embodied in a specific configuration and using special logical arrangements, but one skilled in the art will appreciate that the device is not limited to the specific configuration but rather only by the claims included with this specification. 
         [0041]    Although the foregoing invention has been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. Accordingly, the present implementations are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims. 
         [0042]    In reading the above description, persons skilled in the art will realize that there are many apparent variations that can be applied to the methods and systems described. In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made to the specific exemplary embodiments without departing from the broader spirit and scope of the invention as set forth in the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.