Secure boot of computing devices

Abstract

Techniques for secure booting of Unified Extensible Firmware Interface (UEFI)-compliant devices are described. In one example, execution of a driver associated with a hardware component of a computing device can be detected during boot of the computing device. Based on the detection, a first driver hash of the UEFI's system table can be calculated, where the system table is a data structure that stores configuration details of the computing device and UEFI services. Thereafter, based on detecting completion of the driver's execution, a second driver hash of the system table can be calculated. The first driver hash and the second driver hash can then be compared to determine tampering with the UEFI's system table.

Description

Background Art

[0001] Computing devices include multiple hardware components that require configuration before operation. Modern system firmware, such as the Unified Extensible Firmware Interface (UEFI), allows drivers associated with such hardware components to be executed during the booting of the computing device. Such execution of the drivers facilitates the configuration and initialization of the hardware components during the booting of the computing device. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The detailed description is provided with reference to the accompanying drawings, in which:

[0003] Figure 1 A computing device for determining tampering with a Unified Extensible Firmware Interface (UEFI) according to an example of the present subject matter is illustrated;

[0004] Figure 2 illustrates a computing device for determining tampering with UEFI according to another example of the present subject matter;

[0005] Figure 3 A method for determining tampering with UEFI according to an example of the present subject matter is illustrated;

[0006] Figure 4 A method for secure booting of a UEFI-compliant computing device according to an example of the present subject matter is illustrated; and

[0007] Figure 5 A system environment implementing a non-transitory computer-readable medium for determining tampering with a UEFI in a computing device is illustrated according to an example of the present subject matter. DETAILED DESCRIPTION

[0008] Generally speaking, the Unified Extensible Firmware Interface (UEFI) ensures secure booting of computing devices by validating drivers associated with various hardware components before execution. Driver validation is performed by verifying a digital signature associated with the driver, which is linked to the driver during its development and indicates the driver's authenticity.

[0009] Drivers associated with hardware components are generally available in a binary format without any associated source code, where the binary format of the driver is verifiable by a digital signature accompanying the driver. Therefore, if the driver's source code is tampered with, for example by malicious code during driver development, and is thereafter digitally signed, the integrity of the driver may be impossible to ascertain. Consequently, malicious code in the driver may compromise the security of the UEFI and user data stored on the computing device.

[0010] According to example implementations of the present subject matter, techniques for secure booting of UEFI-compliant computing devices are described.

[0011] In operation, when a computing device is booted, the execution of a driver for configuring a hardware component of the computing device is detected. Based on this detection, a first hash of the UEFI system table is calculated, where the system table is a data structure that stores configuration details of the computing device and various UEFI services. The driver is then allowed to execute to configure the hardware component for operation. Once the configuration of the hardware component is complete, a second hash of the system table is calculated and compared to the first hash. It is then determined whether the first hash and the second hash are equal.

[0012] If the first hash and the second hash are not equal, it can be determined that the system table has been tampered with. Therefore, a notification indicating tampering with the system table can be issued. In such a situation, the modifications made to the system table can be rolled back, and the driver can be blocked from any further execution. Therefore, during a subsequent boot of the computing device, execution of the driver can be blocked, and the computing device can be booted without initializing the hardware components associated with the driver.

[0013] On the other hand, if the first hash and the second hash are found to be equal, it can be determined that no modifications have been made to the system table. In such a situation, the computing device can continue to boot normally.

[0014] Thus, the above-described techniques ensure the integrity of the contents of the UEFI system table by detecting any modifications made to the UEFI system table by drivers associated with hardware components of the computing device. Furthermore, blocking further execution of the driver prevents the execution of malicious code during subsequent boots of the computing device, thereby ensuring a secure boot of the computing device.

[0015] refer to Figures 1 to 5 The above technology is further described. It should be noted that the description and the figures merely illustrate the principles of the present subject matter in conjunction with the examples described herein and should not be construed as limiting the present subject matter. Therefore, it is to be understood that various arrangements that embody the principles of the present subject matter, although not explicitly described or shown herein, may be designed. In addition, all statements herein that record the principles, aspects, and implementations of the present subject matter, as well as specific examples thereof, are intended to encompass their equivalents.

