WO2023027687A1

WO2023027687A1 - Hashes to control code execution

Info

Publication number: WO2023027687A1
Application number: PCT/US2021/047179
Authority: WO
Inventors: Christopher H. Stewart; Christine PHAN; Kevin Bao PHAN; Dallas M. Barlow
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2021-08-23
Filing date: 2021-08-23
Publication date: 2023-03-02

Abstract

In some examples an electronic device comprises a memory and a processor. The processor is to generate a hash of executable code stored to the memory after a phase of a boot operation of the electronic device, determine whether a record of hashes generated during the phase of the boot operation includes the hash, and control, responsive to the determination, execution of the executable code.

Description

HASHES TO CONTROL CODE EXECUTION

BACKGROUND

[0001] Electronic devices such as desktops, laptops, notebooks, tablets, and smartphones include executable code that manages operations of hardware components of the electronic devices, enables users to perform specific tasks, or a combination thereof. Prior to executing the executable code, the electronic device may authenticate the executable code to determine that the executable code is unmodified (e.g., is the same executable code as that generated by an author of the executable code).

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various examples are described below referring to the following figures.

[0003] FIG. 1 is a schematic diagram depicting an electronic device utilizing hashes to control code execution, in accordance with various examples.

[0004] FIG. 2 is a schematic diagram depicting an electronic device utilizing a hypervisor to control code execution, in accordance with various examples.

[0005] FIG. 3 is a flow diagram depicting a method for an electronic device to generate hashes to control code execution, in accordance with various examples.

[0006] FIG. 4 is a flow diagram depicting a method for an electronic device to utilize hashes to control code execution, in accordance with various examples.

[0007] FIG. 5 is a schematic diagram depicting an electronic device utilizing hashes to control code execution, in accordance with various examples.

[0008] FIG. 6 is a schematic diagram depicting an electronic device utilizing hashes to control code execution, in accordance with various examples.

[0009] FIG. 7 is a schematic diagram depicting an electronic device updating a memory to store hashes to control code execution, in accordance with various examples.

DETAILED DESCRIPTION

[0010] As described above, electronic devices include executable code that may be authenticated prior to execution. An executable image format encapsulates a data structure that comprises the executable code. For electronic devices comprising a Unified Extensible Firmware Interface (UEFI) Basic Input/Output System (BIOS) the data structure may be a portable executable (PE) format. (Refer to FIG. 1 below for a description of the IIEFI BIOS.) The executable code may herein be referred to as a PE image. Multiple executable codes may be compiled into a package, or a volume, to facilitate compression, signing, security, or a combination thereof. For a IIEFI BIOS, the volume may be referred to as a firmware volume (FV).

[0011] Prior to executing a PE image, the electronic device may determine whether the PE image is authentic by verifying a signature of the PE image or of an FV that includes the PE image. In instances where the PE image is part of an FV, the signature may be for the FV, and the individual PE image may be unsigned. The electronic device may perform the determination during a phase of a boot operation of the electronic device. The boot operation may include multiple phases. Not all PE images authenticated during a phase of the boot operation are executed before the end of that phase. Instead, the electronic device executes the PE images in a subsequent phase of the boot operation. However, the electronic device may not be able to re-authenticate an individually unsigned PE image that is executed during the subsequent phase, and during a time period that occurs after the authentication of the PE image or of an FV that includes the PE image and prior to the execution of the PE image, the executable code of the PE image may be compromised. For instance, a time-of-check to time-of-use (TOCTOll, TOCTTOU, TOC/TOU) attack may compromise the PE image and enable a malicious third- party to access the electronic device via the executable code.

[0012] This description describes examples of an electronic device to re- authenticate a PE image that is first authenticated during a phase of a boot operation but that is not executed until a subsequent phase of the boot operation. The electronic device collects non-executed PE images that are authenticated either individually or as part of FVs during the phase of the boot operation, loads the non-executed PE images into a memory, generates a hash for each nonexecuted PE image, stores the hash in a record of hashes, and passes the record of hashes to a hypervisor of the electronic device. The hypervisor is a platform upon which virtual machines (VMs) execute. The electronic device removes the nonexecuted PE images from the memory. During the subsequent phase of the boot operation, the electronic device reloads the non-executed PE images into the memory. The hypervisor receives information for the non-executed PE images, generates a hash for each non-executed PE image, and compares the hash to the record of hashes. If the hash is in the record of hashes, then the non-executed PE image indicated by the hash is authenticated and the electronic device launches the PE image. If the hash is not in the record of hashes (e.g., not authenticated), then the electronic device removes the non-executed PE image from the memory (e.g., the non-executed PE image is not launched). In some examples, in addition to removing the non-executed PE image from the memory, the electronic device may generate an error signal.

