Patent Application
20090144332
1. Field of the Invention
This application relates to determining software integrity in computer systems and more particular to determining software integrity in a secure and reliable manner using techniques less likely to be targeted by and more resilient to malicious software attacks.
2. Description of the Related Art
As the number of malicious software attacks continues to rise, the information technology (IT) industry must place more resources into finding ways to stop the attacks. One of the most common methods of preventing malicious software attacks is the use of virus and worm scanner software. A problem with this approach is that the virus and worm scanning software may themselves be the target (and have in the past) of malicious software attacks and become an agent of spreading the malicious software. Detecting this type of malicious attack is extremely difficult because the malicious software now controls the reporting mechanism. This type of attack is potentially very dangerous as the virus/worm scanner typically can access nearly every file in the file system during normal operation at which time new infections can be initiated widely on the system.
In virtualization technology, whose use is rapidly expanding, a new type of super trusted software call a hypervisor resides between the operating system(s) and system hardware. The hypervisor may be undetectable to the operating system and inaccessible to any type of traditional malicious software detection mechanism. However, studies and demonstrations have shown the hypervisor to also be a potential target for malicious software attacks.
Additionally, as hypervisor usage becomes more common to support server consolidation, the hypervisor itself becomes a new single point of failure. Because the hypervisor resides between the operating system(s) and the hardware, there is no good way to measure the health of the hypervisor from normal software. If the hypervisor fails, the monitoring software will be disabled as well.
Accordingly, a new approach to determining software integrity, both its health generally and also with respect to possible attack, is provided while remaining outside of a software attack vector. Use of the new approach can provide increased platform security and reliability.
In an embodiment, a method is provided in which management controller supplies a processor with a command via a sideband interface on the processor. Responsive to the command, the processor reads storage locations accessible by the processor and supplies the contents of the storage locations to the management controller via the sideband interface. The management controller then evaluates the integrity of software associated with the storage locations by comparing a digital signature associated with the software to a known digital signature.
In another embodiment, a computer system is provided that includes a processor having a sideband interface and storage coupled to the processor. A management controller is coupled to the processor through the sideband interface. The processor includes a microcode engine responsive to communication from the sideband interface to cause the processor to read data from storage locations in the storage and provide the data to the management controller through the sideband interface. The data is associated with the software to be evaluated. The management controller is responsive to the data received from the processor to determine integrity of the software associated with the data read from the storage by comparing a digital signature determined from the data and a known digital signature.
The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.
Note that the use of the same reference symbols in different drawings indicates similar or identical items.
Referring to
In contrast, as shown in
The system of
Referring now to
In an embodiment, the communication link (APML) 102 includes clock, data, and an alert signal line. The alert signal line allows the processor to signal the management controller of the occurrence an event. The link 102 may be a point-to-point link between the management controller 101 and the processor 201. The link may be an SMBus or other communication link and may run at various frequencies, e.g., 100 KHz, 400 KHz, 3.4 MHz, or other clock frequency suitable for the particular application. The communication link 102 is used to supply the APML hardware with commands and data and to retrieve data associated with the command, e.g., as a result of a read operation, and provide that data to the management controller 101 for evaluation.
The management controller 101 may be coupled through a network interface card (NIC) 215 to network 217 and through network 217 to an administrator 219. The administrator can provide the management controller 101 with information related to processor 201 through the network as described further herein. The administrator can utilize APML's capabilities to read/write processor state over the network.
The processor 201 includes three address pins 221 that allow the link 102 to select up to eight different processors on a single APML bus segment.
Referring to
The microcode engine 207 receives the commands from the APML block 205 and executes those commands while the microprocessor maintains normal operation. The microcode engine, which is conventional, executes the APML commands at appropriate instruction boundaries of regular instructions executed by the microprocessor. The APML commands function similarly to an interrupt mechanism in that the normal flow of microprocessor instructions is halted briefly while the microcode executes the APML command and then the normal microprocessor instructions resume execution at the conclusion of the APML command.
Referring now to
In one embodiment, in order to obtain an appropriate digital signature for comparison, the management controller reads the trusted software (or a subset thereof) from an appropriate range of system memory in 403. That memory range may be a subset of the entire memory range of the trusted software that is sufficient to ensure the integrity of the trusted software. The management controller reads the trusted software (or portion thereof) by sending an appropriate command over the sideband interface, which causes the processor in response to read storage locations accessible by the processor and provide the data in the storage locations to the management controller. The management controller can then generate a digital signature of the software according to an appropriate encryption algorithm for later use. In other embodiments, a digital signature is provided to the management controller by the administrator over the network. That digital signature provided by the administrator may come from the vendor of the software being monitored.
During normal system operation, at 407 the management controller reads trusted software from the memory range containing the software to be analyzed by sending appropriate commands through the sideband interface to the processor. At 409 the management controller generates a digital signature from the software that was read and evaluates the integrity of software associated with the memory range by comparing the digital signature to a known signature, either previously generated by the management controller, provided to the management controller through the network, or otherwise obtained by the management controller. The digital signature may be generated by a hash algorithm or other appropriate encryption algorithm. In 411, the digital signatures are compared. If the signatures do not match, in 413 the management controller may report the problem to the administrator, take action to correct, and/or take action to prevent further malicious attacks. If the signatures match, the flow returns to 407 where the management controller can again read the trusted software from the appropriate memory range.
In an embodiment, the management controller periodically evaluates the integrity of trusted software and thus may return to 407 on a periodic basis through a delay 414. The frequency with which the management controller evaluates the trusted software may be programmable. Thus, the length of the delay 414 can be programmable. As stated earlier, the trusted software may be resident in system memory, on an I/O device such as a hard drive, or on non-volatile memory within the system. The trusted software may be a hypervisor, operating system software, virus/worm scanner, firewall software, or manageability software, or any other software whose integrity it would be beneficial for the management controller to ascertain and/or monitor. This approach to evaluating the health of the software allows evaluation of operating system or hypervisor software during runtime that may be otherwise difficult to evaluate if it becomes unhealthy. It further allows evaluating the integrity using a mechanism that is less likely to be the target of a malicious software attack and is more resilient to attack. Note that while
The description of the invention set forth herein is illustrative, and is not intended to limit the scope of the invention as set forth in the following claims. Other variations and modifications of the embodiments disclosed herein may be made based on the description set forth herein, without departing from the scope and spirit of the invention as set forth in the following claims.
