System management memory consistency check

Abstract

In one example, a system includes a firmware controller to initiate an SM execution mode of the system. The firmware controller scans a memory for process pool tags. The firmware controller compares the process pool tags with a set of operating system process pool tags and detects a consistency difference between the process pool tags and the set of operating system process pool tags. The firmware controller exits the SM execution mode of the system.

Description

Background Art

[0001] The firmware controller provides support for booting the operating system. The firmware controller provides hardware and low-level driver initialization before handing over system control to the operating system. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Figure 1 A system for managing memory consistency checking using a system according to an example is illustrated;

[0003] Figure 2 is a block diagram of memory allocation for system management memory consistency checking according to an example;

[0004] Figure 3 is a flowchart illustrating a method of managing memory consistency detection using a system according to an example of the present disclosure; and

[0005] Figure 4 is a diagram illustrating a method at a computing device for supporting system management memory consistency checking according to an example. DETAILED DESCRIPTION

[0006] In computer systems, malware injection techniques have been developed to mimic or mask resources within the operating system to avoid detection. Malware can take the form of non-malicious applications and hide resources from the operating system. Malware applications may hide their corresponding process pool information from the operating system, thereby hiding themselves from the host operating system and antivirus applications that rely on the operating system. A system for system management memory consistency detection is disclosed herein.

[0007] The examples described herein provide a method for detecting system management memory consistency. In one example, a system may include an SM memory segment, an operating system memory segment, and a firmware controller. The firmware controller may be configured to enter an SM execution mode. During the SM execution mode, the firmware controller may retrieve a process pool tag set from the operating system memory segment. The firmware controller may compare the process pool tag set with a second process pool tag set stored in the SM memory segment. The firmware controller may detect consistency differences based on the comparison and generate a system interrupt. Then, the firmware controller exits the SM execution mode.

[0008] Figure 1A system 100 utilizing system management memory consistency detection according to an example is illustrated. The system 100 may include a firmware controller 102, a memory 104, an SM memory segment 106, and an operating system (OS) memory segment 108. The system 100 may be implemented within a computing device, including but not limited to a laptop personal computer, a desktop personal computer, a server, or a mobile handheld device. The firmware controller 102 may include a UEFI implementation for setup and configuration of the system 100 hardware. The firmware controller 102 may be communicatively coupled to a communication channel (not shown) to interface with the memory 104. In addition, the firmware controller 102 may be communicatively coupled to the CPU. The firmware controller 102 may include logic to execute programming instructions to support comparator operators and memory access reads and writes. The firmware controller 102 may include a system management interrupt (SMI) handler. The SMI handler is a routine executed when the operating system instantiates an SMI. The SMI handler may include logic for scanning the OS memory segment 108 and locating a process pool tag. The process pool tag may vary across operating systems, however, the information in the tag allows the location and type of the process to which it corresponds to be interpreted. The process pool tag can allow interpretation of data structures in memory corresponding to a process. The process pool tag can be mapped to a specific driver file within the operating system to identify the memory activity (e.g., allocation, deallocation, etc.) of the driver. The operating system can provide a mapping of a specific process pool tag to a corresponding driver file. The process pool tag can correspond to, but is not limited to, operating system constructs including processes, threads, mutexes, driver objects, and kernel modules.

[0009] The memory 104 supports both the firmware controller 102 and the CPU (not shown). When the operating system is executing, the memory 104 provides random access to the storage device for the firmware controller 102 and the CPU. The memory 104 may include, but is not limited to, any form of dynamic random access memory (RAM), including synchronous dynamic random access memory (SDRAM) and high bandwidth memory (HBM). In a personal computer implementation, the memory 104 may be a dual in-line memory module (DIMM). The memory 104 may support read and write access to the firmware controller 102.

[0010] SM memory segment 106 may be a reserved memory segment in memory 104. During booting of system 100, firmware controller 102 may allocate a segment of memory for SM execution mode. SM memory segment 106 may include one or more reserved addressable memories to support context switching of the CPU. In addition, firmware controller 102 may reserve a portion of SM memory segment 106 for use in detecting operating system memory consistency.

[0011] An operating system (OS) memory segment 108 may include a portion of non-reserved memory 104. OS memory segment 108 may include logical data structures used for operation and protection of the operating system. OS memory segment 108 may have increased permission requirements for security.

[0012] The firmware controller 102 in the computer system initializes the hardware and loads the device driver. When the hardware "boots" is completed, the firmware controller transfers control to the operating system.