[0013] Utilizing the electronic device to re-authenticate PE images prior to execution enhances security of the electronic device. By re-authenticating a PE image that is authenticated but not executed during the phase of the boot operation, the electronic device verifies that the PE image has not been compromised during the time that occurs between the authentication during the phase of the boot operation and the launching of the executable code during the subsequent phase of the boot operation. By loading the PE image to memory prior to authentication, the electronic device eliminates a load time between the authentication of the PE image and execution of the re-authenticated PE image. By eliminating the load time, the electronic device reduces a time period during which the PE image may be corrupted.

[0014] In some examples in accordance with the present description, an electronic device is provided. The electronic device comprises a memory and a processor. The processor is to generate a hash of executable code stored to the memory after a phase of a boot operation of the electronic device, determine whether a record of hashes generated during the phase of the boot operation includes the hash, and control, responsive to the determination, execution of the executable code.

[0015] In other examples in accordance with the present description, an electronic device is provided. The electronic device comprises a memory and a processor. The processor is to receive a first hash for an executable code unexecuted during a phase of a boot operation of the electronic device and to receive a signal after the phase of the boot operation. The signal indicates that the unexecuted executable code is stored to the memory. The processor is to, responsive to the signal, generate a second hash for the unexecuted executable code, to determine whether the second hash is equivalent to the first hash, and to control, responsive to the determination, execution of the unexecuted executable code.

[0016] In yet other examples in accordance with the present description, a non- transitory machine-readable medium stores machine-readable instructions, which, when executed by a processor of an electronic device, cause the processor to receive a signal after a phase of a boot operation of the electronic device. The signal indicates that executable code is stored to a memory. The machine-readable instructions, when executed by the processor, cause the processor to, responsive to the signal, generate a hash for the executable code and to compare the hash to a record of hashes stored in the memory. The record of hashes includes a hash for authenticated executable code unexecuted during the phase of the boot operation. The machine-readable instructions, when executed by the processor, cause the processor to, based on a result of the comparison, control execution of the executable code.

[0017] Referring now to FIG. 1 , a schematic diagram depicting an electronic device 100 utilizing hashes to control code execution is provided, in accordance with various examples. The electronic device 100 includes a processor 102 and a storage device 104. The electronic device 100 may be a desktop, a laptop, a notebook, a tablet, a smartphone, or any other suitable computing device. The processor 102 may be a microprocessor, a microcomputer, a microcontroller, or another suitable processor or controller for managing operations of the electronic device 100. The storage device 104 may include a hard drive, solid state drive (SSD), flash memory, random access memory (RAM), or other suitable memory for storing data or executable code of the electronic device 100. While not explicitly shown, the electronic device 100 may include network cards, video adapters, sound cards, local buses, and input/output devices (e.g., keyboard, mouse, display device). [0018] In some examples, the processor 102 couples to the storage device 104. The storage device 104 may store machine-readable instructions which, when executed by the processor 102, cause the processor 102 to perform some or all of the actions attributed herein to the processor 102. The machine-readable instructions may be the machine-readable instructions 106, 108, 110.

[0019] In various examples, when executed by the processor 102, the machine- readable instructions 106, 108, 110 cause the processor 102 to utilize a hash to control code execution. Execution of the machine-readable instruction 106 may cause the processor 102 to generate a hash for executable code stored to memory after a phase of a boot operation. Execution of the machine-readable instruction 108 may cause the processor 102 to determine whether a record of hashes generated during the phase of the boot operation includes the hash. Execution of the machine-readable instruction 110 may cause the processor 102 to control, responsive to the determination, execution of the executable code.

[0020] As described above, in some examples, the electronic device 100 comprises a Basic Input/Output System (BIOS). As used herein, a BIOS refers to hardware or hardware and machine-readable instructions to initialize, control, or operate a computing device (e.g., the electronic device 100) prior to execution of an operating system (OS) of the computing device. Machine-readable instructions included within the BIOS may be software, firmware, microcode, or other programming that defines or controls functionality or operation of the BIOS. In some examples, the BIOS may be implemented using machine-readable instructions, such as platform firmware of the computing device, executable by a processor (e.g., the processor 102). The BIOS may operate or execute prior to the execution of the OS of the computing device. The BIOS may initialize, control, or operate components such as hardware components of the computing device and may load or boot the OS of the computing device.

[0021] In some examples, the BIOS may provide or establish an interface between hardware devices or platform firmware of the computing device and the OS of the computing device, via which the OS of the computing device may control or operate the hardware devices or the platform firmware of the computing device. In some examples, the BIOS may implement the IIEFI specification or another specification or standard for initializing, controlling, or operating a computing device.

