Secure booting of a personal computer system

Abstract

Methods for securing booting a personal computer system. One method includes establishing a secret between two or more devices and securing the secret in each of the two or more devices. Another method includes processing BIOS code instructions and accessing security hardware. The method also includes accessing a first device, locking the security hardware, and calling boot code. Another method includes reading a secret from a first location, storing the secret in a secure location different from the first location, and locking the first location. Another method includes requesting authentication for a device, receiving authentication for the device, and setting a timer associated with the device. Another method includes requesting authentication for a device, failing authentication for the device, and preventing access to the device upon failing authentication for the device.

Claims

What is claimed is:

1. A method of booting a computer system, the method comprising:

establishing a secret between two or more devices; and

securing the secret in each of the two or more devices.

2. The method of claim 1, wherein establishing the secret between two or more devices comprises providing a first GUID from a first device to a master device; and

wherein securing the secret in each of the two or more devices comprises storing the first GUID in a GUID table in the master device, preventing access to the first GUID in the first device, and preventing access to the GUID table in the master device.

3. The method of claim 2, further comprising:

the first device setting an introduced bit in response to providing the first GUID from the first device to the master device.

4. The method of claim 2, wherein establishing the secret between two or more devices further comprises providing a system GUID from a master device to at least a first device; and wherein securing the secret in each of the two or more devices further comprises storing the system GUID in a storage location in at least the first device, preventing access to the system GUID in the storage location in at least the first device, and preventing access to the system GUID in the master device.

5. The method of claim 1, wherein establishing the secret between two or more devices comprises providing a system GUID from a master device to at least a first device; and wherein securing the secret in each of the two or more devices comprises storing the system GUID in a storage location in at least the first device, preventing access to the system GUID in the storage location in at least the first device, and preventing access to the system GUID in the master device.

6. The method of claim 5, further comprising:

the first device setting an introduced bit in response to providing the system GUID from the master device to at least the first device.

7. The method of claim 1, wherein establishing the secret between two or more devices comprises a master device providing a value to a first device as a first GUID; and wherein securing the secret in each of the two or more devices comprises the first device storing the first GUID in a storage location, the master device storing the first GUID in a GUID table, preventing access to the first GUID in the first device, and preventing access to the GUID table in the master device.

8. The method of claim 7, wherein establishing the secret between two or more devices further comprises the master device obtaining a random number and the master device providing the random number to the first device as the first GUID.

9. A method for booting a computer system, the method comprising:

step for establishing a secret between two or more devices; and

step for securing the secret in each of the two or more devices.

10. The method of claim 9, wherein the step for establishing the secret between two or more devices comprises step for providing a first GUID from a first device to a master device; and

wherein the step for securing the secret in each of the two or more devices comprises step for storing the first GUID in a GUID table in the master device, step for preventing access to the first GUID in the first device, and step for preventing access to the GUID table in the master device.

11. The method of claim 10, further comprising:

step for the first device setting an introduced bit in response to the step for providing the first GUID from the first device to the master device.

12. The method of claim 10, wherein the step for establishing the secret between two or more devices further comprises step for providing a system GUID from a master device to at least a first device; and wherein the step for securing the secret in each of the two or more devices further comprises step for storing the system GUID in a storage location in at least the first device, step for preventing access to the system GUID in the storage location in at least the first device, and step for preventing access to the system GUID in the master device.

13. The method of claim 9, wherein the step for establishing the secret between two or more devices comprises step for providing a system GUID from a master device to at least a first device; and wherein the step for securing the secret in each of the two or more devices comprises step for storing the system GUID in a storage location in at least the first device, step for preventing access to the system GUID in the storage location in at least the first device, and step for preventing access to the system GUID in the master device.

14. The method of claim 13, further comprising:

step for the first device setting an introduced bit in response to providing the system GUID from the master device to at least the first device.

15. The method of claim 9, wherein the step for establishing the secret between two or more devices comprises step for a master device providing a value to a first device as a first GUID; and wherein the step for securing the secret in each of the two or more devices comprises step for the first device storing the first GUID in a storage location, step for the master device storing the first GUID in a GUID table, step for preventing access to the first GUID in the first device, and step for preventing access to the GUID table in the master device.

16. The method of claim 15, wherein the step for establishing the secret between two or more devices further comprises step for the master device obtaining a random number and step for the master device providing the random number to the first device as the first GUID.

17. A computer readable program storage device encoded with instructions that, when executed by a computer system, performs a method of booting the computer system, the method comprising:

establishing a secret between two or more devices; and

securing the secret in each of the two or more devices.

18. The computer readable program storage device of claim 17, wherein establishing the secret between two or more devices comprises providing a first GUID from a first device to a master device; and

wherein securing the secret in each of the two or more devices comprises storing the first GUID in a GUID table in the master device, preventing access to the first GUID in the first device, and preventing access to the GUID table in the master device.

19. The computer readable program storage device of claim 18, the method further comprising:

the first device setting an introduced bit in response to providing the first GUID from the first device to the master device.

20. The computer readable program storage device of claim 18, wherein establishing the secret between two or more devices further comprises providing a system GUID from a master device to at least a first device; and wherein securing the secret in each of the two or more devices further comprises storing the system GUID in a storage location in at least the first device, preventing access to the system GUID in the storage location in at least the first device, and preventing access to the system GUID in the master device.

21. The computer readable program storage device of claim 17, wherein establishing the secret between two or more devices comprises providing a system GUID from a master device to at least a first device; and wherein securing the secret in each of the two or more devices comprises storing the system GUID in a storage location in at least the first device, preventing access to the system GUID in the storage location in at least the first device, and preventing access to the system GUID in the master device.

22. The computer readable program storage device of claim 21, the method further comprising:

the first device setting an introduced bit in response to providing the system GUID from the master device to at least the first device.

23. The computer readable program storage device of claim 17, wherein establishing the secret between two or more devices comprises a master device providing a value to a first device as a first GUID; and wherein securing the secret in each of the two or more devices comprises the first device storing the first GUID in a storage location, the master device storing the first GUID in a GUID table, preventing access to the first GUID in the first device, and preventing access to the GUID table in the master device.

24. The computer readable program storage device of claim 23, wherein establishing the secret between two or more devices further comprises the master device obtaining a random number and the master device providing the random number to the first device as the first GUID.

25. A method of booting a computer system, the computer system including a processor coupled to a memory, to security hardware, and to a first device, the method comprising:

processing BIOS code instructions;

accessing security hardware;

accessing a first device;

locking the security hardware; and

calling boot code.

26. The method of claim 25, wherein accessing security hardware includes the BIOS code instructions accessing the security hardware.

27. The method of claim 25, wherein accessing security hardware includes the first device accessing the security hardware.

28. The method of claim 25, wherein locking the security hardware includes locking the security hardware to prevent access to the first device.