[0013] During the boot process, the firmware controller allocates system management random access memory (SMRAM) as part of the SM memory segment 106. The SMRAM has a base address corresponding to the allocated area, and an offset based on the available central processing unit (CPU) processing core. In typical operation, during system management mode (SMM) operation, the SMRAM can be used to store CPU registers or CPU context. The offset plus the base address can be used to define the SMRAM area for the CPU context in a multi-CPU core system. The SMRAM can be reserved for SMM operations and can be inaccessible to the host operating system. SMM operations can be called during operating system execution to provide low-level device management, such as managing thermal performance.

[0014] Since the operating system and subsequent user applications cannot access the SMRAM, the firmware controller 102 can use the SMRAM for security. In one implementation, the firmware controller 102 can generate a series of cryptographic keys for authentication purposes. The cryptographic keys can be stored in the SMRAM and utilized during an SMI event, and thus may be inaccessible to the operating system.

[0015] Figure 2 2 is a block diagram 200 of memory allocation for system management memory consistency detection according to an example. The memory 104 may include the SM memory segment 106 and the OS memory segment 108 as previously described. The OS memory segment 108 may include a set of process pool tags 204 for the currently executing process. The process pool tags 204 may be included in a memory management data structure utilized by the operating system to track memory allocated and freed by processes running under the control of the operating system. The process pool tags 204 may be present in the OS memory segment 108 and may be identifiable by a descriptor written in memory to identify a memory pool table.

[0016] User space memory 206 may provide read and write support for the execution of user applications, separate from OA memory segment 108. User space memory 206 may be used for common user applications, such as web browsers and word processors. The access rights of user space memory 206 are less restrictive than those of OS memory segment 108. SM memory segment 106 may include higher access rights than OS memory segment 108. In some implementations, the operating system may not be aware of the allocation of SM memory segment 106. SMI handlers may be able to access the entire memory 104 in SM mode.

[0017] In some implementations, the operating system may allocate a portion of the OS memory segment 108 for use during operations following an SMI event. In addition, the operating system may allocate a portion of the user space memory 206 for use during operations following an SMI event. In another implementation, a user space application may allocate a portion of the user space memory 206 to which the application has access rights. The allocated memory in the OS memory segment 108 or in the user space memory 206 may be used as a high-speed communication channel for the operating system or application to communicate with the firmware controller prior to an SMI event. In one implementation, the allocated memory space may be at an address previously known to the firmware controller 102. In one implementation, the allocated memory in the OS memory segment 108 or in the user space memory 206 may be used to securely transfer any data between the firmware controller 102 and the SMI initiation process.

[0018] Figure 3 302 is a flowchart illustrating a method of utilizing a system to manage memory consistency detection according to an example of the present disclosure. Figure 1 and Figure 2 References to components in can be used to describe the execution of this method.

[0019] At 302, the firmware controller 102 initiates the SM execution mode. The firmware controller 102 receives a special instruction that calls an SMI and changes the operating context of the system to the system management execution mode. The current context of the CPU can be written to the SMRAM in the SM memory segment 106 to maintain the operating state of the computer system for returning to normal execution. When changing the context to the SM execution mode, the firmware controller 102 executes the SMI handler. The SMI handler can be written as a piece of logic encoded into the firmware controller itself. In some implementations, the SMI handler can be code that can be programmed into non-volatile memory. In a secure communication implementation, the process that instantiates the SMI event can copy the cryptographic key to the allocated OS memory segment 108 or user space memory 206 known to the firmware controller 102. When entering the SM execution mode, the firmware controller 102 can authenticate the cryptographic key copied to the allocated OS memory segment 108 or user space memory 206 known to the firmware controller 102. The firmware controller 102 can compare the cryptographic key with the generated cryptographic key stored in the SMRAM to authenticate the process that generated the SMI event. After verifying the cryptographic key, the firmware controller 102 can verify that the process pool tag set as reported by the operating system exists. The firmware controller 102 can additionally verify any data within the process pool tag structure to confirm that the SMI calling process has not been emptied by the process. The operating system process pool tag can be generated by an application programming interface call to the OS and then stored in an allocated OS memory segment 108 or user space memory 206 known to the firmware controller 102. In another embodiment, the operating system process pool tag may include a predefined list of known non-malicious processes. In another implementation, the operating system process pool tag can be detected by the firmware controller 104 scanning the memory 104 during the SM execution mode of the system. In another example, during the SMI execution mode, the firmware controller 102 can securely inject the cryptographic key directly into the memory space of the SMI initiation process. The cryptographic key can be used by the SMI initiation process to authenticate itself to the firmware controller 102.

[0020] At 304, the firmware controller 102 scans the memory 104 for process pool tags. The firmware controller 102 may execute an SMI handler to search for process pool tags. The search may include an algorithm that looks for certain patterns that indicate memory pool allocations in the memory 104. Upon discovering memory pool allocations, the firmware controller 102 may further scan the memory pool allocations for process pool tags corresponding to processes executed prior to the context switch. The firmware controller may store any discovered process pool tags in an allocated portion of the SM memory segment 106 for processing. In another embodiment, the firmware controller 102 may store any discovered process pool tags in an allocated OS memory segment 108 or user space memory 206 known to the firmware controller 102.