[0022] In various examples, the BIOS includes executable code usable to perform a power on self-test (POST), which includes hardware initialization, testing, and configuration during the boot-up process. The BIOS further includes executable code usable to launch a bootloader from a Master Boot Record (MBR), and to use the bootloader to launch the OS. After launching the OS, the BIOS is usable to provide OS runtime services (e.g., communication with peripheral devices) for the OS and applications. In other examples, IIEFI BIOS may be used in lieu of the BIOS. Like BIOS, IIEFI BIOS includes executable code usable to perform hardware initialization, testing, and configuration during the boot-up process, to launch the OS, and to provide OS runtime services for the OS and applications. However, IIEFI BIOS employs globally unique identifier (GIIID) partition tables (GPTs) in lieu of MBRs. For the sake of convenience and brevity, this description uses the term BIOS generally to refer to both BIOS and IIEFI BIOS. The OS comprises executable code that manages both hardware and executable code (e.g., applications) after a computer has booted up.

[0023] As described herein, the terms “applications,” “software,” and “firmware” may be considered to be interchangeable in the context of the examples provided. “Firmware” may be considered to be machine-readable instructions that a processor (e.g., the processor 102) executes prior to execution of the OS, with a small portion that continues after the OS bootloader executes (e.g., a callback procedure). “Applications” and “software” may be considered broader terms than “firmware,” and may be considered to refer to machine-readable instructions that execute after the OS bootloader starts, through OS runtime, and until the computing device (e.g., the electronic device 100) shuts down. “Application,” “software,” and “firmware,” as used herein, may be referred to as executable code. [0024] In various examples, the executable code, or PE image, may be an executable file (e.g., a file having a .exe or EXE extension), a dynamic-link library (e.g. , a file having a .dll or DLL extension), a device driver or hardware configuration (e.g., a file having a .sys or SYS extension), or a pre-boot executable or boot loader executable (e.g., a file having a UEFI extensible firmware interface (EFI) or .efi extension). As described above, prior to executing the PE image, the electronic device 100 may verify a signature of the PE image or of an FV comprising the PE image during a first phase of a boot operation of the electronic device 100. In some examples, the first phase of the boot operation may be a Driver execution Environment (DXE) phase. In examples where the electronic device 100 comprises a IIEFI BIOS, the DXE phase may be subdivided into multiple subphases. As described below with respect to FIG. 3, a start phase of the DXE phase may herein be referred to as “Start DXE Core,” which is when the main DXE Core driver begins execution, and an end phase of the DXE phase may be indicated by EndOfDxe. A time period of the DXE phase may be referred to as a DXE core time period. During the DXE core time period, PE images that are trusted are executed. A trusted PE image, as used herein, is an authenticated executable code that originates from the electronic device 100. Trusted code may be the BIOS of the electronic device 100, for example. Authenticated, non-trusted PE images may not be able to be executed until after EndOfDxe.

[0025] Another phase of the boot operation may start after EndOfDxe. The another phase of the boot operation may be a Boot Device Selection (BDS) phase, as described below with respect to FIG. 4. During the BDS phase, the non-trusted PE images authenticated but not executed during the DXE core time period may be executed. A non-trusted PE image, as used herein, may be executable code that originates from a third-party and that facilitates communication between the electronic device 100 and a component of the third-party. Firmware of a Thunderbolt computing device may be a non-trusted PE image, for example.

[0026] In various examples, the machine-readable instructions 106, 108, 110 are executed by the processor 102 during the BDS phase. As described above, during the DXE core time period, the processor 102 collects non-executed PE images from FVs that are authenticated, loads the non-executed PE images into a memory, generates a first hash for each non-executed PE image, and stores a record of the first hashes in the memory. In some examples, the memory is the storage device 104. In other examples, the memory is a virtual memory. Virtual memory, as used herein, is a memory management technique in which the processor 102 generates virtual addresses by mapping memory addresses used by executable code to physical addresses of the storage device 104, another storage device (not explicitly shown) of the electronic device 100, or a combination thereof.

[0027] In some examples, to generate the first hash for each non-executed PE image, the processor 102 may normalize a memory address of each non-executed PE image and then utilize a hashing technique to generate the first hash for each non-executed PE image. In various examples, the processor 102 may normalize the memory address by zeroing out the starting address and the address offset within the loaded non-executed PE images. In other examples, the processor 102 may normalize the memory address by subtracting the memory address for each non-executed PE image from the starting address and the address offset within each non-executed PE image. After creating the record of the hashes, the processor 102 removes the non-executed PE images from the memory. In various examples, during the BDS phase, the processor 102 loads to the memory an executable code that was authenticated but not executed during the DXE core time period. For example, the executable code unexecuted during the DXE phase of the boot operation is a non-trusted portable executable (PE) image. The processor 102 generates a second hash for the executable code and compares the second hash to the record of hashes stored in the memory. The record of hashes comprises hashes for authenticated executable codes unexecuted during the DXE phase of the boot operation, for example.