29. The method of claim 28, wherein locking the security hardware to prevent access to the first device includes setting one or more lock bits to prevent access to the first device.

30. The method of claim 25, further comprising:

unlocking the security hardware.

31. The method of claim 30, wherein unlocking the security hardware includes unlocking the security hardware in response to accessing the first device.

32. The method of claim 25, further comprising:

checking a lock status of the security hardware.

33. The method of claim 32, wherein checking the lock status of the security hardware comprises reading one or more entries in a storage location configured to store one or more lock bits.

34. A method for booting a computer system, the computer system including a processor coupled to a memory, to security hardware, and to a first device, the method comprising:

step for processing BIOS code instructions;

step for accessing security hardware;

step for accessing a first device;

step for locking the security hardware; and

step for calling boot code.

35. The method of claim 34, wherein the step for accessing the security hardware includes step for the BIOS code instructions accessing the security hardware.

36. The method of claim 34, wherein the step for accessing the security hardware includes step for the first device accessing the security hardware.

37. The method of claim 34, wherein the step for locking the security hardware includes step for locking the security hardware to prevent access to the first device.

38. The method of claim 37, wherein the step for locking the security hardware to prevent access to the first device includes step for setting one or more lock bits to prevent access to the first device.

39. The method of claim 34, further comprising:

step for unlocking the security hardware.

40. The method of claim 39, wherein the step for unlocking the security hardware includes step for unlocking the security hardware in response to the step for accessing the first device.

41. The method of claim 34, further comprising:

step for checking a lock status of the security hardware.

42. The method of claim 41, wherein the step of checking the lock status of the security hardware comprises step for reading one or more entries in a storage location configured to store one or more lock bits.

43. A computer readable program storage device encoded with instructions that, when executed by a computer system including a processor coupled to a memory, to security hardware, and to a first device, performs a method of booting the computer system, the method comprising:

processing BIOS code instructions;

accessing security hardware;

accessing a first device;

locking the security hardware; and

calling boot code.

44. The computer readable program storage device of claim 43, wherein accessing the security hardware includes the BIOS code instructions accessing the security hardware.

45. The computer readable program storage device of claim 43, wherein said accessing security hardware includes the first device accessing the security hardware.

46. The computer readable program storage device of claim 43, wherein said locking the security hardware includes locking the security hardware to prevent access to the first device.

47. The computer readable program storage device of claim 46, wherein locking the security hardware to prevent access to the first device includes setting one or more lock bits to prevent access to the first device.

48. The computer readable program storage device of claim 43, the method further comprising:

unlocking the security hardware.

49. The computer readable program storage device of claim 48, wherein unlocking the security hardware includes unlocking the security hardware in response to accessing the first device.

50. The computer readable program storage device of claim 43, the method further comprising:

checking a lock status of the security hardware.

51. The computer readable program storage device of claim 50, wherein checking the lock status of the security hardware comprises reading one or more entries in a storage location configured to store one or more lock bits.

52. A method of booting a personal computer system, the method comprising:

reading a secret from a first location;

storing the secret in a secure location different from the first location; and

locking the first location.

53. The method of claim 52, wherein the first location comprises a memory;

wherein reading the secret from the first location comprises reading the secret from a memory;

wherein storing the secret in a secure location different from the first location comprises storing the secret in a secure location different from the memory; and

wherein locking the first location comprises locking the memory.

54. The method of claim 53, wherein the memory is a read-only memory (ROM);

wherein reading a secret from a memory comprises reading the secret from the ROM; and

wherein securing the secret in a secure location different from the memory comprises securing the secret in the secure location different from the ROM.

55. The method of claim 54, wherein the data comprises basic input-output system (BIOS) data and the ROM is a BIOS ROM configured to store the BIOS data;

wherein reading the secret from the ROM comprises reading the secret from the BIOS ROM; and

wherein securing the secret in the secure location different from the ROM comprises securing the secret in the secure location different from the BIOS RO M.

56. The method of claim 55, wherein securing the secret in the secure location different from the memory comprises storing the secret in SMM memory space.

57. The method of claim 52, further comprising:

reading code from the first location, wherein the code is different from the secret and different from the data stored in the first location.

58. The method of claim 57, wherein the first location comprises a memory;

wherein reading the secret from the first location comprises reading the secret from a memory;

wherein storing the secret in a secure location different from the first location comprises storing the secret in a secure location different from the memory;

wherein locking the first location comprises locking the memory; and

wherein reading the code from the first location, wherein the code is different from the secret and different from the data stored in the first location comprises reading the code from the memory, wherein the code is different from the secret and different from the data stored in the memory.

59. The method of claim 58, wherein securing the secret in a secure location different from the memory comprises storing the secret in SMM memory space.

60. A method for booting a personal computer system, the method comprising:

step for reading a secret from a first location;

step for storing the secret in a secure location different from the first location; and

step for locking the first location.

61. The method of claim 60, wherein the first location comprises a memory;

wherein the step for reading the secret from the first location comprises step for reading the secret from a memory;

wherein the step for storing the secret in the secure location different from the first location comprises step for storing the secret in a secure location different from the memory; and

wherein the step for locking the first location comprises step for locking the memory.

62. The method of claim 61, wherein the memory is a read-only memory (ROM);

wherein the step for reading the secret from the memory comprises reading the secret from the ROM; and

wherein the step for securing the secret in the secure location different from the memory comprises securing the secret in the secure location different from the ROM.

63. The method of claim 62, wherein the data comprises basic input-output system (BIOS) data and the ROM is a BIOS ROM configured to store the BIOS data;

wherein the step for reading the secret from the ROM comprises step for reading the secret from the BIOS ROM; and

wherein the step for securing the secret in the secure location different from the ROM comprises step for securing the secret in the secure location different from the BIOS ROM.

64. The method of claim 63, wherein the step for securing the secret in the secure location different from the memory comprises step for storing the secret in SMM memory space.

65. The method of claim 60, further comprising:

step for reading code from the first location, wherein the code is different from the secret and different from the data stored in the first location.

66. The method of claim 65, wherein the first location comprises a memory;

wherein the step for reading the secret from the first location comprises step for reading the secret from the memory;

wherein the step for storing the secret in the secure location different from the first location comprises step for storing the secret in the secure location different from the memory;

wherein the step for locking the first location comprises step for locking the memory; and

wherein the step for reading the code from the first location, wherein the code is different from the secret and different from the data stored in the first location comprises step for reading the code from the memory, wherein the code is different from the secret and different from the data stored in the memory.

67. The method of claim 66, wherein the step for securing the secret in the secure location different from the memory comprises step for storing the secret in SMM memory space.

68. A computer readable program storage device encoded with instructions that, when executed by a personal computer system, performs a method of booting the personal computer system, the method comprising:

reading a secret from a first location;

storing the secret in a secure location different from the first location; and

