Abstract:
A method, system and computer readable medium containing programming instructions for booting a computer system having a plurality of devices is disclosed. They include provisions for initiating a boot sequence in the computer system and determining whether a device of the plurality of devices is either a bootable device or a nonbootable device. If the device is a nonbootable device, a clean restart of the boot sequence is performed, wherein the nonbootable device is bypassed during the clean restart.

Description:
FIELD OF THE INVENTION  
         [0001]    The present invention relates generally to computer systems and, more particularly, to a method and system for a clean boot process.  
         BACKGROUND OF THE INVENTION  
         [0002]    With the advent of personal computer system use in every day personal and business affairs, the issue of computer security has become critical. To protect the information contained in the personal computer system, which in many cases may be highly sensitive and confidential, embedded security subsystems (“ESS”) have been developed.  
           [0003]    An ESS is typically a chip coupled to a processor in the computer. The ESS is independent from the computer&#39;s operating system, and therefore, is incorruptible from the operating system. The ESS is utilized generally according to the standards developed by the Trusted Computing Platform Alliance (TCPA), which is an open association of technology companies working to improve computer-platform security. The TCPA has developed an innovative trust model for computing platforms, including hardware capabilities, to make protections stronger.  
           [0004]    [0004]FIG. 1 is a block diagram of a computer system  10  utilizing an ESS  40  in accordance with the TCPA trust model. As is shown, the computer system  10  includes a processor  20  coupled to a BIOS  30  and an ESS  40 . The BIOS  30  typically performs a Power-on Self Test (POST) and ensures that hardware devices, such as a floppy drive  50  and hard drive  60 , are functional. Memory  70  is coupled to the BIOS  30  to store code loaded from the hardware devices during POST. The BIOS  30  includes a boot block  32  and a main BIOS  34 . The ESS  40  includes a plurality of protected control registers (PCRs)  42 , at least one  42   a  of which is dedicated to the booting process.  
           [0005]    In FIGS. 2A and 2B, a flowchart illustrating a conventional boot process  100  utilizing the ESS in accordance with the TCPA trust model is presented. The process  100  begins when the computer is reset in step  110 , e.g., the computer is powered-up. In step  112 , the PCR(s)  42   a  dedicated to the booting process is reset to zero. Before the code in the boot block  32  is executed, the code is hashed to produce a digest value, which is then extended to the PCR  42   a , via step  114 . Then, in step  116 , the code in the boot block  32  is run, which passes control over to the main BIOS  34 . Nevertheless, before executing the code in the main BIOS  34 , that code is also hashed and the value extended to the PCR  42   a  in step  118 . Then, in step  120 , the code in the main BIOS  34  is run.  
           [0006]    As with most typical boot processes, the BIOS  30  will perform a Power On Self Test (POST) for all of the different hardware components in the system to ensure each component is working properly. Thus, the BIOS  30  will determine which devices, e.g., floppy drive  50  and hard drive  60 , are bootable, list them in a boot table, and then initiate the boot sequence.  
           [0007]    Referring now to FIG. 2B, the process  100  continues at number B. Starting with a first device in the boot table, the BIOS  30  attempts to read the device (step  122 ) to determination whether the device is bootable (step  126 ). If the device is not bootable, then the boot table is incremented by one and the BIOS  30  attempts to read the next device (step  122 ). If the device appears to be bootable (step  126 ), then the BIOS  30  will hash code from the device and extend the value to the PCR  42   a  in step  126 . The BIOS  30  will then load the code and execute this code in step  128 ). At this point, the code in the device is now in control of the system. The device will then make a determination of whether it is bootable in step  130 . If the device code determines that it is not bootable, then it will return control back to the BIOS  30  by generating an interrupt signal, such as an interrupt  18   h , via stepl 32 . The BIOS  30  will increment to the next boot device in step  134 . If, on the other hand, the device code determines that the device is bootable (step  130 ), the device will boot an operating system, via step  136 .  
           [0008]    Once the operating system has been booted, the process  100  continues at number C. This part of the process, illustrated in FIG. 2C, verifies the trustworthiness of the boot sequence. The value(s) in the PCR(s)  42   a  is a reflection of the boot process from beginning to end. In step  142 , the value(s) in the PCR(s)  42   a  is compared to a predetermined value that reflects a trustworthy boot sequence. The predetermined value is typically calculated by the operating system.  
           [0009]    If the PCR  42   a  value is not equal to the predetermined value calculated by the operating system (step  144 ), the operating system will be required to initiate a security check in step  148  to examine the boot process to determine whether a security breach has occurred. Additional logic must be provided in the operating system to perform this check.  
           [0010]    If a device was determined by BIOS  30  to be bootable and the device ended up returning to BIOS  30  through the interrupt signal, then the PCR  42   a  value will differ from the predetermined value. Thus, while the boot process might be trustworthy, the operating system will nonetheless be required to initiate the security check. Moreover, because the code from a nonbootable device has been loaded from that device, there is a chance that destructive code from that device remains in system memory  70 , where it can potentially cause harm.  
           [0011]    Accordingly, a need exists for handling nonbootable devices identified during the boot process and for protecting the computer system without requiring additional logic in the operating system. The present invention addresses such a need.  
         SUMMARY OF THE INVENTION  
         [0012]    A present invention provides a method, system and computer readable medium containing programming instructions for booting a computer system having a plurality of devices. The method, system and computer readable medium include initiating a boot sequence in the computer system and determining whether a device of the plurality of devices is either a bootable device or a nonbootable device. If the device is a nonbootable device, a clean restart of the boot sequence is performed, wherein the nonbootable device is bypassed during the clean restart.  
           [0013]    Through the aspects of the present invention, if the BIOS is notified that a device is a nonbootable device, the BIOS will execute a clean restart of the entire boot process. The clean restart includes resetting the value in a PCR dedicated to the boot process to zero, and clearing system memory such that any code that might be stored from the nonbootable device is removed. During the clean restart, the BIOS will bypass the nonbootable device and proceed to attempt to boot other devices. Once the BIOS has booted to an operating system the value in the PCR should match a predetermined value known by the operating system because the BIOS will have performed a clean boot. If it does not, the operating system can conclude a nontrustworthy boot process, without the need for a security check and the associated logic therefor. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0014]    [0014]FIG. 1 illustrates a block diagram of a computer system that can be used in accordance with the preferred embodiment of the present invention.  
         [0015]    [0015]FIGS. 2A, 2B and  2 C illustrate a flowchart of a process for booting a computer system utilizing an ESS in accordance with a TCPA trusted model.  
         [0016]    [0016]FIGS. 3A, 3B and  3 C illustrate a flowchart of a process for booting the system in accordance with a preferred embodiment of the present invention. 
     
    
     DETAILED DESCRIPTION  
       [0017]    The present invention relates generally to computer systems and, more particularly, to a method and system for a clean boot process. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiment and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest scope consistent with the principles and features described herein.  
         [0018]    In accordance with the present invention, a clean and trustworthy boot process is performed by restarting the boot process whenever a device fails to boot, and bypassing that nonbootable device in the restarted boot process. By performing a clean restart and eventually booting only the boot device containing the operating system, the operating system need not be concerned with checking the trustworthiness of the nonbootable devices, thereby saving time and resources. In addition, during a clean restart, any code loaded and stored in memory from the nonbootable device is cleared, thereby eliminating a potential source of intrusion.  
         [0019]    [0019]FIGS. 3A, 3B and  3 C illustrate a process in accordance with a preferred embodiment of the present invention. Referring first to FIG. 3A, the process begins as before, e.g., with a computer reset (step  110 ′), resetting a value in a PCR  42   a  dedicated to the boot process to zero in step  112 ,′ hashing code in the boot block  32  and extending the value to the PCR  42   a  (step  114 ′), running the code in the boot block  32  to pass control to the main BIOS  34  (step  116 ′), hashing code in the main BIOS  34  and extending the value to the PCR  42   a  (step  118 ′), and running the code in the main BIOS  34  in step  120 .′ 
         [0020]    Referring now to FIG. 3B, as before, the BIOS attempts to boot the next boot device. If the device does not appear to be bootable (step  124 ′), then step  122 ′ is repeated whereby the BIOS  30  attempts to boot the next device in the boot table. If the device appears bootable, then the BIOS  30  will hash code from the device and extend the value to the boot PCR  42   a  in step  126 ′. The BIOS  30  will then load the code from the device and execute this code in step  128 ′. The operating system code loaded by the BIOS  30  then makes another determination as to whether the device is actually bootable in step  130 ′. If, the code is not bootable, then the operating system code will generate an interrupt signal, such as an interrupt  18   h , via step 132 ′. The interrupt signal will return control back to the BIOS  30  in step  134 ′. The BIOS  30  will then clear any code loaded into memory  70  (step  210 ), and set a flag indicating that the current device should be bypassed on a next boot, via step  220 . The BIOS  30  will then force a clean restart of the system in step  230 . At this point, steps  112 ′ to  130 ′ are repeated. During the clean restart, the BIOS  30  bypasses booting any device that has been flagged, and instead increments to the next bootable device in the boot table. Thus, steps  122 ′ to  130 ′ are performed on the next bootable device.  
         [0021]    Once the boot device has been booted, i.e., an operating system has been booted via step  138 ′, then the trustworthiness of the boot process is verified. Referring now to FIG. 3C, the value in the PCR  42   a  is compared to the predetermined value that represents a trustworthy boot process. Preferably, the predetermined value is calculated by the operating system, which is aware of the bootable devices. Because the method and system in accordance with the preferred embodiment of the present invention performs the clean restart whenever the BIOS  30  unsuccessfully attempts to boot a nonbootable device, the PCR  42   a  value reflects only the device that was successfully booted by BIOS  30 . Thus, by comparing the PCR  42   a  value and the predetermined value, the operating system can immediately determine whether the boot is trustworthy.  
         [0022]    For example, if unauthorized code is present in any one of those successfully booted devices, the digest value resulting from a hash of that code will produce a PCR  42   a  value that differs from the predetermined value. The operating system would then conclude that the boot process is not trustworthy, and take appropriate action. If, however, the PCR  42   a  value matches the predetermined value, then the operating system can be assured that the boot process is trustworthy, and full control can be passed to the operating system.  
         [0023]    Through the method and system of the present invention, a clean boot process is performed before verifying the trustworthiness of the boot process. Because the boot process is clean the operating system does not need to include additional logic to perform a security check of the nonbootable and bootable devices to determine if a breach has occurred. By performing a clean restart, which includes clearing the memory, any code loaded and stored in memory from the nonbootable device is cleared, thereby eliminating a potential source of intrusion. Thus, the method and system of the present invention protects the computer system from rogue applications that may be hidden in the hardware devices.  
         [0024]    Although the present invention has been described in accordance with the embodiments shown, one of ordinary skill in the art will readily recognize that there could be variations to the embodiments and those variations would be within the spirit and scope of the present invention. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.