[0028] In various examples, to generate the second hash, the processor 102 may normalize a memory address of the executable code. To normalize the memory address of the executable code, the processor 102 may zero out a starting address and an address offset that are located within the executable code or may subtract the memory address from the starting address and the address offset. The processor 102 may utilize the hashing technique utilized to generate the first hash during the DXE core time period to generate the second hash.

[0029] The processor 102 determines whether the record of hashes generated during the DXE core time period includes the second hash and controls, responsive to the determination, execution of the executable code. In some examples, the processor 102 may control execution of the executable code by either executing the executable code or by unloading the executable code from the memory. For example, responsive to a determination that the record of hashes includes the second hash, the processor 102 launches the executable code. In another example, responsive to a determination that the second hash is absent from the record of hashes, the processor 102 unloads the executable code from the memory. By controlling execution of PE images that are authenticated during the DXE core time period but that are not loaded for execution until the BDS phase, the processor 102 enhances security of the electronic device 100.

[0030] Referring now to FIG. 2, a schematic diagram depicting an electronic device 200 utilizing a hypervisor 204 to control code execution is provided, in accordance with various examples. The electronic device 200 comprises hardware components 202, the hypervisor 204, and virtual machines 206a-c. The electronic device 200 may be the electronic device 100. The hardware components 202 are resources of the electronic device 200. The hardware components 202 may include a processor (e.g., the processor 102), a storage device (e.g., the storage device 104), a keyboard, a mouse, a graphics card, a sound card, a motherboard, a power supply, a fan, a network interface, a display device, or a combination thereof. The hypervisor 204 is the processor executing executable code that enables sharing of the resources of the electronic device 200 by generating and managing the virtual machines 206a-c. The virtual machines 206a-c may each emulate a computing device.

[0031] In some examples, as described above, during the DXE core time period, a processor (e.g., the processor 102) of the electronic device 200 executing the BIOS collects authenticated, non-executed PE images, loads the authenticated, non-executed PE images into a memory, generates a hash for each authenticated, non-executed PE image, and stores a record of the hashes in the memory. In various examples, the processor may execute the BIOS within a virtual machine. The processor may execute the BIOS within the virtual machine 206c, for example. The memory may be a virtual memory of the electronic device 200. The virtual memory may be the virtual memory of the virtual machine 206a, for example. The processor removes the authenticated, non-executed PE images from the memory. [0032] In various examples, after the DXE core time period, the processor, executing the BIOS, loads a PE image that was authenticated but not executed during the DXE core time period into the memory. The processor may load the PE image into the memory in response to a start-up of the electronic device 200, a callback procedure, or a combination thereof, for example. The processor passes information for the record of hashes and the PE image to the hypervisor 204. In some examples, the information may include a virtual address for the record of hashes and a virtual address for the PE image, for example. The hypervisor 204 may protect the memory storing the record of hashes, blocking modifications to the record of hashes except by the hypervisor 204. The protected memory may be referred to as a hypervisor-protected memory. The hypervisor-protected memory may be a hypervisor-protected memory of the virtual machine 206b, for example. In other examples, the information for the record of the hashes may be a memory buffer created by the IIEFI BIOS. The hypervisor 204 may set attributes of memories of the virtual machines 206a-c such that the virtual machines 206a-c are blocked from changing contents of the memory buffer. In various examples, the hypervisor 204 may protect the memory storing the PE image or a combination of the memory storing the record of the hashes and the PE image.

[0033] In some examples, the hypervisor 204 generates a hash for the PE image and compares the hash to the record of hashes stored in the memory. If the hash is in the record of hashes (e.g., authenticated), then the hypervisor 204 launches the PE image. If the hash is not in the record (e.g., not authenticated), then the hypervisor 204 unloads the PE image from memory. By controlling execution of PE images that are authenticated during the DXE core time period but that are not loaded for execution until after EndOfDxe, the hypervisor 204 enhances security of the electronic device 200.