locking the first location.

69. The computer readable program storage device of claim 68, wherein the first location comprises a memory;

wherein reading the secret from the first location comprises reading the secret from a memory;

wherein storing the secret in a secure location different from the first location comprises storing the secret in a secure location different from the memory; and

wherein locking the first location comprises locking the memory.

70. The computer readable program storage device of claim 69, wherein the memory is a read-only memory (ROM);

wherein reading a secret from a memory comprises reading the secret from the ROM; and

wherein securing the secret in a secure location different from the memory comprises securing the secret in the secure location different from the ROM.

71. The computer readable program storage device of claim 70, wherein the data comprises basic input-output system (BIOS) data and the ROM is a BIOS ROM configured to store the BIOS data;

wherein reading the secret from the ROM comprises reading the secret from the BIOS ROM; and

wherein securing the secret in the secure location different from the ROM comprises securing the secret in the secure location different from the BIOS ROM.

72. The computer readable program storage device of claim 71, wherein securing the secret in the secure location different from the memory comprises storing the secret in SMM memory space.

73. The computer readable program storage device of claim 68, the method further comprising:

reading code from the first location, wherein the code is different from the secret and different from the data stored in the first location.

74. The computer readable program storage device of claim 73, wherein the first location comprises a memory;

wherein reading the secret from the first location comprises reading the secret from a memory;

wherein storing the secret in a secure location different from the first location comprises storing the secret in a secure location different from the memory;

wherein locking the first location comprises locking the memory; and

wherein reading the code from the first location, wherein the code is different from the secret and different from the data stored in the first location comprises reading the code from the memory, wherein the code is different from the secret and different from the data stored in the memory.

75. The computer readable program storage device of claim 74, wherein securing the secret in a secure location different from the memory comprises storing the secret in SMM memory space.

76. A method of booting a computer system, the method comprising:

requesting authentication for a device;

receiving authentication for the device; and

setting a timer associated with the device.

77. The method of claim 76, wherein requesting authentication for the device comprises requesting authentication for the device from a subsystem; and wherein receiving authentication for the device comprises receiving authentication for the device from the subsystem.

78. The method of claim 76, further comprising:

requesting authentication for a subsystem;

receiving authentication for the subsystem; and

setting a timer associated with the subsystem.

79. The method of claim 78, wherein requesting authentication for the subsystem comprises requesting authentication for the subsystem from the computer system; and

wherein receiving authentication for the subsystem comprises receiving authentication for the subsystem from the computer system.

80. The method of claim 76, further comprising:

requesting authentication for the computer system;

receiving authentication for the computer system; and

setting a timer associated with the computer system.

81. The method of claim 80, wherein requesting authentication for the computer system comprises requesting authentication for the computer system from a network security authenticator; and wherein receiving authentication for the computer system comprises receiving authentication for the computer system from the network security authenticator.

82. The method of claim 76, wherein the device comprises the computer system, wherein requesting authentication for the device comprises requesting authentication for the computer system from a network security authenticator; and wherein receiving authentication for the computer system comprises receiving authentication for the device from the network security authenticator.

83. A method for booting a computer system, the method comprising:

step for requesting authentication for a device;

step for receiving authentication for the device; and

step for setting a timer associated with the device.

84. The method of claim 83, wherein the step for requesting authentication for the device comprises step for requesting authentication for the device from a subsystem; and wherein the step for receiving authentication for the device comprises step for receiving authentication for the device from the subsystem.

85. The method of claim 83, further comprising:

step for requesting authentication for a subsystem;

step for receiving authentication for the subsystem; and

step for setting a timer associated with the subsystem.

86. The method of claim 85, wherein the step for requesting authentication for the subsystem comprises step for requesting authentication for the subsystem from the computer system; and wherein the step for receiving authentication for the subsystem comprises step for receiving authentication for the subsystem from the computer system.

87. The method of claim 83, further comprising:

step for requesting authentication for the computer system;

step for receiving authentication for the computer system; and

step for setting a timer associated with the computer system.

88. The method of claim 87, wherein the step for requesting authentication for the computer system comprises step for requesting authentication for the computer system from a network security authenticator; and wherein the step for receiving authentication for the computer system comprises step for receiving authentication for the computer system from the network security authenticator.

89. The method of claim 83, wherein the device comprises the computer system, wherein the step for requesting authentication for the device comprises step for requesting authentication for the computer system from a network security authenticator; and wherein the step for receiving authentication for the computer system comprises step for receiving authentication for the device from the network security authenticator.

90. A computer readable program storage device encoded with instructions that, when executed by a computer system, performs a method of booting the computer system, the method comprising:

requesting authentication for a device;

receiving authentication for the device; and

setting a timer associated with the device.

91. The computer readable program storage device of claim 90, wherein requesting authentication for the device comprises requesting authentication for the device from a subsystem; and wherein receiving authentication for the device comprises receiving authentication for the device from the subsystem.

92. The computer readable program storage device of claim 90, the method further comprising:

requesting authentication for a subsystem;

receiving authentication for the subsystem; and

setting a timer associated with the subsystem.

93. The computer readable program storage device of claim 92, wherein requesting authentication for the subsystem comprises requesting authentication for the subsystem from the computer system; and wherein receiving authentication for the subsystem comprises receiving authentication for the subsystem from the computer system.

94. The computer readable program storage device of claim 90, the method further comprising:

requesting authentication for the computer system;

receiving authentication for the computer system; and

setting a timer associated with the computer system.

95. The computer readable program storage device of claim 94, wherein requesting authentication for the computer system comprises requesting authentication for the computer system from a network security authenticator; and wherein receiving authentication for the computer system comprises receiving authentication for the computer system from the network security authenticator.

96. The computer readable program storage device of claim 90, wherein the device comprises the computer system, wherein requesting authentication for the device comprises requesting authentication for the computer system from a network security authenticator; and

wherein receiving authentication for the computer system comprises receiving authentication for the device from the network security authenticator.

97. A method of booting a computer system, the method comprising:

requesting authentication for a device;

failing authentication for the device; and

preventing access to the device upon failing authentication for the device.

98. The method of claim 97, wherein the device is the computer system; wherein requesting authentication for the device comprises requesting authentication for the computer system; wherein failing authentication for the device comprises failing authentication for the computer system; and wherein preventing access to the device upon failing authentication for the device comprises preventing access to the computer system upon failing authentication for the computer system.

99. The method of claim 98, wherein requesting authentication for the computer system comprises requesting authentication for the computer system over a network from a network authentication device.

100. A method for booting a computer system, the method comprising:

step for requesting authentication for a device;

step for failing authentication for the device; and

step for preventing access to the device upon failing authentication for the device.