[0021] At 306, the firmware controller 102 compares the signature of the process pool tag with a set of signatures of known operating system process pool tags. The firmware controller 102 may generate a signature for the discovered process pool tag based on the type, size, and location of the discovered process pool tag to verify that the discovered process pool tag is known to the operating system. Utilizing the signature may enable the firmware controller 102 to more efficiently compare process pool tags. The firmware controller 102 may compare the discovered process pool tag(s) with a set of known process pool tags provided by the operating system prior to the SMI. The operating system may be directed through an application programming interface to output all process pool information it knows about. In one example, the output may include writing the process pool information to an allocated OS memory segment 108 or user space memory 206 that the firmware controller 102 knows about and can access. The firmware controller 102 directly compares the discovered process pool tag with the process pool tag written to the user space memory 206. Since the firmware controller 102 may be able to access all memory 104, it may be possible for the operating system to directly provide a record of its known process pool tags in the OS memory segment 108. In implementations in which firmware controller 102 does not detect a mismatch, firmware controller 102 may securely provide cryptographic keys with a mitigated risk of interception by a malicious process.

[0022] At 308, the firmware controller 102 detects a consistency difference based on the comparison. A consistency difference can be detected in the event that the discovered process pool tag does not exist in the list of known process pool tags. In another example, there may be a mismatch between the detected process pool tag and the list of known process pool tags. The mismatch may include a process pool tag that exists in the list of known process pool tags, however, parameters associated with the detected process pool tag are inconsistent, which may indicate manipulation of the process pool tag. A consistency difference can be evidence of malware execution, where the malware alters the operating system memory to disguise itself. In some malware infections, the malware can change its corresponding process pool tag within the operating system so that it can still execute, but will not be visible to software that utilizes the operating system application programming interface (API) to capture the executed process.

[0023] At 310, the firmware controller 102 writes a consistency difference data structure to the allocated memory. The consistency difference data structure may be a data structure indicating a difference (e.g., a process pool tag that is not reported by the application). In addition, the consistency difference data structure may also include a cryptographic key utilized by the firmware controller 102 to update the SMI event initiating process. In one implementation, a data structure including information related to consistency differences may be stored in a previously allocated OS memory segment 108 or user space memory 206. In some implementations, the firmware controller 102 may rotate the cryptographic key to the process initiating the SMI event. The firmware controller 102 may include a new cryptographic key for the process having a data structure written to a previously allocated OS memory segment 108 or user space memory 206. The advantage of this method is that a cryptographic key with a minimal chance of interception is provided to the process initiating the SMI event because the SMI event is uninterruptible and execution returns to the initiating process.

[0024] At 312, the firmware controller exits the SM execution mode. The firmware controller 102 may execute a resume command for a compatible platform architecture. In the event that the firmware controller 102 stores a data structure including information related to the consistency difference in a previously allocated OS memory segment 108 or user space memory 206, the consistency difference information may be extracted by the SMI initiation process during normal execution. The firmware controller 102 may copy the CPU context information from the SMRAM back to the appropriate CPU registers to resume execution. With this approach, the SMI event may be uninterruptible, and the calling application receives the data in the previously allocated OS memory segment 108 or user space memory 206 without the possibility of malware interception. Data provided from the SM execution mode to a process outside the SM execution mode allows the operating system or another application (such as an antivirus application) to take action. Similarly, if the firmware controller 102 provides a new cryptographic key, the SMI event initiation process may then extract it.

[0025] Figure 4 4 is a diagram illustrating a method for supporting system management memory consistency detection at a computing device according to an example. The computing device 400 depicts the firmware controller 102 and the memory device 404, and as an example of the computing device 400 performing its operations, the memory device 404 may include instructions 406-420 executable by the firmware controller 102. Therefore, it can be said that the memory device 404 stores program instructions that, when executed by the firmware controller 102, implement the components of the computing device 400. The executable program instructions stored in the memory device 404 may be similar to those described in reference to Figure 3 The method described, and by way of example may include instructions 406 for generating a cryptographic key set, instructions 408 for initiating an SM execution mode, instructions 410 for calling an interrupt handler, instructions 412 for verifying that a first cryptographic key is present within the cryptographic key set, instructions 414 for scanning a memory for process pool tags, instructions 416 for comparing the process pool tags with an operating system pool tag, instructions 418 for detecting consistency differences based on the comparison, and instructions 420 for exiting the SM execution mode.

[0026] Memory device 404 generally represents any number of memory components capable of storing instructions that may be executed by firmware controller 102. Memory device 404 is non-transitory in the sense that it does not encompass transitory signals, but instead consists of at least one memory component configured to store relevant instructions. Figure 1, the memory device 404 is a distinct non-volatile memory storage device separate from the memory 104. As a result, the memory device 404 may be a non-transitory computer-readable storage medium. The memory device 404 may be implemented in a single device or distributed across devices. In addition, the memory device 404 may be fully or partially integrated in the same device as the firmware controller 102, or it may be separate but accessible to the device and the firmware controller 102.

[0027] In one example, program instructions 406-420 may be part of an installation package that, when installed, may be executed by firmware controller 102 to implement components of computing device 400. In this case, memory device 404 may be a portable medium, such as a compact disc (CD), a digital video disc (DVD), or a flash drive or a memory from which an installation package maintained by a server may be downloaded and installed. In another example, program instructions may be part of an already installed (one or more) application. In another example, program instructions 406-420 may include a binary image configured to be stored or written to a non-volatile memory device. Here, memory device 404 may include an integrated memory, such as a hard disk drive, a solid-state drive, etc.

[0028] References to "example" or similar language in the specification mean that a particular feature, structure, or characteristic described in conjunction with the example is included in at least one example, but not necessarily in other examples. Various instances of the phrase "in one example" or similar phrases in various places in the specification do not necessarily all refer to the same example.

Claims

1. A system comprising: System Management (SM) memory segment; operating system memory segments; A firmware controller, communicatively coupled to the SM memory segment and the operating system memory segment, for: Initiate the SM execution mode of the system; Scanning memory for process pool tags, wherein the process pool tags are present in operating system memory segments; comparing the process pool tag to the operating system's set of process pool tags; detecting consistency differences between the process pool tag and the operating system process pool tag set based on the comparison; and Exit the system's SM execution mode, The process pool tag is included in a memory management data structure utilized by an operating system to track memory allocated and freed by processes running under control of the operating system.

2. The system of claim 1, wherein the consistency difference corresponds to a mismatch between a process pool tag and an operating system set of process pool tags.

3. The system of claim 1, wherein the set of operating system process pool tags is stored in a memory.

4. The system of claim 3, wherein the set of operating system process pool tags comprises output of an operating system application programming interface call. 5 . The system of claim 1 , wherein the firmware controller further calls a handler upon entering SM execution mode.

6. A method comprising: Initiate the system management (SM) execution mode of the system; Scanning memory for process pool tags, wherein the process pool tags are present in operating system memory segments; comparing the signature of the process pool tag with the signature set of the operating system's process pool tags; Detecting consistency differences between the process pool tag and the operating system process pool tag set based on the comparison; writing the consistency difference data structure to the allocated memory; as well as Exit the system's SM execution mode, The process pool tag is included in a memory management data structure utilized by an operating system to track memory allocated and freed by processes running under control of the operating system.

7. The method of claim 6, wherein the consistency difference corresponds to a mismatch between a process pool tag and an operating system set of process pool tags.

8. The method of claim 6, further comprising storing the cryptographic key set in a system management random access memory of the system during the SM execution mode.

9. The method of claim 6, wherein the set of operating system process pool tags is stored in memory and comprises output of operating system application programming interface calls.

10. The method of claim 6, further comprising calling a handler upon entering SM execution mode.

11. A computer readable medium comprising a memory having instructions which, when executed, cause a firmware controller of a system to: generating a set of cryptographic keys for storage in a system management random access memory (SMRAM); Initiate the system management (SM) execution mode of the system; Call the interrupt handler; verifying that the first cryptographic key exists with the set of cryptographic keys; Scanning memory for process pool tags, wherein the process pool tags are present in operating system memory segments; comparing the process pool tag to the operating system's set of process pool tags; detecting consistency differences between the process pool tag and the operating system process pool tag set based on the comparison; and Exit the system's SM execution mode, The process pool tag is included in a memory management data structure utilized by an operating system to track memory allocated and freed by processes running under control of the operating system.

12. The computer-readable medium of claim 11, wherein the consistency difference corresponds to a mismatch between a process pool tag and an operating system set of process pool tags.

13. The computer-readable medium of claim 11, wherein when executed, the instructions further cause the firmware controller to store the second cryptographic key in a data structure in the allocated memory.

14. The computer readable medium of claim 11, wherein the set of operating system process pool tags is stored in memory and comprises output of an operating system application programming interface call.

15. The computer-readable medium of claim 11, wherein when executed, the instructions for comparing cause the firmware controller to: generating a signature based on the process pool tag; and A determination is made as to whether a signature exists with a set of signatures corresponding to a set of operating system process pool tags.

Images