[0034] In various examples, during the DXE core time period, the processor, executing the BIOS, sends the hypervisor 204 a record of PE images authenticated but not executed during the DXE core time period. The hypervisor 204 creates a record of information for the PE images and stores the record of information for the PE images to a memory. Utilizing a normalization technique described above with respect to FIG. 1 , the hypervisor 204 normalizes memory addresses of the PE images and generates a hash for each PE image. The hypervisor 204 stores a record of the hashes for the PE images to the memory. The processor, executing the BIOS, unloads the PE images from the memory. After the DXE core time period, responsive to a signal to launch a PE image, the processor, executing the BIOS, loads the PE image into the memory and transmits a signal to the hypervisor 204. The signal to launch the PE image received by the processor, executing the BIOS, may be generated by a callback procedure, for example. The signal transmitted by the processor indicates a command for the hypervisor 204 to authenticate the PE image. The hypervisor 204 generates a hash for the PE image and compares the hash to the record of hashes. The hypervisor 204 may generate the hash utilizing the techniques described above with respect to FIG. 1 . Based on a result of the comparison, the hypervisor 204 transmits a signal to the BIOS that indicates whether the PE image is authenticated or not authenticated. Responsive to the signal indicating that the PE image is not authenticated, the BIOS may generate an error signal.

[0035] Referring now to FIG. 3, a flow diagram depicting a method 300 for an electronic device (e.g., the electronic device 100, 200) to generate hashes to control code execution is provided, in accordance with various examples. The method 300 includes a start point 302 that indicates a start of a phase of a boot operation of the electronic device. The start of the phase of the boot operation of the electronic device may be referred to as “Start DXE core,” for example. The method 300 also includes an extract process 304 during which the electronic device extracts executable code from signed volumes. During a collect process 306 of the method 300, the electronic device collects non-executed executable code. Additionally, the method 300 includes a create record process 308 during which the electronic device creates a record for the non-executed executable code. The electronic device normalizes memory addresses for the non-executed executable code during a normalize process 310 of the method 300. The method 300 includes the electronic device generating a hash for each non-executed executable code of the record during a hash process 312. The method 300 also includes the electronic device creating a record of the hashes during a create record process 314. During a store process 316 of the method 300, the electronic device stores the record of the hashes in hypervisor-protected memory. The electronic device unloads the non-executed executable code from memory during an unload process 318 of the method 300. The method 300 includes an end point 320 that indicates an end of the phase of the boot operation of the electronic device. The end of the phase of the boot operation may be referred to as “EndOfDxe,” for example.

[0036] In various examples, the method 300 may be implemented by machine- readable instructions stored to a storage device (e.g., the storage device 104) of the electronic device. A processor (e.g., the processor 102) of the electronic device may execute the machine-readable instructions to perform the method 300. In some examples, the processor, executing the BIOS, sends a hypervisor (e.g., the hypervisor 204) a list of the non-executed executable code collected during the collect process 306. During the create record process 308, the hypervisor creates the record for the non-executed executable code and stores the record to a hypervisor-protected memory. Utilizing a normalization technique described above with respect to FIGS. 1 & 2, the hypervisor normalizes the memory addresses for the non-executed executable code during the normalize process 310. During the hash process 312, the hypervisor generates a hash for each non-executed executable code. The hypervisor creates a record of the hashes during the create record process 314 and stores the record of hashes in the hypervisor-protected memory during the store process 316. The processor, executing the BIOS, unloads the PE images from the memory during the unload process 318.

[0037] Referring now to FIG. 4, a flow diagram depicting a method 400 for an electronic device (e.g., the electronic device 100, 200) to utilize hashes to control code execution is provided, in accordance with various examples. The method 400 includes a start point 402 that indicates a start of a phase of a boot operation of the electronic device. The start of the phase of the boot operation of the electronic device may be referred to as “Start Boot Device Selection (BDS)” and may occur after EndOfDxe, for example. The method 400 also includes a load process 404 during which a BIOS of the electronic device loads PE images of non-executed executable code to memory. During a receive process 406 of the method 400, a hypervisor (e.g., the hypervisor 204) of the electronic device receives information for the loaded PE images. Additionally, the method 400 includes a normalize process 408 during which the hypervisor normalizes memory addresses for the PE images. The method 400 includes the hypervisor generating a hash for each PE image during a hash process 410. The method 400 also includes the hypervisor replacing the normalized memory address with the original memory addresses associated with each PE image during a restore process 412. During a decision point 414 of the method 400, the hypervisor determines whether the hash for a PE image is in a record of hashes. Responsive to the hypervisor determining that the hash is not in the record of hashes, the PE image associated with the hash is unloaded from the memory during an unload process 416. Responsive to the hypervisor determining that the hash is in the record of hashes, the PE image associated with the hash is launched during a launch process 418. The PE attributes of the PE image are applied during an apply process 420.