101. The method of claim 100, wherein the device is the computer system; wherein the step for requesting authentication for the device comprises step for requesting authentication for the computer system; wherein the step for failing authentication for the device comprises step for failing authentication for the computer system; and wherein the step for preventing access to the device upon failing authentication for the device comprises step for preventing access to the computer system upon failing authentication for the computer system.

102. The method of claim 101, wherein the step for requesting authentication for the computer system comprises step for requesting authentication for the computer system over a network from a network authentication device.

103. A computer readable program storage device encoded with instructions that, when executed by a computer system, performs a method of booting the computer system, the method comprising:

requesting authentication for a device;

failing authentication for the device; and

preventing access to the device upon failing authentication for the device.

104. The computer readable program storage device of claim 103, wherein the device is the computer system; wherein requesting authentication for the device comprises requesting authentication for the computer system; wherein failing authentication for the device comprises failing authentication for the computer system; and wherein preventing access to the device upon failing authentication for the device comprises preventing access to the computer system upon failing authentication for the computer system.

105. The computer readable program storage device of claim 104, wherein requesting authentication for the computer system comprises requesting authentication for the computer system over a network from a network authentication device.

106. A method of booting a computer system, the method comprising:

requesting authentication through security hardware using master mode;

placing one or more bus interface logics in master mode by setting master mode bits therein;

receiving authentication data through the one or more bus interface logics in master mode; and

verifying the authentication data.

107. The method of claim 106, further comprising:

exiting master mode and flushing buffers in the one or more bus interface logics.

108. The method of claim 106, further comprising:

ending booting the computer system if the authentication data is not verified.

109. The method of claim 106, further comprising:

continuing booting the computer system after the authentication data is verified.

110. A method for booting a computer system, the method comprising:

step for requesting authentication through security hardware using master mode;

step for placing one or more bus interface logics in master mode by setting master mode bits therein;

step for receiving authentication data through the one or more bus interface logics in master mode; and

step for verifying the authentication data.

111. The method of claim 110, further comprising:

step for exiting master mode and flushing buffers in the one or more bus interface logics.

112. The method of claim 110, further comprising:

step for ending booting the computer system if the authentication data is not verified.

113. The method of claim 110, further comprising:

step for continuing booting the computer system after the authentication data is verified.

114. A computer readable program storage device encoded with instructions that, when executed by a computer system, performs a method of booting the computer system, the method comprising:

requesting authentication through security hardware using master mode;

placing one or more bus interface logics in master mode by setting master mode bits therein;

receiving authentication data through the one or more bus interface logics in master mode; and

verifying the authentication data.

115. The computer readable program storage device of claim 114, further comprising:

exiting master mode and flushing buffers in the one or more bus interface logics.

116. The computer readable program storage device of claim 114, further comprising:

ending booting the computer system if the authentication data is not verified.

117. The computer readable program storage device of claim 114, further comprising:

continuing booting the computer system after the authentication data is verified.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to computing systems, and, more particularly, to methods for secure components in personal computer systems.

2. Description of the Related Art

FIG. 1A illustrates an exemplary computer system 100. The computer system 100 includes a processor 102, a north bridge 104, memory 106, Advanced Graphics Port (AGP) memory 108, a Peripheral Component Interconnect (PCI) bus 110, a south bridge 112, a battery, an AT Attachment (ATA) interface 114 (more commonly known as an Integrated Drive Electronics (IDE) interface), a universal serial bus (USB) interface 116, a Low Pin Count (LPC) bus 118, an input/output controller chip (SuperI/O™) 120, and BIOS memory 122. It is noted that the north bridge 104 and the south bridge 112 may include only a single chip or a plurality of chips, leading to the collective term "chipset." It is also noted that other buses, devices, and/or subsystems may be included in the computer system 100 as desired, e.g. caches, modems, parallel or serial interfaces, SCSI interfaces, network interface cards, etc. ["SuperI/O" is a trademark of National Semiconductor Corporation of Santa Clara, Calif.]

The processor 102 is coupled to the north bridge 104. The north bridge 104 provides an interface between the processor 102, the memory 106, the AGP memory 108, and the PCI bus 110. The south bridge 112 provides an interface between the PCI bus 110 and the peripherals, devices, and subsystems coupled to the IDE interface 114, the USB interface 116, and the LPC bus 118. The battery 113 is shown coupled to the south bridge 112. The Super I/O™ chip 120 is coupled to the LPC bus 118.

The north bridge 104 provides communications access between and/or among the processor 102, memory 106, the AGP memory 108, devices coupled to the PCI bus 110, and devices and subsystems coupled to the south bridge 112. Typically, removable peripheral devices are inserted into PCI "slots" (not shown) that connect to the PCI bus 110 to couple to the computer system 100. Alternatively, devices located on a motherboard may be directly connected to the PCI bus 110.

The south bridge 112 provides an interface between the PCI bus 110 and various devices and subsystems, such as a modem, a printer, keyboard, mouse, etc., which are generally coupled to the computer system 100 through the LPC bus 118 (or its predecessors, such as an X-bus or an ISA bus). The south bridge 112 includes the logic used to interface the devices to the rest of computer system 100 through the IDE interface 114, the USB interface 116, and the LPC bus 118.

FIG. 1B illustrates certain aspects of the prior art south bridge 112, including those provided reserve power by the battery 113, so-called "being inside the RTC battery well" 125. The south bridge 112 includes south bridge (SB) RAM 126 and a clock circuit 128, both inside the RTC battery well 125. The SB RAM 126 includes CMOS RAM 126A and RTC RAM 126B. The RTC RAM 126B includes clock data 129 and checksum data 127. The south bridge 112 also includes, outside the RTC battery well 125, a CPU interface 132, power and system management units 133, PCI bus interface logic 134A, USB interface logic 134C, IDE interface logic 134B, and LPC bus interface logic 134D.

Time and date data from the clock circuit 128 are stored as the clock data 129 in the RTC RAM 126B. The checksum data 127 in the RTC RAM 126B may be calculated based on the CMOS RAM 126A data and stored by BIOS during the boot process, such as is described below, e.g. block 148, with respect to FIG. 2A. The CPU interface 132 may include interrupt signal controllers and processor signal controllers. The power and system management units 133 may include an ACPI (Advanced Configuration and Power Interface) controller.

From a hardware point of view, an x86 operating environment provides little for protecting user privacy, providing security for corporate secrets and assets, or protecting the ownership rights of content providers. All of these goals, privacy, security, and ownership (collectively, PSO) are becoming critical in an age of Internet-connected computers. The original personal computers were not designed in anticipation of PSO needs.

From a software point of view, the x86 operating environment is equally poor for PSO. The ease of direct access to the hardware through software or simply by opening the cover of the personal computer allows an intruder or thief to compromise most security software and devices. The personal computer's exemplary ease of use only adds to the problems for PSO.

SUMMARY OF THE INVENTION

In one aspect of the present invention, a method of booting a computer system is presented. The method includes establishing a secret between two or more devices and securing the secret in each of the two or more devices.