[0016] Figure 1 Illustrated is a computing device 100 for determining tampering with a Unified Extensible Firmware Interface (UEFI) according to an example of the present subject matter. Examples of computing device 100 may include, but are not limited to, laptop computers, desktop computers, tablets, and smartphones.

[0017] The computing device 100 may include a plurality of hardware components that may be initialized during pre-operating system (OS) initialization of the computing device 100. In addition, each of the plurality of components may correspondingly have a driver associated therewith, wherein each driver may correspond to a plurality of callback functions.

[0018] In an illustrative example, a first driver associated with a first hardware component of computing device 100 can be configured to publish data to an Advanced Configuration and Power Interface (ACPI) table. In one example, the ACPI table can store hardware configuration information and power management information for computing device 100. In this example, the data to be published to the ACPI table becomes available after the execution of a second driver associated with a second hardware component of computing device 100. In such a scenario, the first driver can register a callback function to monitor the availability of the data. When the availability of the data is determined to be true, an event can be triggered to invoke the callback function of the first driver. Consequently, the callback function of the first driver can be executed, and the data can be published in the ACPI table.

[0019] Computing device 100 may include a detection engine 102 to determine execution of callback functions of drivers associated with hardware components of computing device 100. During pre-OS initialization of computing device 100, execution of callback functions may be detected in a driver execution environment (DXE) phase.

[0020] Based on detecting execution of the callback function, the hash engine 104 of the computing device 100 may calculate a first callback function hash of a system table of the UEFI, where the system table is a data structure that stores configuration details of the computing device and various UEFI services.

[0021] The hash engine 104 may then detect completion of execution of the callback function. Based on this detection, the hash engine 104 may calculate a second callback function hash for the driver.

[0022] The determination engine 106 of the computing device 100 can then compare the first callback function hash with the second callback function hash to determine whether the system table has been tampered with. Thus, any modifications made to the system table due to the execution of the callback function can be identified, thereby ensuring the integrity of the content stored in the system table.

[0023] Figure 2 A computing device 100 for determining tampering with UEFI according to another example of the present subject matter is illustrated. As described earlier, examples of computing device 100 may include, but are not limited to, desktop computers, laptop computers, smartphones, and tablets.

[0024] The computing device 100 may include a processor 202 and a memory 204 coupled to the processor 202. The functions of the various elements shown in the figures, including any functional blocks labeled "processor(s)", may be provided using dedicated hardware as well as hardware capable of executing instructions. When provided by a processor, these functions may be provided by a single dedicated processor, a single shared processor, or multiple individual processors, some of which may be shared. In addition, the explicit use of the term "processor" should not be interpreted as referring exclusively to hardware capable of executing instructions, and may implicitly include, but is not limited to, digital signal processor (DSP) hardware, network processors, application specific integrated circuits (ASICs), and field programmable gate arrays (FPGAs). Other standard and / or custom hardware may also be coupled to the processor 202.

[0025] Memory 204 may include any computer-readable media including, for example, volatile memory (eg, random access memory (RAM)) and / or nonvolatile memory (eg, ROM, EPROM, flash memory, etc.).

[0026] Additionally, computing device 100 may also include engine(s) 206 , which may include detection engine 102 , hashing engine 104 , determination engine 106 , and modification engine 208 .

[0027] In one example, the engine(s) 206 can be implemented as hardware, firmware, or a combination thereof. In the examples described herein, such a combination of hardware and firmware can be implemented in a number of different ways. For example, the engine's firmware can be processor-executable instructions stored on a non-transitory machine-readable storage medium, and the engine's hardware can include processing resources (e.g., implemented as a single processor or a combination of multiple processors) to execute such instructions.

[0028] According to an implementation of the present subject matter, a machine-readable storage medium may store instructions that, when executed by a processing resource, implement the functionality of the engine. In such an implementation, computing device 100 may include a machine-readable storage medium for storing instructions and a processing resource for executing the instructions.

[0029] In one example of the present subject matter, the machine-readable storage medium may be located within computing device 100. However, in other examples, the machine-readable storage medium may be located at a different location, but accessible to computing device 100 and processor 202.

[0030] The computing device 100 may further include data 210, which serves as a repository for, among other things, data that may be acquired, processed, received, or generated by the engine(s) 206. The data 210 may include hashed data 212, determined data 214, and other data 216. In one example, the data 210 may be stored in the memory 204.

[0031] In one example implementation of the present subject matter, pre-OS initialization for a computing device with UEFI is divided into multiple phases: the Security (SEC) phase, the Pre-EFI (PEI) phase, the Driver Execution Environment (DXE) phase, the Boot Device Selection (BDS) phase, and the Transient System Load (TSL) phase. Pre-OS initialization may begin with the SEC phase, where initial operations may be performed to ensure the integrity of the firmware used to initialize the processor, chipset, and motherboard after the computing device 100 is powered on or rebooted. Pre-OS initialization may then proceed to the PEI phase, which provides a standardized method for loading and invoking specific initial configuration routines for the processor, chipset, and motherboard of the computing device 100. The primary purpose of the PEI phase is to determine the boot path for the computing device 100 and to initialize and allocate a minimum amount of RAM and persistent storage containing the DXE foundation and architecture protocols to allow for the instantiation of the DXE phase.

[0032] During the DXE phase, initialization of various hardware components of the computing device 100 is performed. Initialization of the various hardware components may be facilitated by executing different drivers associated with each of the various hardware components. In one example, discovery and execution of the different drivers is facilitated by a DXE dispatcher.

[0033] In an example of the present subject matter, the DXE dispatcher can be coupled to the detection engine 102, where the detection engine 102 detects execution of a driver associated with a hardware component of the computing device 100 during the DXE phase. The driver can be one of a DXE driver and a UEFI driver.

[0034] Based on the detection performed on the driver by the detection engine 102, the hash engine 104 can generate a system management interrupt (SMI), wherein the generation of the SMI causes the triggering of the system management mode (SMM) within the DXE phase. The triggering of SMM can save the state of the processor 202 in a secure area of ​​RAM designated as system management RAM (SMRAM).

[0035] Additionally, hash engine 104 may calculate a first driver hash of a system table of the UEFI based on detecting execution of the driver and may store the first driver hash in hash data 214. As explained earlier, the system table is a data structure that stores configuration details of the computing device and various UEFI services.

[0036] Various UEFI services can include UEFI boot services, UEFI runtime services, and protocol services. UEFI boot services and UEFI runtime services can be accessed through the UEFI boot services table and UEFI runtime services table, respectively, included in the system table. Additionally, protocol services are a set of related functions and data fields that can be used to provide software abstractions for devices such as consoles, disks, and networks.

[0037] Upon execution of the driver, a pointer to the system table may be passed to the driver. Passing the pointer to the driver allows the driver to access configuration information of the computing device along with various UEFI services to initialize hardware components associated therewith.

[0038] It will be noted that once the first driver hash of the system table is calculated and stored in hash data 214, the SMM may be terminated and the driver executed.

[0039] Once the execution of the driver is complete, the hash engine 104 may regenerate the SMI, thereby re-triggering the SMM within the DXE phase. Subsequently, the hash engine 104 may calculate the second driver hash of the system table and may store it in the hash data 214. In one example, the hash data 214 may be stored in SMRAM to prevent access to the first driver hash and the second driver hash outside of SMM.

[0040] Hash engine 104 can be further coupled to determination engine 106, where determination engine 106 can compare the first driver hash and the second driver hash of the system table and store the result of the comparison in determination data 214. In an example, determination data 214 can also be stored in SMRAM.

[0041] The first driver hash and the second driver hash can be compared to identify whether any modifications have been made to the system tables during driver execution.

[0042] If the determination engine 106 determines that the first driver hash and the second driver hash are equal, the determination engine 106 can ascertain that no modifications have been made to the system table. Subsequently, it can be determined whether the DXE scheduler has more drivers to load and execute. If no additional drivers are identified for execution, the DXE phase can end and control can be passed to a subsequent phase for loading the OS.

[0043] On the other hand, if the determination engine 106 determines that the first driver hash and the second driver hash are not equal, the determination engine 106 can determine that the execution of the driver has tampered with the UEFI system table. In such a situation, the driver may be blocked. In addition, in one example, the execution of the driver can be blocked during a subsequent boot of the computing device 100.

[0044] The modification engine 208 may then undo any modifications made to the system tables during driver execution.

[0045] Once execution of the driver is complete, the DXE scheduler may further identify whether any other drivers associated with any other components of the computing device need to be executed.

[0046] In one example, the DXE scheduler may not identify any other drivers associated with any other hardware components for execution. In such a situation, a video output device coupled to the computing device may be identified. Subsequently, a notification indicating tampering with the system table may be displayed along with details of the driver, followed by a reboot of the computing device.

[0047] In another example, the DXE dispatcher may discover and execute a callback function of another driver associated with another hardware component of the computing device 100. In the example, the detection engine 102 coupled to the DXE dispatcher may detect the execution of the callback function.

[0048] Based on this detection, the hash engine 104 may cause the triggering of the SMM. The hash engine 104 may then calculate the first callback function hash of the system table and store it in the hash data 214. Subsequently, the SMM may be terminated and the execution of the callback function may be completed.

[0049] Once the execution of the callback function is complete, the hash engine 104 may re-trigger the SMM and calculate a second callback function hash for the system table. Thereafter, the second callback function hash may be stored in the hash data 214.

[0050] The determination engine 106 may compare the first callback function hash and the second callback function hash to find out whether execution of the callback function has tampered with the system table of the UEFI.

[0051] If the determination engine 106 determines that the first callback function hash and the second callback function are equal, the determination engine 106 may determine that no modifications have been made to the system table of the UEFI.

[0052] On the other hand, if the determination engine 106 determines that the first callback function hash and the second callback function hash are not equal, the determination engine 106 can determine that the execution of the callback function has tampered with the system table. Therefore, the other driver may be blocked. Subsequently, the modification engine 208 can undo the modifications made to the system table during the execution of the callback function.

[0053] The DXE scheduler may again identify whether any other drivers associated with any other hardware components are still available for execution. In one example, the DXE scheduler may not identify any other drivers associated with any other hardware components for execution. In such a situation, it may be determined whether a video output device is coupled to computing device 100. If no video output device is found coupled to computing device 100, a notification indicating an attack on UEFI may be displayed by flashing a light-emitting diode (LED) mounted on computing device 100, followed by a reboot of computing device 100.

[0054] Figure 3 A method 300 for determining tampering with a UEFI in a computing device according to an example of the present subject matter is illustrated. Although the method 300 can be implemented in various systems, for ease of explanation, the description of the method 300 is provided with reference to the computing device 100 described above. The order in which the method 300 is described is not intended to be construed as limiting, and any number of the described method blocks can be combined in any order to implement the method 300 or an alternative method.

[0055] It is understood that the blocks of method 300 can be performed in computing device 100. As will be readily understood, the blocks of method 300 can be executed based on instructions stored in a non-transitory computer-readable medium. The non-transitory computer-readable medium may include, for example, digital memories, magnetic storage media such as magnetic disks and tapes, hard drives, or optically readable digital data storage media.

[0056] At block 302, execution of a driver associated with a hardware component of a computing device with a Unified Extensible Firmware Interface (UEFI) may be detected during bootup of the computing device. The driver may be one of a Driver Execution Environment (DXE) driver and a UEFI driver. In one example, execution of the driver may be detected by a detection engine 102 of the computing device 100.

[0057] At block 304 , a first driver hash of a system table of the UEFI is calculated, wherein the system table is a data structure that stores configuration details of the computing device and UEFI services. In one example, the hash engine 104 of the computing device 100 may calculate the first driver hash of the system table.

[0058] At block 306, completion of driver execution may be detected. In an example, the detection engine 102 may detect completion of driver execution.

[0059] At block 308 , based on detecting completion of the driver execution, a second driver hash of the system table may be calculated. In one example, the second driver hash may be calculated by the hash engine 104 .

[0060] At block 310, the first driver hash and the second driver hash can be compared to determine tampering with the UEFI's system table. In one example, the determination engine 106 can determine tampering with the UEFI's system table. If it is determined that the UEFI's system table has been tampered with, a video output device coupled to the computing device 100 can be identified, and a notification providing details of the driver can be displayed on the video output device. Otherwise, the method can proceed to loading an operating system on the computing device.

[0061] Figure 4 A method 400 for secure booting of a UEFI-compliant computing device according to an example of the present subject matter is illustrated. Although the method 400 can be implemented in various systems, for ease of explanation, the description of the method 400 is provided with reference to the computing device 100 described above. The order in which the method 400 is described is not intended to be construed as limiting, and any number of the described method blocks can be combined in any order to implement the method 400 or an alternative method.

[0062] It is understood that the blocks of method 400 can be performed in computing device 100. As will be readily understood, the blocks of method 400 can be executed based on instructions stored in a non-transitory computer-readable medium. The non-transitory computer-readable medium may include, for example, digital memories, magnetic storage media such as magnetic disks and tapes, hard drives, or optically readable digital data storage media.

[0063] At block 402, execution of a driver associated with a hardware component of a computing device may be detected during the driver execution phase (DXE) of a computing device with a Unified Extensible Firmware Interface (UEFI) during boot. The driver may be a driver execution environment (DXE) driver or a UEFI driver. Based on the detection of the driver associated with the hardware, a system management interrupt (SMI) may be generated, thereby triggering system management mode (SMM) within the DXE phase. Triggering SMM may save the state of the computing device's processor in a secure area of ​​RAM designated as system management RAM (SMRAM). In one example, the execution of the driver may be detected by a detection engine 102 of the computing device 100.

[0064] At block 404, a first driver hash of the UEFI system table is calculated, where the system table is a data structure that stores configuration details of the computing device and various UEFI services. The various UEFI services may include UEFI boot services, UEFI runtime services, and protocol services. The first driver hash may be stored in a secure area of ​​RAM. Subsequently, SMM may be terminated. In one example, the first driver hash of the UEFI system table may be calculated by the hash engine 104 of the computing device 100.

[0065] At block 406, completion of execution of the second driver hash of the system table is detected. Based on this detection, an SMI is regenerated, thereby re-triggering the SMM. Thereafter, the second driver hash of the system table is calculated and stored in SMRAM. In one example, the second driver hash can be calculated by the hash engine 104.

[0066] At block 408, the first driver hash and the second driver hash of the system table may be retrieved from the SMRAM and compared to each other. The result of the comparison may then be stored in the SMRAM, followed by termination of SMM. In one example, the determination engine 106 of the computing device 100 may compare the first driver hash and the second driver hash.

[0067] Subsequently, at block 410 , execution of a callback function of another driver associated with another hardware component of the computing device may be detected. In an example, detection of execution of the callback function may be detected by the detection engine 102 .

[0068] At block 412, based on this detection, SMM mode may be re-triggered within the DXE phase. A first callback function hash of the system table may then be calculated and stored in SMRAM, followed by termination of SMM. The callback function may then be executed.

[0069] At block 414, completion of execution of the callback function may be detected. Based on this detection, SMM may be re-triggered and a second callback function hash may be calculated. The second callback function may then be saved in SMRAM. In one example, the second callback function hash may be calculated by the hash engine 104.

[0070] At block 416, the first callback function hash may be compared to the second callback function hash. The result of the comparison may then be stored in SMRAM. In one example, the determination engine 106 may compare the first callback function hash to the second callback function hash.

[0071] At block 418, based on the result of the comparison of at least one of the first and second driver hashes and the first and second callback function hashes, it may be determined whether there has been tampering with the system table of the UEFI. In one example, the determination engine 106 may determine tampering with the system table of the UEFI.

[0072] In one example, if the first driver hash and the second driver hash are found to be unequal, it can be determined that the execution of the driver caused tampering with the system table. Therefore, the driver may be blocked. In the example described above, if the first callback function hash and the second callback function hash are found to be unequal, it can be further determined that the execution of the callback function also caused tampering with the system table. Therefore, the callback function may also be blocked. In such a situation, the execution of the callback function of the driver and the other driver may be blocked during a subsequent boot of the computing device 100.

[0073] Figure 5 A system environment 500 is illustrated that implements a non-transitory computer-readable medium 502 for determining tampering with a UEFI in a computing device according to an example of the present subject matter. In an example implementation, the system environment 500 can be a computing device, such as the computing device 100. The system environment 500 includes a processing resource 504 communicatively coupled to the non-transitory computer-readable medium 502 via a communication link 506. In an example, the processing resource 504 retrieves computer-readable instructions from the non-transitory computer-readable medium 502 and executes the computer-readable instructions.

[0074] The non-transitory computer-readable medium 502 can be, for example, an internal memory device or an external memory device. In an example implementation, the communication link 506 can be a direct communication link, such as any memory read / write interface. In another example implementation, the communication link 506 can be an indirect communication link, such as a network interface. In such a case, the processing resource 504 can access the non-transitory computer-readable medium 502 via a network 508. The network 508 can be a single network or a combination of multiple networks and can use a variety of different communication protocols.

[0075] The processing resource 504 and the non-transitory computer-readable medium 502 may also be communicatively coupled to (one or more) data sources 510. The (one or more) data sources 510 may be used to store data. In an example implementation, the non-transitory computer-readable medium 502 includes a set of computer-readable instructions for determining tampering with the UEFI in a computing device, such as the computing device 100. The set of computer-readable instructions may be accessed by the processing resource 504 via the communication link 506 and subsequently executed to authorize access to the computing device 100.

[0076] In an example, the non-transitory computer-readable medium 502 may include instructions for implementing the detection engine 102. In one example, the instructions implementing the detection engine 102 may be code executable to detect execution of a driver associated with a hardware component of the component device 100. The code may further facilitate completion of detecting execution of the driver.

[0077] The non-transitory computer-readable medium 502 may further include a set of instructions that implement the hash engine 104. In one example, the instructions that implement the hash engine 104 may be code executable to compute a hash of a system table of the UEFI at various instances, where the system table is a data structure that stores configuration details of a computing device and UEFI services.

[0078] Furthermore, the non-transitory computer-readable medium 502 may include an instruction set implementing the determination engine 106. In one example, the instructions implementing the determination engine 106 may be code executable to compare hashes calculated by the hash engine 104 to determine tampering with the system table of the UEFI.

[0079] In an example of the present subject matter, instructions implementing the detection engine 102 may detect execution of drivers associated with hardware components of the computing device in a driver execution environment (DXE) phase during pre-operating system (OS) initialization of the computing device.

[0080] Based on detecting execution of the driver, instructions implementing hash engine 104 may compute a first driver hash of the system table.

[0081] The instructions implementing the detection engine 102 can then detect the completion of the execution of the driver. Based on this detection, the instructions implementing the hash engine 104 can calculate a second driver hash of the system table. Thereafter, the instructions implementing the determination engine 106 can compare the first driver hash and the second driver hash and can store the result of the comparison in the data source(s) 510.

[0082] Subsequently, the instructions implementing the detection engine 102 may detect execution of a callback function of another driver associated with another component of the computing device.Based on the detection, the instructions implementing the hash engine 104 may calculate a first callback function hash of the system table.

[0083] The instructions implementing the detection engine 102 can then detect the completion of execution of the callback function. Based on this detection, the instructions implementing the hash engine 104 can calculate a second callback function hash. Thereafter, the instructions implementing the determination engine 106 can compare the first callback function hash to the second callback function hash and store the result of the comparison in the data source(s) 510.

[0084] Based on a comparison of at least one of the first and second driver hashes and the first and second callback function hashes, the instructions implementing the determination engine 106 can determine tampering with the system table of the UEFI. If it is determined that the first and second driver hashes do not match or the first and second callback function hashes do not match, the instructions implementing the determination engine 106 can determine that the system table has been tampered with.

[0085] In such a situation, the instructions implementing the determination engine 106 may block at least one of the callback functions of the driver and the other driver.

[0086] Blocking at least one of the callback functions of the driver and the other driver may prevent malicious code from being executed during a subsequent boot of the computing device 100 , thereby ensuring the integrity of the UEFI of the computing device 100 .

[0087] Although examples of the subject matter have been described in language specific to methods and / or structural features, it is to be understood that the subject matter is not limited to the specific methods or features described. Rather, these methods and specific features are disclosed and explained as examples of the subject matter.

Claims

1. A method comprising: During boot of a computing device having a Unified Extensible Firmware Interface (UEFI), detecting execution of a driver associated with a hardware component of the computing device; Calculating a first driver hash of a system table of the UEFI, wherein the system table is a data structure that stores configuration details of the computing device and UEFI services; Detecting the completion of the driver's execution; Upon completion of execution of the driver, computing a second driver hash of the system table; comparing the first driver hash to the second driver hash; detecting execution of a callback function of another driver associated with another hardware component of the computing device; Calculate the first callback function hash of the system table; Detect the completion of the execution of the callback function; When the completion of the callback function is detected, a second callback function hash of the system table is calculated; Compare the first callback function hash to the second callback function hash; as well as Tampering with a system table of the UEFI is determined based on a comparison of the first and second driver hashes and the first and second callback function hashes.

2. The method of claim 1 , further comprising blocking the driver based on determining tampering with a system table of the UEFI. 3 . The method of claim 2 , further comprising preventing execution of the driver during a subsequent boot of the computing device.

4. The method of claim 1, further comprising: identifying a video output device coupled to the computing device; as well as When tampering with the system tables is determined, a notification providing details of the driver is displayed on the video output device.

5. The method of claim 1, further comprising undoing modifications made to the system table by the driver. 6 . The method of claim 1 , wherein execution of the driver is detected in a driver execution environment (DXE) phase during booting of the computing device. The method of claim 6 , wherein the driver is one of a DXE driver and a UEFI driver.

8. The method of claim 6, further comprising: triggering a system management mode SMM in the DXE phase, wherein the triggering SMM saves a state of a processor of the computing device in a secure area of ​​a random access memory RAM coupled thereto; as well as The first driver hash and the second driver hash are stored in a secure area of ​​RAM.

9. The method of claim 1, further comprising preventing execution of the callback function during a subsequent boot of the computing device.

10. A system comprising: A detection engine for detecting, during a pre-operating system (OS) initialization of a computing device having a Unified Extensible Firmware Interface (UEFI), execution of a callback function of a driver associated with a hardware component of the computing device in a driver execution environment (DXE) phase; A hashing engine coupled to the detection engine for: Calculating a first callback function hash of a UEFI system table, wherein the system table is a data structure that stores configuration details of a computing device and UEFI services; Upon detecting completion of execution of the callback function, calculating a second callback function hash of the system table; as well as A determination engine coupled to the hash engine for: It is determined whether the first callback function hash is different from the second callback function hash to determine tampering with the system table of the UEFI.

11. The system of claim 10, wherein the detection engine is coupled to a DXE dispatcher, wherein the DXE dispatcher discovers and executes a plurality of drivers associated with a plurality of hardware components of the computing device during pre-OS initialization of the computing device.

12. The system of claim 10, further comprising a modification engine for undoing modifications made to the system table based on the determination of tampering with the system table of the UEFI.

13. A non-transitory computer-readable medium comprising instructions executable by a processing resource for: Detecting execution of a driver associated with a hardware component of a computing device in a driver execution environment (DXE) phase during pre-operating system (OS) initialization of a computing device having a Unified Extensible Firmware Interface (UEFI); Calculating a first driver hash of a system table of the UEFI, wherein the system table is a data structure that stores configuration details of the computing device and UEFI services; Detecting the completion of the driver's execution; Upon completion of execution of the driver, computing a second driver hash of the system table; comparing the first driver hash to the second driver hash; detecting, during a pre-OS initialization of the computing device, in a DXE phase, execution of a callback function of another driver associated with another hardware component of the computing device; Calculate the first callback function hash of the system table; Detect the completion of the execution of the callback function; When the execution of the callback function is completed, the second callback function hash of the system table is calculated; Compare the first callback function hash to the second callback function hash; as well as Tampering with a system table of the UEFI is determined based on a comparison of the first and second driver hashes and the first and second callback function hashes.

14. The non-transitory computer-readable medium of claim 13, further comprising instructions for preventing execution of at least one of the driver and the callback function of another driver during a subsequent boot of the computing device.

Images