[0038] In various examples, the method 400 may be implemented by machine- readable instructions stored to a storage device (e.g., the storage device 104) of the electronic device. A processor (e.g., the processor 102) of the electronic device may execute the machine-readable instructions to perform the method 400. In some examples, the processor, executing the BIOS, loads PE images of nonexecuted executable code to memory during the load process 404. The nonexecuted executable code may be executable code not executed during the DXE core time period described above with respect to FIG. 3, for example. In various examples, during the receive process 406, the hypervisor receives the information for the loaded PE images from the processor, executing the BIOS. In other examples, during the receive process 406, the hypervisor retrieves the information from hypervisor-protected memory. In some examples, during the normalizing process 408, the hypervisor creates a record of the original address of the PE images before zeroing out the memory addresses. During the restore process 412, the hypervisor utilizes the record of the original addresses to replace the zeroed- out memory addresses. In other examples, during the normalizing process 408, the hypervisor may subtract a start address of a PE image from address offsets within the PE image. The hypervisor may add the start address of the PE image to the address offsets within the PE image during the restore process 412 to replace the normalized memory addresses with the original memory addresses. [0039] In various examples, responsive to the determination that the hash is not in the record of hashes, the hypervisor unloads the PE image associated with the hash from the memory during the unload process 416. In other examples, responsive to the determination that the hash is not in the record of hashes, the hypervisor generates a signal. Responsive to the signal, the processor, executing the BIOS, unloads the PE image associated with the hash from the memory during the unload process 416. In various examples, responsive to the hypervisor determining that the hash is in the record of hashes, the hypervisor launches the PE image associated with the hash during the launch process 418 and applies the PE attributes of the PE image during the apply process 420. In other examples, responsive to the hypervisor determining that the hash is in the record of hashes, the hypervisor generates a signal. Responsive to the signal, the processor, executing the BIOS, launches the PE image associated with the hash during the launch process 418 and applies the PE attributes of the PE image during the apply process 420.

[0040] Referring now to FIG. 5, a schematic diagram depicting an electronic device 500 utilizing hashes to control code execution is provided, in accordance with various examples. The electronic device 500 may be the electronic device 100, 200. The electronic device 500 comprises a processor 502 and a storage device 504. The processor 502 may be the processor 102. The storage device 504 may be the storage device 104. While not explicitly shown, the electronic device 500 may include network cards, video adapters, sound cards, local buses, and input/output devices (e.g., keyboard, mouse, display device).

[0041] In some examples, the processor 502 couples to the storage device 504. The storage device 504 may store machine-readable instructions which, when executed by the processor 502, cause the processor 502 to perform some or all of the actions attributed herein to the processor 502. The machine-readable instructions may be the machine-readable instructions 506, 508, 510, 512, 514.

[0042] In various examples, when executed by the processor 502, the machine- readable instructions 506, 508, 510, 512, 514 cause the processor 502 to utilize a hash to control code execution. Execution of the machine-readable instruction 506 may cause the processor 502 to receive a first hash for executable code unexecuted during a phase of a boot operation. Execution of the machine-readable instruction 508 may cause the processor 502 to receive a signal after the phase of the boot operation indicating that the unexecuted executable code is stored to a memory. Execution of the machine-readable instruction 510 may cause the processor 502 to generate a second hash for the unexecuted executable code. Execution of the machine-readable instruction 512 may cause the processor 502 to determine whether the second hash is equivalent to the first hash. Execution of the machine-readable instruction 514 may cause the processor 502 to control, responsive to the determination, execution of the unexecuted executable code.

[0043] In various examples, the “phase of the boot operation” described by the machine-readable instructions 506, 508 may be the DXE core time period described above. In some examples, the machine-readable instructions 506, 508, 510, 512, 514 may be machine-readable instructions of a hypervisor (e.g., the hypervisor 204). The hypervisor receives the first hash for executable code unexecuted during the DXE core time period. The executable code unexecuted during the phase of the boot operation may be a non-trusted PE image, for example. In various examples, the processor 502 stores the first hash to the memory. In some examples, the memory storing the first hash is a hypervisor- protected memory. The hypervisor generates the second hash for the unexecuted executable code, determines whether the second hash is equivalent to the first hash, and generates a signal to control, responsive to the determination, execution of the unexecuted executable code. In various examples, responsive to the signal indicating that the second hash is equivalent to the first hash, the processor 502 executes the unexecuted executable code. In other examples, responsive to the signal indicating that the second hash is not equivalent to the first hash, the processor 502 unloads the unexecuted executable code from the memory.