According to another aspect of the present invention, a method of booting a computer system including a processor coupled to a memory, to security hardware, and to a first device is presented. The method includes processing BIOS code instructions and accessing security hardware. The method also includes accessing a first device, locking the security hardware, and calling boot code.

According to yet another aspect of the present invention, a method of booting a personal computer system is provided. The method includes reading a secret from a first location, storing the secret in a secure location different from the first location, and locking the first location.

According to still another aspect of the present invention, a method of booting a computer system is provided. The method includes requesting authentication for a device, receiving authentication for the device, and setting a timer associated with the device.

According to still yet another aspect of the present invention, a method of booting a computer system is provided. The method includes requesting authentication for a device, failing authentication for the device, and preventing access to the device upon failing authentication for the device.

According to yet another aspect of the present invention, a method of booting a computer system is provided. The method includes requesting authentication through security hardware using master mode and placing one or more bus interface logics in master mode by setting master mode bits therein. The method also includes receiving authentication data through the one or more bus interface logics in master mode and verifying the authentication data.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may be understood by reference to the following description taken in conjunction with the accompanying drawings, in which like reference numerals identify similar elements, and in which:

FIG. 1A illustrates a block diagram of a prior art computer system, while FIG. 1B illustrates a block diagram of a prior art south bridge;

FIGS. 2A and 2B illustrate flowcharts of prior art methods for operating a computer system using code stored in ROM;

FIG. 3 illustrates a flowchart of an embodiment of data and command flow in a computer system having a secure execution box, according to one aspect of the present invention;

FIG. 4 illustrates a block diagram of an embodiment of a computer system including security hardware in the south bridge as well as a crypto-processor, according to one aspect of the present invention;

FIGS. 5A and 5B illustrate block diagrams of embodiments of a south bridge including security hardware for controlling SMM, according to various aspect of the present invention;

FIG. 6 illustrates a block diagram of an embodiment of a south bridge including security hardware for secure SMM operations, according to one aspect of the present invention;

FIGS. 7A, 7B, 7C, and 7D illustrate embodiments of secure storage, according to various aspects of the present invention;

FIGS. 8A and 8B illustrate block diagrams of embodiments of a BIOS ROM and an SMM ROM for secure SMM operations, respectively, according to various aspects of the present invention;

FIGS. 9A and 9B illustrate block diagrams of embodiments of a computer system operable to control the timing and duration of SMM operations, according to one aspect of the present invention;

FIG. 10A illustrates a flowchart of an embodiment of a method for forcing a processor out of SMM, according to one aspect of the present invention, while FIG. 10B illustrates a flowchart of an embodiment of a method for reinitiating SMM upon the early termination of SMM, according to one aspect of the present invention;

FIGS. 11A and 11B illustrate flowcharts of embodiments of methods for updating a monotonic counter stored in the SMM ROM, according to various aspects of the present invention;

FIGS. 12A and 12B illustrate flowcharts of embodiments of methods for updating a monotonic counter in the south bridge, according to various aspects of the present invention;

FIGS. 13A and 13B illustrate flowcharts of embodiments of a method for providing a monotonic value in a computer system, according to one aspect of the present invention;

FIGS. 14A and 14B illustrate block diagrams of embodiments of processors including random number generators using entropy registers, according to one aspect of the present invention;

FIG. 15 illustrates a block diagram of another embodiment of a random number generator, according to one aspect of the present invention;

FIGS. 16A, 16B, 16C, 16D, 16E, 16F, and 16G illustrate flowcharts of embodiments of methods for accessing the security hardware, which may be locked, according to various aspects of the present invention;

FIGS. 17A, 17B, and 17C illustrate block diagrams of embodiments of the access locks 460 shown in FIG. 6, while FIG. 17D illustrates a block diagram of an embodiment of the override register, all according to various aspects of the present invention;

FIG. 18A illustrates a prior art flowchart of an SMM program, while FIG. 18B illustrates a flowchart of an embodiment of operation of an interruptible and re-enterable SMM program, and FIG. 18C illustrated a flowchart of an embodiment of operation of a computer system running the interruptible and re-enterable SMM program, according to various aspects of the present invention;

FIGS. 19A, 19B, and 19C illustrate block diagrams of embodiments of computer systems with the BIOS ROM accessible to the processor at boot time and to the south bridge at other times, according to various aspects of the present invention;

FIGS. 20A-20D illustrate block diagrams of embodiments of processors including lock registers and logic, according to various aspects of the present invention;

FIG. 21 illustrates a flowchart of an embodiment of a method for initiating HDT mode, according to one aspect of the present invention;

FIG. 22 illustrates a flowchart of an embodiment of a method for changing the HDT enable status, according to one aspect of the present invention;

FIG. 23 illustrates a flowchart of an embodiment of a method for initiating the microcode loader, according to one aspect of the present invention;

FIG. 24 illustrates a flowchart of an embodiment of a method for changing the microcode loader enable status, according to one aspect of the present invention;

FIGS. 25A, 25B, 26, and 27 illustrate flowcharts of embodiments of methods for secure access to storage, according to various aspects of the present invention;

FIG. 28 illustrates a prior art challenge-response method for authentication;

FIGS. 29A, 29B, 29C, 29D, and 29E illustrate embodiments of computer devices or subsystems including GUIDs and/or a stored secret and/or a system GUID, according to various aspects of the present invention;

FIGS. 30A and 30B illustrate flowcharts of embodiments of methods for operating a computer system including a biometric device, such as the biometric device shown in FIG. 29A, according to various aspects of the present invention;

FIGS. 31A, 31B, 32A, 32B, 32C, and 33 illustrate flowcharts of embodiments of methods for authenticating a device in a computer system, such as computer systems including the computer subsystems of FIGS. 29A, 29D, and 29E, according to various aspects of the present invention;

FIGS. 34 and 35 illustrate flowcharts of embodiments of methods for removing a device from a computer system once the device has been united with the computer system using a introduced bit, according to various aspects of the present invention;

FIG. 36 illustrates a block diagram of an embodiment of a computer subsystem including bus interface logics with master mode capabilities, according to one aspect of the present invention;

FIG. 37 illustrates a flowchart of an embodiment of a method for operating in a master mode outside the operating system, according to one aspect of the present invention;

FIG. 38A illustrates a flowchart of an embodiment of a method for booting a computer system including authentication via the crypto-processor using master mode logic, while FIG. 38B illustrates a flowchart of an embodiment of a method for booting a computer system including authentication via the security hardware using the master mode logic, according to various aspects of the present invention;

FIGS. 39A, 39B, and 39C illustrate block diagrams of embodiments of computer systems 5000 for securing a device, a computer subsystem, or a computer system using timers to enforce periodic authentication, according to various aspects of the present invention;

FIGS. 40A and 40B illustrate flowcharts of embodiments of a method for securing a device, a computer subsystem, or a computer system, such as a portable computer, by limiting use to finite periods of time between successive authorizations, according to various aspects of the present invention;

FIG. 41 illustrates a flowchart of an embodiment of a method for booting a computer system including initializing a timer to enforce periodic authentication and authorization, according to one aspect of the present invention; and

FIGS. 42A and 42B illustrate block diagrams of embodiments of the system management registers, according to various aspects of the present invention.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the description herein of specific embodiments is not intended to limit the invention to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

Illustrative embodiments of the invention are described below. In the interest of clarity, not all features of an actual implementation are described in this specification. It will, of course, be appreciated that in the development of any such actual embodiment, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which will vary from one implementation to another. Moreover, it will be appreciated that such a development effort might be complex and time-consuming, but would nevertheless be a routine undertaking for those of ordinary skill in the art having the benefit of this disclosure. The use of a letter in association with a reference number is intended to show alternative embodiments or examples of the item to which the reference number is connected.

System Management Mode (SMM) is a mode of operation in the computer system that was implemented to conserve power. The SMM was created for the fourth generation x86 processors. As newer x86 generation processors have appeared, the SMM has become relatively transparent to the operating system. That is, computer systems enter and leave the SMM with little or no impact on the operating system.

Referring now to the drawings, and in particular to FIG. 2A, a flowchart of a prior art method of initializing a computer system using code stored in the BIOS 122 is shown. During initialization of the power supply, the power supply generates a power good signal to the north bridge, in block 136. Upon receiving the power good signal from the power supply, the south bridge (or north bridge) stops asserting the reset signal for the processor, in block 138.

During initialization, the processor reads the default jump location, in block 140. The default jump location in memory is usually at a location such as FFFF0h. The processor performs a jump to the appropriate BIOS code location (e.g. FFFF0h) in the ROM BIOS, copies the BIOS code to the RAM memory, and begins possessing the BIOS code instructions from the RAM memory, in block 142. The BIOS code, processed by the processor, performs a power-on self test (POST), in block 144.

The BIOS code next looks for additional BIOS code, such as from a video controller, IDE controller, SCSI controller, etc. and displays a start-up information screen, in block 146. As examples, the video controller BIOS is often found at C000h, while the IDE controller BIOS code is often found at C800h. The BIOS code may perform additional system tests, such as a RAM memory count-up test, and a system inventory, including identifying COM (serial) and LPT (parallel) ports, in block 148. The BIOS code also identifies plug-and-play devices and other similar devices and then displays a summary screen of devices identified, in block 150.

The BIOS code identifies the boot location, and the corresponding boot sector, in block 152. The boot location may be on a floppy drive, a hard drive, a CDROM, a remote location, etc. The BIOS code next calls the boot sector code at the boot location to boot the computer system, such as with an operating system, in block 154.

It is noted that for a cold boot or a hard (re)boot, all or most of the descriptions given in blocks 136-154 may occur. During a warm boot or a soft (re)boot the BIOS code usually jumps from block 142 into block 148, skipping the POST, memory tests, etc.