[0044] Referring now to FIG. 6, a schematic diagram depicting an electronic device 600 utilizing hashes to control code execution is provided, in accordance with various examples. The electronic device 600 may be the electronic device 100, 200, 500. The electronic device 600 comprises a processor 602 and a non- transitory machine-readable medium 604. The processor 602 may be the processor 102, 502. The non-transitory machine-readable medium 604 may be the storage device 104, 504. The term “non-transitory” does not encompass transitory propagating signals. While not explicitly shown, the electronic device 600 may include network cards, video adapters, sound cards, local buses, and input/output devices (e.g., keyboard, mouse, display device).

[0045] In some examples, the processor 602 couples to the non-transitory machine-readable medium 604 storing machine-readable instructions which, when executed by the processor 602, cause the processor 602 to perform some or all of the actions attributed herein to the processor 602. The machine-readable instructions may be the machine-readable instructions 606, 608, 610, 612.

[0046] In various examples, when executed by the processor 602, the machine- readable instructions 606, 608, 610, 612 cause the processor 602 to utilize a hash to control code execution. Execution of the machine-readable instruction 606 may cause the processor 602 to receive a signal indicating that executable code is stored to a memory. Execution of the machine-readable instruction 608 may cause the processor 602 to generate a hash for the executable code. Execution of the machine-readable instruction 610 may cause the processor 602 to compare the hash to a record of hashes stored in the memory. Execution of the machine- readable instruction 612 may cause the processor 602 to, based on a result of the comparison, control execution of the executable code.

[0047] In some examples, the machine-readable instructions 606, 608, 610, 612, may be machine-readable instructions of a hypervisor (e.g., the hypervisor 204). The hypervisor receives the signal after a phase of a boot operation of the electronic device 600. The phase of the boot operation may be the DXE core time period, for example. The hypervisor may receive the signal during a BDS phase, for example. The executable code stored to the memory may be executable code authenticated but not executed during the DXE core time period. The executable code may be executable code that the processor 602 authenticates as part of an FV during the DXE core time period, for example. In some examples, the FV may include trusted and non-trusted executable code and the executable code is a nontrusted executable code. During the phase of the boot operation, the processor 602 executes the trusted executable code of the FV. In some examples, the memory is a virtual memory. In various examples, the hypervisor creates the record of hashes stored in the memory during the phase of the boot operation. The hypervisor may store the record of hashes in a hypervisor-protected memory. In some examples, the hashes of the record of hashes are hashes for non-trusted executable codes unexecuted during the phase of the boot operation.

[0048] In some examples, based on a result of the comparison of the hash to the record of hashes, the hypervisor generates a signal to control the execution of the executable code. Responsive to the signal indicating that the hash is in the record of hashes, the processor 602 executes the executable code. Responsive to the signal indicating that the hash is absent from the record of hashes, the processor 602 unloads the executable code from the memory.

[0049] Referring now to FIG. 7, a schematic diagram depicting an electronic device 700 updating a memory 702 to store hashes to control code execution is provided, in accordance with various examples. The electronic device 700 may be the electronic device 100, 200, 500, 600. The electronic device 700 comprises the memory 702. The memory 702 may be virtual memory. While not explicitly shown, the electronic device 700 may include a processor (e.g., the processor 102, 502, 602), a storage device (e.g., the storage device 104, 504, the non-transitory machine-readable medium 604), network cards, video adapters, sound cards, local buses, and input/output devices (e.g., keyboard, mouse, display device).

[0050] In various examples, a method 704 may be implemented by machine- readable instructions stored to the memory 702. The processor (not explicitly shown) may execute the machine-readable instructions to perform the method 704. The method 704 includes an extract process 706 during which the processor (not explicitly shown) extracts executable code from signed volumes. During a collect process 708 of the method 704, the processor (not explicitly shown) collects nonexecuted executable code in a record. During a create process 710 of the method 704, the processor (not explicitly shown) creates a record of hashes for the nonexecuted executable code. The method 704 also includes a removal process 712 during which the processor (not explicitly shown) removes the non-executed executable code from the memory. Additionally, the method 704 includes a load process 714 during which the processor (not explicitly shown) loads a PE image for the non-executed executable code. [0051] In some examples, the processor (not explicitly shown) stores the extracted executable code to a memory block 702a of the memory 702 during the extract process 706. During the collect process 708, the processor (not explicitly shown) stores the record of the non-executed executable code to a memory block 702b. The memory block 702b may include the memory block 702a or a subset of addresses of the memory block 702a. For example, the executable code stored to memory block 702a during the extract process 706 may be the executable code of the memory block 702b. During the create process 710, the processor (not explicitly shown) stores the record of hashes to a memory block 702c. The memory block 702c may include the memory block 702b or a subset of addresses of the memory block 702b. For example, the non-executed executable code stored to memory block 702b during the collect process 708 may be the non-executed executable code of the memory block 702c. In some examples, the memory block 702c may be a hypervisor-protected memory. During the removal process 712, the processor (not explicitly shown) deletes the non-executed executable code from a memory block 702d. The memory block 702d may include the memory block 702c or a subset of addresses of the memory block 702c. During the load process 714, the processor (not explicitly shown) stores the PE image to the memory block 702e. The memory block 702e may include the memory block 702d or a subset of addresses of the memory block 702d. For example, the record of hashes stored to memory block 702d may be the record of hashes of the memory block 702e.

[0052] The above description is meant to be illustrative of the principles and various examples of the present description. Numerous variations and modifications become apparent to those skilled in the art once the above description is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

[0053] In the figures, certain features and components disclosed herein may be shown in exaggerated scale or in somewhat schematic form, and some details of certain elements may not be shown in the interest of clarity and conciseness. In some of the figures, in order to improve clarity and conciseness, a component or an aspect of a component may be omitted. [0054] In the above description and in the claims, the term “comprising” is used in an open-ended fashion, and thus should be interpreted to mean “including, but not limited to... .” Also, the term “couple” or “couples” is intended to be broad enough to encompass both direct and indirect connections. Thus, if a first device couples to a second device, that connection may be through a direct connection or through an indirect connection via other devices, components, and connections. Additionally, the word “or” is used in an inclusive manner. For example, “A or B” means any of the following: “A” alone, “B” alone, or both “A” and “B.”

Claims

CLAIMS What is claimed is:

1 . An electronic device, comprising: a memory; and a processor to: generate a hash of executable code stored to the memory after a phase of a boot operation of the electronic device; determine whether a record of hashes generated during the phase of the boot operation includes the hash; and control, responsive to the determination, execution of the executable code.

2. The electronic device of claim 1 , wherein the processor is to: normalize a memory address of the executable code; and utilize a hashing technique to generate the hash of the executable code.

3. The electronic device of claim 2, wherein to normalize the memory address of the executable code, the processor is to: zero out a starting address and an address offset, wherein the starting address and the address offset are within the executable code; or subtract the memory address of the executable code from the starting address and from the address offset.

4. The electronic device of claim 1 , wherein responsive to the determination that the record of hashes includes the hash, the processor is to launch the executable code.

5. The electronic device of claim 1 , wherein responsive to the determination that the hash is absent from the record of hashes, the processor is to unload the executable code from the memory.

6. An electronic device, comprising: a memory; and a processor to: receive a first hash for an executable code unexecuted during a phase of a boot operation of the electronic device; receive a signal after the phase of the boot operation, the signal indicating that the unexecuted executable code is stored to the memory; responsive to the signal, generate a second hash for the unexecuted executable code; determine whether the second hash is equivalent to the first hash; and control, responsive to the determination, execution of the unexecuted executable code.

7. The electronic device of claim 6, wherein the executable code unexecuted during the phase of the boot operation of the electronic device is a non-trusted portable executable (PE) image.

8. The electronic device of claim 6, wherein the processor is to store the first hash to the memory.

9. The electronic device of claim 8, wherein the memory storing the first hash is a hypervisor-protected memory.

10. The electronic device of claim 9, wherein a hypervisor is to: generate the second hash for the unexecuted executable code; determine whether the second hash is equivalent to the first hash; and generate a signal, responsive to the determination, to control the execution of the unexecuted executable code.

11. A non-transitory machine-readable medium storing machine-readable instructions which, when executed by a processor of an electronic device, cause the processor to: receive a signal after a phase of a boot operation of the electronic device, the signal indicating that executable code is stored to a memory; responsive to the signal, generate a hash for the executable code; compare the hash to a record of hashes stored in the memory, the record of hashes comprising hashes for authenticated executable codes unexecuted during the phase of the boot operation; and based on a result of the comparison, control execution of the executable code.

12. The non-transitory machine-readable medium of claim 11 , wherein the memory is a virtual memory.

13. The non-transitory machine-readable medium of claim 11 , wherein the executable code is executable code that the processor is to authenticate as part of a firmware volume during the phase of the boot operation.

14. The non-transitory machine-readable medium of claim 13, wherein the firmware volume includes trusted and non-trusted executable code; wherein the executable code is a non-trusted executable code; and wherein, during the phase of the boot operation, the processor is to execute the trusted executable code of the firmware volume.

15. The non-transitory machine-readable medium of claim 14, wherein hashes of the record of hashes are hashes for non-trusted executable codes unexecuted during the phase of the boot operation.