In FIG. 2B, a flowchart of a prior art method of operating a computer system in SMM using code stored in the BIOS 122 is shown. An interrupt controller receives a request for SMM, in block 172. The interrupt controller signals the request for SMM to the processor by asserting a system management interrupt (SMI#) signal, in block 174.

The processor recognizes the request for SMM and asserts an SMI ACTive (SMIACT#) signal, in block 176. The system recognizes the SMIACT# signal, disables access to the system RAM, and enables access to system management RAM (SMRAM) space, in block 178.

The current processor state is saved to SMRAM, in block 180. The processor resets to the SMM default state and enters SMM, in block 182. The processor next reads the default pointer and jumps to the appropriate place in SMRAM space, in block 184. In block 186, the source and/or nature of the SMI request is identified.

An SMI handler services the SMI request, in block 188. After servicing the SMI request, the SMI handler issues a return from SMM (RSM) instruction to the processor, in block 190. Upon operating on the RSM instruction, the processor restores the saved state information and continues normal operation, in block 192.

FIG. 3 illustrates a block diagram of an embodiment of a flowchart showing data and command flow in a computer system having a secure execution box 260, according to one aspect of the present invention. User input and output (I/O) data and/or commands 205 are provided to and received from one or more applications 210. The applications 210 exchange data and commands with cryptography service providers 215 within the computer system, such as the computer system 100 or any other computer system. The cryptography service providers 215 may use API (Application Programming Interface) calls 220 to interact with drivers 225 that provide access to hardware 230.

According to one aspect of the present invention, the drivers 225 and the hardware 230 are part of a secure execution box configured to operate in a secure execution mode (SEM) 260. Trusted privacy, security and ownership (PSO) operations, also referred to simply as security operations, may take place while the computer system is in SEM 260. Software calls propagated from the user I/O 205 and/or the applications 210 may be placed into the secure execution box in SMM 260 via an SMM initiation register 425B (or SMM initiator 425A) discussed below with respect to FIG. 5B (or FIG. 5A). Parameters may be passed into and out of the secure execution box in SEM 260 via an access-protected mailbox RAM 415, also discussed below with FIGS. 5A and 5B. The software calls have access to the secure execution box in SEM 260 to various security hardware resources, such as described in detail below.

In various embodiments of the present invention, power management functions may be performed inside SEM 260. One current standard for power management and configuration is the Advanced Configuration and Power Interface (ACPI) Specification. The most recent version is Revision 2.0, dated Jul. 27, 2000, and available from the ACPI website currently run by Teleport Internet Services, hereby incorporated herein by reference in its entirety. According to the ACPI specification, control methods, a type of instruction, tell the system to go do something. The ACPI specification does not know how to carry out any of the instructions. The ACPI specification only defines the calls, and the software must be written to carry out the calls in a proscribed manner. The proscribed manner of the ACPI specification is very restrictive. One cannot access some registers in your hardware. To access those registers, various aspects of the present invention generate an SMI# to enter SMM and read these registers. As power management has the potential to be abused e.g. change the processor voltage and frequency, raised above operating limits to destroy the processor, or lowered below operating limits leading to a denial of service, ACPI calls should be carried out in a secure manner, such as inside SEM 260.

Inside SEM 260, each ACPI request can be checked against some internal rules for safe behavior. Using terminology more completely described below, the ACPI request would be placed in the inbox of the mailbox, parameter values read from the inbox, the ACPI request evaluated using the inbox parameters for acceptability, and then either carryout the request or not, based on the evaluation results. For additional details of various embodiments, see FIGS. 6, 42A, and 42B below.

FIG. 4 illustrates a block diagram of an embodiment of a portion of an improved version of computer system 100 including security hardware 370 in a south bridge 330, as well as a crypto-processor 305, according to one aspect of the present invention. The south bridge 330 includes the security hardware 370, an interrupt controller (IC) 365, USB interface logic 134C, and the LPC bus interface logic (LPC BIL) 134D. The IC 365 is coupled to the processor 102. The USB interface logic 134C is coupled through an optional USB hub 315 to a biometric device 320 and a smart card reader 325. The LPC bus 118 is coupled to the south bridge 330 through the LPC BIL 134D. The crypto-processor 305 is also coupled to the LPC bus 118. A memory permission table 310 within the Crypto-processor 305 provides address mappings and/or memory range permission information. The memory permission table 310 may be comprised in a non-volatile memory. A BIOS 355, i.e. some memory, preferably read-only memory or flash memory, is coupled to the crypto-processor 305. The security hardware 370 may include both security hardware and secure assets protected by the security hardware.

The security hardware 370 in the south bridge 330 may be operable to provide an SMI interrupt request to the IC 365 for the processor 102. The security hardware 370 may also interact with the crypto-processor 305. Access to the BIOS 355 is routed through the crypto-processor 305. The crypto-processor 305 is configured to accept and transfer access requests to the BIOS 355. The crypto-processor 305 therefore may understand the address mappings of the BIOS 305. According to one aspect of the present invention, the security hardware 370 allows the computer system 100 to become an embodiment of the secure execution box 260 shown in FIG. 3.

In one embodiment, the crypto-processor 305 is configured to accept an input from the biometric device 320 and/or the smart card reader 325 over the USB interface, i.e. through the optional USB hub 315 and the USB interface logic 134C, and over the LPC bus 118. Other interfaces, such as IDE or PCI, may be substituted. The crypto-processor 305 may request one or more inputs from the biometric device 320 and/or the smart card reader 325 to authenticate accesses to the BIOS 355, other storage devices, and/or another device or subsystem in the computer system 100.

It is noted that the IC 365 may be included in the processor instead of the south bridge 330. The IC 365 is also contemplated as a separate unit or associated with another component of the computer system 100. It is also noted that the operations of the LPC bus 118 may correspond to the prior art Low Pin Count Interface Specification Revision 1.0 of Sep. 29, 1997. The operations of the LPC bus 118 may also correspond to the extended LPC bus disclosed in co-pending U.S. patent application Ser. No. 09/544,858, filed Apr. 7, 2000, entitled "Method and Apparatus For Extending Legacy Computer Systems", whose inventor is Dale E. Gulick, which is hereby incorporated by reference in its entirety. It is further noted that the USB interface logic 134C may couple to the LPC BIL 134D is any of a variety of ways, as is well known in the art for coupling different bus interface logics in a bridge.

FIGS. 5A and 5B illustrate block diagrams of embodiments of the south bridge 330, including the security hardware 370, according to various aspects of the present invention. In FIG. 5A, the south bridge 330A includes the security hardware 370A and IC 365. The security hardware 370A includes sub-devices such as an SMM timing controller 401A, an SMM access controller 402A, and control logic 420A. The sub-devices may be referred to as security hardware or secure assets of the computer system 100. The SMM timing controller 401A includes an SMM indicator 405, a duration timer 406A, a kick-out timer 407A, and a restart timer 408. The SMM access controller 402A includes SMM access filters 410, mailbox RAM 415, and an SMM initiator 425A.

As shown in FIG. 5A, the control logic 420 is coupled to control operation of the SMM timing controller 401A, the SMM access controller 402A, and the SMM initiator 425A. Input and output (I/O) to the security hardware 370A pass through the SMM access filters 410 and are routed through the control logic 420A.

The SMM timing controller 401A includes the duration timer 406A, which measures how long the computer system 100 is in SMM. The kick-out timer 407A, also included in the SMM timing controller 401A, counts down from a predetermined value while the computer system 100 is in SMM. The control logic 420A is configured to assert a control signal (EXIT SMM 404) for the processor to exit SMM, such as in response to the expiration of the kick-out timer 407A. The restart timer 408, included in the SMM timing controller 401A, starts counting down from a predetermined value after the kick-out timer 407A reaches zero. The SMM indicator 405, also included in the SMM timing controller 401A, is operable to monitor the status of one or more signals in the computer system, such as the SMI# (System Management Interrupt) signal and/or the SMIACT# (SMI ACTive) signal to determine if the computer system is in SMM.

The SMM access controller 402A includes the SMM access filters 410, which are configured to accept input requests for the sub-devices within the security hardware 370A. When the computer system 100 is in SMM, the SMM access filters are configured to pass access requests (e.g. reads and writes) to the control logic 420A and/or the target sub-device. When the computer system 100 is not in SMM, the SMM access filters are configured to respond to all access requests with a predetermined value, such as all '1's. The SMM access controller 402A also includes the mailbox RAM 415. In one embodiment, the mailbox RAM 415 includes two banks of RAM, such as 512 bytes each, for passing parameters into and out of the secure execution box 260. Parameters passed to or from the sub-devices included within the security hardware 370 are exchanged at the mailbox RAM 415. One bank of RAM 415, an inbox, is write-only to most of all of the computer system in most operating modes. Thus, parameters to be passed to the sub-devices included within the security hardware 370 may be written into the inbox. During selected operating modes, such as SMM, both read and write accesses are allowed to the inbox. Another bank of RAM 415, an outbox, is read-only to most of all of the computer system in most operating modes. Thus, parameters to be received from the sub-devices included within the security hardware 370 may be read from the outbox. During selected operating modes, preferably secure modes, such as SMM, both read and write accesses are allowed to the outbox.

The SMM initiator 425A may advantageously provide for a convenient way to request that the computer system 100 enter SMM. A signal may be provided to the SMM initiator 425A over the request (REQ) line. The signal should provide an indication of the jump location in SMM memory. The SMM initiator 425A is configured to make a request for SMM over the SMM request (SMM REQ) line, for example, by submitting an SMI# to the interrupt controller 365. The SMM initiator 425A is also configured to notify the control logic 420A that the request for SMM has been received and passed to the interrupt controller 365.

In FIG. 5B, the south bridge 330B includes the security hardware 370B. The IC 365 is shown external to the south bridge 330B. The security hardware 370B includes an SMM timing controller 401B, an SMM access controller 402B, and control logic 420B. The SMM timing controller 401B includes an SMM indicator 405, a duration/kick-out timer 407B, and a restart timer 408. The SMM access controller 402B includes SMM access filters 410 and mailbox RAM 415. An SMM initiation register 425B is shown external to the south bridge 330B.

As shown in FIG. 5B, the control logic 420B is coupled to control operation of the SMM timing controller 401B and the SMM access controller 402B. Input and output (I/O) signals to the security hardware 370B pass through the SMM access filters 410 and are routed through the control logic 420B. The control logic 420B is also coupled to receive an indication of a request for SMM from the SMM initiation register 425B.

The SMM timing controller 401B includes the duration/kick-out timer 407B measures how long the computer system 100 is in SMM, counting up to a predetermined value while the computer system 100 is in SMM. The control logic 420B is configured to assert a control signal for the processor to exit SMM in response to the duration/kick-out timer 407B reaching the predetermined value. The restart timer 408 starts counting down from a predetermined value after the duration/kick-out timer 407B reaches the predetermined value. The SMM indicator 405 is operable to monitor the status of one or more signals in the computer system, such as the SMI# (System Management Interrupt) signal and/or the SMIACT# (SMI ACTive) signal, to determine if the computer system is in SMM.

The SMM access controller 402B includes the SMM access filters 410, which are configured to accept input requests for the sub-devices within the security hardware 370B. When the computer system 100 is in SMM, the SMM access filters are configured to pass access requests (e.g. reads and writes) to the control logic 420B and/or the target sub-device. When the computer system 100 is not in SMM, the SMM access filters may be configured to respond to all access requests with a predetermined value, such as all '1's. The SMM access controller 402B also includes the mailbox RAM 415, described above with respect to FIG. 5A.

The SMM initiation register 425B may advantageously provide for a convenient way to request that the computer system 100 enter SMM. A signal may be provided to the SMM initiation register 425B over the request (REQ) line. The signal should provide an indication of the jump location in SMM memory. The SMM initiation register 425B is configured to provide the indication to the control logic 420B. The control logic 420B is configured to make a request for SMM over the SMM request (SMM REQ) line, for example, by submitting an SMI# to the interrupt controller 365.

It is noted that in the embodiment illustrated in FIG. 5A, the SMM initiator 425A includes internal logic for handling the SMM request. In the embodiment illustrated in FIG. 5B, the SMM initiation register 425B relies on the control logic 420B to handle the SMM request. It is also noted that the SMM initiator 425A is part of the security hardware 370A, while the SMM initiation register 425B is not part of the security hardware 370B.

FIG. 6 illustrates a block diagram of an embodiment of the south bridge 330C including security hardware 370C, according to one aspect of the present invention. As shown, the security hardware 370C includes sub-devices, such as the SMM timing controller 401, the SMM access controller 402, the control logic 420, a TCO counter 430, a monotonic counter 435A, the scratchpad RAM 440, a random number generator 455, secure system (or SMM) management registers 470, OAR- (Open At Reset) locks 450, and an OAR override register 445. The SMM access controller 402 includes one or more access locks 460 within the SMM access filters 410. Some aspects of embodiments of the SMM timing controller 401, the SMM access controller 402, and the control logic 420 are described herein with respect to FIGS. 5A and 5B, above.

The embodiment of the SMM access controller 402 illustrated in FIG. 6 includes the one or more access locks 460 within the SMM access filters 410. The access locks 460 provide a means of preventing (or locking) and allowing (or unlocking) access to one or more of the devices within the security hardware 370C. Various embodiments for the one or more access locks 460 are shown in FIGS. 17A-17C and described with reference thereto.

In one embodiment, the access locks 460 are open at reset (OAR), allowing the BIOS software access to the security hardware 370. The BIOS software then closes the access locks 460 prior to calling the boot sector code, shown in block 154 in FIG. 2A. In various embodiments, the access locks 460 may be opened by software or hardware to allow for access to the security hardware 370. For example, the access locks 460 may be opened by a signal from the IC 365 or the processor 102 (or 805A or 805B from FIGS. 9A and 9B) or the control logic 420. The access locks 460 may be opened in response to an SMI# or in response to the processor 102 or 805 entering SMM. Additional information on the access locks 460 may be obtained from one or more of the methods 1600A-1600C described below with respect to FIGS. 16A-16C.

The TCO counter (or timer) 430 may include a programmable timer, such as a count-down timer, that is used to detect a lock-up of the computer system 100. Lock-up may be defined as a condition of the computer system 100 where one or more subsystems or components do not respond to input signals for more than a predetermined period of time. The input signals may include internal signals from inside the computer system 100 or signals from outside the computer system 100, such as from a user input device (e.g. keyboard, mouse, trackball, biometric device, etc.). It is also noted that the lock-ups may be software or hardware in nature. According to various aspects of the present invention, the TCO counter 430 may be programmed and read from inside SMM. The TCO counter 430 is preferably programmed with value less than a default duration for the kick-out timer 407. In one embodiment, the TCO timer 430 generates an SMI# upon a first expiration of the TCO timer 430, and the TCO timer 430 generates a reset signal for the computer system upon a second, subsequent expiration of the TCO timer 430.

In one embodiment, the TCO timer 430 may be accessed by the computer system 100 or software running in the computer system 100 for the computer system 100 to recover from lock-ups when the computer system is not in SMM. In another embodiment, the TCO timer 430 may be accessed by the computer system 100 both in and out of SMM.

The monotonic counter 435A comprises a counter, preferably at least 32 bits and inside the RTC battery well 125, which updates when the value stored in the monotonic counter 435A is read. The monotonic counter 435A is configured to update the value stored to a new value that is larger than the value previously stored. Preferably, the new value is only larger by the smallest incremental amount possible, although other amounts are also contemplated. Thus, the monotonic counter 435A may advantageously provide a value that is always increasing up to a maximum or rollover value. Additional details may be found below with respect to FIGS. 8, 12, and 13.

The scratchpad RAM 440 includes one or more blocks of memory that are available only while the computer system 100 is in certain operating modes, such as SMM. It is also contemplated that other sub-devices of the security hardware 370 may use the scratchpad RAM 440 as a private memory. One embodiment of the scratchpad RAM 440 includes 1 kB of memory, although other amounts of memory are also contemplated. In one embodiment, the scratchpad RAM is open at reset to all or most of the computer system 100, while in another embodiment, the scratchpad RAM is inaccessible while the computer system is booting.

The random number generator (RNG) 455 is configured to provide a random number with a number of bits within a predetermined range. In one embodiment, a new random number with from 1 to 32 bits in length is provided in response to a request for a random number. It is noted that restricting access to the RNG, such as only in SMM, may advantageously force software to access the RNG through a standard API (application programming interface), allowing for increased security and easing hardware design constraints. Additional details may be found below with respect to FIGS. 14 and 15.

The OAR locks 450 may include a plurality of memory units (e.g. registers), which include associated programming bit (or lock bits) that lock the memory (or memories) used to store BIOS information or other data, for example, BIOS ROM 355 and SMM ROM 550 in FIGS. 7A and 7B below. Each memory unit may have, by way of example, three lock bits associated with it. In one embodiment, four 8-bit registers may store the lock bits for each 512 kB ROM-page, one register for every two 64-kB segment. With sixteen blocks of four registers, a maximum of 8 MB of ROM may be locked. Addressing may be as follows: