WO2022154795A1

WO2022154795A1 - Uefi variables generation

Info

Publication number: WO2022154795A1
Application number: PCT/US2021/013537
Authority: WO
Inventors: Ming Chang HUNG; Fu-Jyu Guo; Nung-Kai Chen; Heng-Fu CHANG
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2021-01-15
Filing date: 2021-01-15
Publication date: 2022-07-21

Abstract

An electronic device may include a first non-volatile storage device having a first storage region, a second non-volatile storage device having a second storage region, and a processor. The processor may detect a modification to a data attribute, generate a first unified extensible firmware interface (UEFI) variable including modified data and previous data associated with the data attribute, and store the first UEFI variable in the first storage region via a first UEFI runtime service. Further, the processor may generate a second UEFI variable to include data indicating the modification to the data attribute and a counter to record boot count. Furthermore, the processor may store the second UEFI variable in the second storage region via the first UEFI runtime service. The processor selectively read, via a second UEFI runtime service, the modified data or previous data from the first storage region based on the second UEFI variable.

Description

UEFI VARIABLES GENERATION

BACKGROUND

[0001] Basic input/output system (BIOS) instructions are used to boot up (i.e., perform boot operations such as loading and starting an operating system (OS), testing hardware, and the like) and perform low level operations in a computing device. BIOS may be implemented using the unified extensible firmware interface (UEFI) standard, which is a specification that defines an interface between an OS and platform firmware (i.e., a combination of persistent memory and program code/data stored in the persistent memory).

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Examples are described in the following detailed description and in reference to the drawings, in which:

[0003] FIG. 1 A is a block diagram of an example electronic device, including a processor to generate a first UEFI variable and a second UEFI variable upon detecting a modification to a data attribute;

[0004] FIG. 1B is a block diagram of the example electronic device of FIG. 1A, depicting additional features;

[0005] FIGs. 2A and 2B are block diagrams of an example electronic device including a machine-readable storage medium, storing instructions to selectively read modified data or previous data from a first non-volatile storage region based on data stored in a second UEFI variable;

[0006] FIG. 2C depicts an example data attribute layout including modified data and previous data with corresponding CRC32 values;

[0007] FIG. 2D depicts an example data representation for the second UEFI variable of FIG. 2A; [0008] FIG. 3A is a flowchart illustrating an exampie method for generating a non-volatile variable to identify that a data attribute was modified;

[0009] FIG. 3B is an example sequence diagram associated with a SetVariable service of FIG. 3A;

[0010] FIG. 4A is a flowchart illustrating an example method for retrieving modified data or previous data based on a boot count of a UEFI variable stored in a non-volatile storage device (e.g., CMOS);

[0011] FIG. 4B-4F are example sequence diagrams associated with a GetVariable service of FIG. 4A;

[0012] FIG. 5A is a block diagram of an example electronic device including a machine-readable storage medium, storing instructions to update a first UEFI variable to increment a boot count after the data attribute has been modified; and

[0013] FIG. SB is a flowchart illustrating an example method 550 for recoding the boot count during a pre-boot phase and clearing the boot count during a normal power off event.

DETAILED DESCRIPTION

[0014] BIOS may refer to hardware or hardware and instructions to initialize, control, or operate an electronic device prior to execution of an operating system (OS) of the electronic device, instructions included within the BIOS may be software, firmware, microcode, or other programming that defines or controls functionality or operation of the BIOS. In one example, the BIOS may be implemented using instructions, such as platform firmware of the electronic device, executable by a processor. The BIOS may operate or execute prior to the execution of the OS of the electronic device. The BIOS may initialize, control, or operate components such as hardware components of the electronic device and may load or boot the OS of the electronic device. [0015] In some examples, the BIOS may provide or establish an interface between hardware devices or platform firmware of the electronic device and an OS of the electronic device, via which the OS of the electronic device may control or operate hardware devices or platform firmware of the electronic device. In some examples, the BIOS may implement the unified extensible firmware interface (UEFI) specification or another specification or standard for initializing, controlling, or operating the electronic device.

[0016] The BIOS or UEFI specification may have to refer to data attributes written in a firmware read-only memory (ROM) which can be accessible after the powering-on of the electronic device, to perform a boot operation (e.g,, device recognition, initialization, or the like) at the time of boot. Such data attributes indispensable to the boot may be stored in the form of UEFI variables. For example, the UEFI variables may include secure boot settings, program critical contents and operating data such as BIOS control policy, or the like.

[0017] The UEFI specification may provide a set of functions that are accessible to both the early boot environment and to the OS. Such functions are known as the “runtime services.” Example runtime service may include a SetVariable service to write/delete a UEFI variable and a GetVariable service to read a UEFI variable. The UEFI variables may be accessible during system management mode (SMM) runtime as well as during boot time. During runtime, the variables may be accessible to the OS, SMM, and/or firmware. The runtime services may provide functionality to manipulate the UEFI variables. For example, the UEFI variables may allow the OS to manage certain settings of the platform firmware like the UEFI boot manager, managing the keys for UEFI Secure Boot protocol, or the like. For example, a user may not have a knowledge of the BIOS control policy, however, may try to change the BIOS control policy through BIOS setup (Fl 0) or BIOS configuration utility (BCU). Such manipulation or modification of the UEFI variables may affect the boot operation of the electronic device (e.g., the electronic device may not boot to the OS environment) or result in hanging during the power-on self-test (POST). [0018] Examples described herein may enable to detect a modification to a data attribute (e.g., critical data atribute that affects a boot operation of an electronic device). Further, a first UEFI variable including the modified data and the previous data may be generated in a first storage region of a first non-volatile storage device via a first UEFI runtime service (e.g., a UEFI SetVariable service). Further, a second UEFI variable may be generated in a second storage region of a second non-volatile storage device via the first UEFI runtime service. The second UEFI variable may include data indicating the modification to the data atribute and a counter to record boot count.

[0019] Initially, the counter may be set to 1 after the data attribute has been modified. Further, the counter may be incremented during each reboot of the electronic device. Furthermore, the counter may be cleared in response to a detection of a normal power off event of the electronic device. Thus, the counter may indicate whether an unexpected shutdown of the electronic device has occurred after the data atribute has been modified. Further, the boot count in the second UEFI variable is used to selectively read the modified data or previous data from the first storage region via a second UEFI runtime service (e.g., a UEFI GetVariable service).

[0020] Thus, examples described herein may utilize a hooking program to extend the UEFI SetVariabie/GetVariable service to generate a new non-volatile UEFI variable (i.e., the second UEFI variable) to indicate that the critical data attribute has been modified and to record boot count after the critical data attribute has been modified. The new non-volatile UEFI variable may identify whether the electronic device can successfully boot to the OS or not and may be cleared when system do a normal shutdown/restore/hibernation.

[0021] In the following description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of the present techniques. However, the example apparatuses, devices, and systems, may be practiced without these specific details. Reference in the specification to “an example" or similar language means that a particular feature, structure, or characteristic described may be included in at least that one example but may not be in other examples.

[0022] The term “pre-boot” may refer to a process that the platform firmware performs, in the state where the electronic device is in a power-off state (e.g., an advanced configuration and power interface (ACPI) S5 state) or in a hibernation state (e.g., an ACPI S4 state), after the electronic device is turned on, and before the OS starts loading. Example “pre-boot” may be performed before a pre- extensible firmware interface (EFI) initialization (PEI) phase of the UEFI boot process. Further, the term "boot” may refer to a series of processes performed from the powering-on of the electronic device, via the pre-boot, to the completion of loading of the OS and OS application. A boot from the power-off state (85 state) or the hibernation state (84 state) is called “cold boot.” Example boot process may include a PEI phase, a driver execution environment (DXE) phase, and/or a boot device select (BDS) phase of the UEFI boot process.

[0023] Turning now to the figures, FIG. 1A is a block diagram of an example electronic device 100, including a processor 110 to generate a first UEFI variable 112 and a second UEFI variable 114 upon detecting a modification to a data attribute. Example electronic device 100 may include a notebook computer, a tablet computer, a desktop computer, or the like. The UEFI specification may include components called UEFI variables (e.g., first UEFI variable 112 and second UEFI variable 114), which may be used in UEFI Secure Boot techniques. The UEFI variables may provide an interface through which an operating system can interact with the platform firmware. Example UEFI variables may be used to save Memory Reference Code (MRC) configuration data, platform control hub (PCH) configuration data, system agent (SA) configuration data, program content, operating data (e.g., BIOS control settings), and the like.

[0024] The UEFI variables may be accessed from an operating system environment through a UEFI specification-defined interface using service calls defined in the UEFI specification as GetVariable and SetVariable services, which respectively retrieve a variable value or set the value of a specified UEFI variable. The GetVariable and SetVariable services may be used in the firmware phase of system boot and additionally the use of the GetVariable and SetVariable functions may be supported by an OS after the OS has booted.

[0025] Electronic device 100 may include a first non-volatile storage device 102 having a first storage region 104. Example first non-volatiie storage device 102 may be a read only memory (ROM) storage device (e.g., serial peripheral interface (SPI) flash memory). Further, electronic device 100 may include a second nonvolatile storage device 106 having a second storage region 108. Example second non-volatile storage device 106 may include a complementary metal-oxide- semiconductor (CMOS) storage device. The term “storage region” may refer to an area of a persistent memory that is located on a non-volatile storage device. Further, electronic device 100 may include a processor 110. Processor 110 may be a type of central processing unit (CPU), microprocessor, or processing logic that interprets and executes machine-readable instructions stored in machine-readable storage medium in electronic device 100.

[0026] During operation, processor 110 may detect a modification to a data attribute that affects a boot operation of electronic device 100. Example data attribute may include a BIOS setting. Further, processor 110 may generate a first UEFI variable 112 including modified data and previous data associated with the data attribute. The previous data may refer to data before the modification, i.e., at the time when electronic device 100 was booted normally. Further, processor 110 may store or save first UEFI variable 112 in first storage region 104 via a first UEFI runtime service 116. Example first UEFI runtime service 116 may be a SetVariable service to write/delete an UEFI variable to/from a storage region of a non-volatile storage device.

[0027] Further, processor 110 may generate a second UEFI variable 114 to include data indicating the modification to the data attribute and a counter to record boot count upon storing first UEFI variable 112. The boot count may indicate a number of times electronic device 106 is booted after the data atribute has been modified. For example, the counter may be initially set to 1 after the data attribute has been modified. Furthermore, processor 110 may store or save second UEFI variable 114 in second storage region 108 via first UEFI runtime service 116. [0028] Also, processor 110 may clear second UEFI variable 114 including the boot count in response to a detection of a normal power off event of electronic device 100. The normal power off event may include a shutdown event, a restart event, or a hibernation event of electronic device 100. In other words, when an unexpected shutdown of electronic device 100 occurs, the boot count may not be cleared. For example, the unexpected shutdown may be caused due to power outages, brown outs, depleted laptop battery or removed power cord, accidentally hitting the power button, or electronic device 100 encountering problem that forces itself to shut down.

[0029] Further, the counter may be updated to increment the boot count during a pre-boot process of electronic device 100. For example, during the pre-boot process of electronic device 100, processor 110 may:

- read second UEFI variable 114 from second storage region 108,

- detect that first UEFI variable 112 has been updated based on the data in second UEFI variable 114, and

- update second UEFI variable 114 to increment the boot count responsive to a detection that the data attribute has been modified.

[0030] Further, during the boot process or after an operating system (OS) for electronic device 100 has booted, processor 110 may selectively read, via a second UEFI runtime service 118, the modified data or previous data from first storage region 104 based on second UEFI variable 114. The modified data or previous data may be used to perform a successful boot operation of electronic device 100. For example, second UEFI runtime service 118 may be a GetVariable service to read/retrieve an UEFI variable from a storage region of a non-volatile storage device.

[0031] In one example, processor 1 10 may read second UEFI variable 114 from second storage region via second UEFI runtime service 118. For example, processor 110 may read second UEFI variable 114 when second UEFI runtime service 118 is called to access first UEFI variable 112, Further, processor 110 may detect that the modification in the data atribute associated with first UEFI variable 112 affects the boot operation using second UEFI variable 114. Furthermore, processor 110 may determine whether a pre-boot process of electronic device 100 has occurred after the data attribute has been modified using the boot count stored in second UEFI variable 114. For example, the boot count ‘T’ indicates that the pre-boot process of electronic device 100 has not occurred. The boot count of “greater than 1” indicates that the pre-boot process of electronic device 100 has occurred, i.e., an unexpected shutdown of electronic device 100 occurred after the data attribute has been modified.

[0032] When the pre-boot process of electronic device 100 has not occurred after the data attribute has been modified, processor 110 may extract the modified data (e.g., a latest BIOS setting) from first storage region 104 and return the modified data via the second UEFI runtime service 118. When the pre-boot process of electronic device 100 has occurred after the data attribute has been modified, processor 110 may extract the previous data (e.g., a previous BIOS seting) from first storage region 104 and return the previous data via second UEFI runtime service 118.

[0033] Thus, examples described herein may provide UEFI DXE and PEI drivers, which may use a hooking program to extend SetVariable/GetVariable function. The UEFI PEI and DXE drivers can handle to recover previous critical contents (i.e., the previous data) to resolve boot fail or hang issues associated with electronic device 100.

[0034] FIG. 1 B is a block diagram of example electronic device 100 of FIG. 1 A, depicting additional features. For example, similarly named elements of FIG, 1B may be similar in structure and/or function to elements described with respect to FIG. 1A. As shown in FIG. 1 B, electronic device 100 may include a third storage region 152. In one example, third storage region 152 may be provided as part of first non-volatile storage device 102 (e.g.. as shown in FIG. 1 B) or a separate nonvolatile storage device.

[0035] During operation, processor 110 may generate a third UEFI variable 154 including the modified data and previous data associated with the data attribute. Further, processor 110 may store third UEFI variable 154 including the modified data and previous data in third storage region 152 via first UEFI runtime service 116. In this example, third storage region 152 may act as a back-up for first storage region 104. In this example, the modified data or previous data is read from third storage region 152 via second UEFI runtime service 118 during a failure to read the modified data or previous data from first storage region 104. Thus, examples described herein may provide dual variable storage regions (i.e., first storage region 104 and third storage region 152), which can reduce a probability of failure of the boot process of electronic device 100 due to a crash of first UEFI variable 112.

[0036] FIGs. 2A and 2B are block diagrams of an example electronic device 200 including a machine-readable storage medium 204, storing instructions to selectively read modified data or previous data from a first non-volatile storage region based on data stored in a second UEFI variable. Electronic device 200 may include a processor 202 and machine-readable storage medium 204 communicatively coupled through a system bus. Processor 202 may be any type of central processing unit (CPU), microprocessor, or processing logic that interprets and executes machine-readable instructions stored in machine-readable storage medium 204. Machine-readable storage medium 204 may be a randomaccess memory (RAM) or another type of dynamic storage device that may store information and machine-readable instructions that may be executed by processor 202. For example, machine-readable storage medium 204 may be synchronous DRAM (SDRAM), double data rate (DDR), rambus DRAM (RDRAM), rambus RAM, etc., or storage memory media such as a floppy disk, a hard disk, a CD-ROM, a DVD, a pen drive, and the like. In an example, machine-readable storage medium 204 may be a non-transitory machine-readable medium. In an example, machine- readable storage medium 204 may be remote but accessible to electronic device 200.

[0037] As shown in FIG. 2A, machine-readable storage medium 204 may store instructions 206-214. In an example, instructions 206-214 may be executed by processor 202 to generate the first UEFI variable and the second UEFI variable upon detecting a modification to a data atribute. Instructions 206 may be executed by processor 202 to identify a modification to a date attribute. Example data attribute may be a BIOS setting.

[0038] Instructions 208 may be executed by processor 202 to generate a cyclic redundancy check (CRC) for modified data and previous date associated with the data attribute. The term “CRC” may refer to an error-detecting code used in digital networks and storage devices to detect data corruption. The CRC may verify an integrity of the data secured by backup operations and transferred over a network, and the data stored on non-volatile storage devices. Example CRC may include CRC32. An example data attribute layout 200C including modified data 272 and previous data 274 with corresponding CRC32 values is shown in FIG. 2C.

[0039] Instructions 210 may be executed by processor 202 to generate, via a first UEFI runtime service, a first UEFI variable including the modified data with the CRC and the previous data with the CRC in a first non-volatile storage region. For example, the first UEFI runtime service is a UEFI SetVariable service. In some examples, machine-readable storage medium 204 may store instructions to generate a third UEFI variable including the modified data with the generated CRC and the previous data with the generated CRC in a third non-volatile storage region via the first UEFI runtime service. In some examples, the third UEFI variable may be a back-up for the first UEFI variable. The first non-volatile storage region and the third non-volatile storage region can be part of or supported on a same nonvolatile storage device (e.g., an SPI flash memory) or separate non-volatile storage devices.

[0040] I nstructions 212 may be executed by processor 202 to generate, via the first UEFI runtime service, a second UEFI variable in a second non-volatile storage region. The second UEFI variable may include data indicating the modification to the data attribute and a counter to record boot count. The boot count may Indicate an unexpected shutdown of electronic device 200 after the data attribute has been modified. An example data representation 200D of the second UEFI variable is shown in FIG. 2D. As shown in FIG. 2D, the second UEFI variable may be represented using 8-bits (1 byte). In this example, bits 0-3 may be used to store boot count and bit-7 may be used to indicate that the data attribute has been modified. For example, a value of “1” for bit-7 may indicate that the data attribute has been modified and a value of “0” for bit-7 may indicate that the data attribute has not been modified. Further, bits 4-6 may be reserved for identification data (e.g„ namespace) associated with the second UEFI variable.

[0041] Further, machine-readable storage medium 204 may store instructions to clear the data that indicates the data attribute has been modified and the boot count from the second UEFI variable in response to a detection of a shutdown event, a restart event, or a hibernation event of electronic device 200. However, when an unexpected shutdown of electronic device 200 occurs, the data and the boot count in the second UEFI variable may not be cleared.

[0042] Furthermore, during a pre-boot process of electronic device 200, machine-readable storage medium 204 may store instructions to:

- read, via a second UEFI runtime service, the second UEFI variable from the second non-volatile storage region,

- detect that the data attribute has been modified based on the data in the second UEFI variable, and

~ update the second UEFI variable to increment the boot count responsive to a detection that the data attribute has been modified.

[0043] Instructions 214 may be executed by processor 202 to selectively read, via the second UEFI runtime service, the modified data or previous data from the first non-volatile storage region based on the second UEFI variable (e.g., the boot count stored in the second UEFI variable). For example, the second UEFI runtime service is a UEFI GetVariable service. In some examples, the modified data or previous data may be retrieved from the third non-volatile storage region via a second UEFI runtime service during a failure to read the modified data or previous data from the first non-volatile storage region. Selectively reading the modified data or previous data based on the boot count is explained in FIG. 2B.

[0044] As shown in FIG. 2B, machine-readable storage medium 204 may store instructions 252-264. In an example, instructions 252-264 may be executed by processor 202 to selectively read the modified data or previous data from the first non-volatile storage region based on the boot count Instructions 252 may be executed by processor 202 to read, via the second UEFI runtime service, the second UEFI variable from the second non-volatile storage region.

[0045] Instructions 254 may be executed by processor 202 to detect the modification in the data attribute associated with the first UEFI variable using the second UEFI variable. Instructions 256 may be executed by processor 202 to read, via the second UEFI runtime service, the first UEFI variable from the first nonvolatile storage region in response to the detection.

[0046] Instructions 258 may be executed by processor 202 to verify data integrity of the modified data and the previous data with the generated CRC associated with the modified data and the previous data, respectively, upon reading the first UEFI variable. Upon the verification, instructions 260 may be executed by processor 202 to determine whether an unexpected shutdown of electronic device 200 has occurred after the data attribute has been modified using the boot count in the second UEFI variable.

[0047] When the unexpected shutdown of electronic device 200 has not occurred after the data atribute has been modified, instructions 262 may be executed by processor 202 to return the modified data via the second UEFI variable interface. When the unexpected shutdown of electronic device 200 has occurred, instructions 264 may be executed by processor 202 to return the previous data via the second UEFI runtime service.

[0048] FIG. 3A is a flowchart illustrating an example method 300A for generating a non-volatile variable to identify that a data attribute has been modified. Examples described in FIG. 3A can be implemented using a DXE driver or system management mode (SMM) driver during a boot process (e.g., DXE phase, BDS phase, or the like) and/or a runtime environment (i.e. , after an OS has been loaded) of an electronic device. At 302, during the boot process or runtime environment, a UEFI driver (e.g., a DXE driver or SMM driver) that hooks a call to a UEFI Setvariable service may be called to set a data attribute. [0049] At 304, a change in the data attribute may be determined as being critical (i.e., the change in the data attribute may affect a boot operation of the electronic device). Example data attribute may include a BIOS setting. At 306, critical variable data including modified data with a CRC32 value and previous data with a CRC32 value may be generated. At 308, the critical variable data may be recorded into a first storage region of a first non-volatile storage device through the UEFI SetVariable service.

[0050] At 310, a check may be made to determine whether a return status of the UEFI SetVariable service is successful (e.g., corresponding to the first storage region). When the return status is successful (at 310), then the process goes to block 314, where a backup for the critical variable data may be generated. When the return status is not successful (at 310), an error associated with the return status may be reported through an audit log (e.g., an embedded controller/super input/output (SIO) audit log), at 312, and then the process goes to block 314, At 314, the critical variable data may be recorded into a second storage region of the first non-volatile storage device or a second non-volatile storage device through the UEFI SetVariable service.

[0051] At 316, a check may be made to determine whether a return status of the UEFI SetVariable service is successful (e.g., corresponding to the second storage region). When the return status is successful (at 316), then the process goes to block 320. When the return status is not successful (at 316), an error associated with the return status may be reported through an audit log (e.g., an embedded controller/super input/output (SIO) audit log), at 318, and the process goes to block 320.

[0052] Upon storing the critical variable data in the first storage region and/or the second storage region, at 320, an UEFI variable on a non-volatile storage device (e.g., CMOS) may be updated to identify that the critical data atribute has been modified and to initiate a boot count. At 322, the return status of the UEFI SetVariable service corresponding to storing the critical variable data in the first storage region and/or the second storage region may be indicated. [0053] FIG. 3B is an example sequence diagram 300B associated with the SetVariable service of FIG. 3A. At 352, a modification to a data attribute (e.g., a critical data setting) may be detected. At 354, a hooking program that use a UEFI SetVariable service may be called to record the data attribute. At 356, the critical variable data with current data (i.e., previous setting data before the modification) and the modified data may be generated. At 356. the critical variable data including the previous data (e.g., a previous setting data) with CRC32 and the modified data (e.g,, a modified setting data or a latest setting data) with CRC32 may be generated.

[0054] At 358, the critical variable data including the previous data with CRC32 and the modified data with CRC32 may be recorded in the first storage region. At 360, the critical variable data including the previous data with CRC32 and the modified data with CRC32 may be recorded In the second storage region. Upon recoding the critical variable data, the UEFI variable in the non-volatile storage device (e.g., CMOS) may be updated to identify that the critical data attribute has been modified and initiate the boot count (e.g., set boot count to 1), at 362.

[0055] FIG. 4A is a flowchart illustrating an example method 400A for retrieving modified data or previous data based on a boot count of a UEFI variable stored in the non-volatile storage device (e.g. , CMOS). Examples described in FIG. 4A can be implemented using a PEI driver, a DXE driver, or a SMM driver during a boot process (e.g., a PXE phase, DXE phase, BDS phase, or the like), and/or a runtime environment (i.e. , after an OS has been loaded). At 402, during the boot process or runtime environment, a UEFI driver (e.g,, a PEI driver, a DXE driver, or SMM^ driver) that hooks a call to a UEFI GetVariable service may be called to access a data atribute.

[0056] At 404, a change in the data attribute may be determined as being critical (i.e., the change in the data atribute may affect a boot operation of an electronic device), for instance, using the data stored in the UEFI variable of the non-volatile storage device. At 406, the critical variable data including the modified data and the previous data associated with the data attribute may be retrieved from a first storage region through the UEFI GetVariable service. In an example, memory may be reallocated to obtain critical variable data associated with the data attribute. In this example, the UEFI drivers may not be aware of a design of the data attribute layout (e.g., critical variable data as shown in 2Q0C of FIG. 2C) that includes the modified data and the previous data. Therefore, memory may be reallocated to retrieve the critical variable data.

[0057] At 408, a check may be made to determine whether a return status of the UEFI GetVariable service is successful (e.g,, corresponding to the first storage region). When the return status is not successful (at 408), the process goes to block 412. In some examples, an error associated with the return status may be reported through an audit log. When the return status is successful (at 408), a check may be made to verify the data integrity of the modified data and the previous data using corresponding CRC32 values, at 410. When the verification of data integrity is successful (at 410), the process goes to block 418. When the verification of data integrity fails (at 410), the process goes to block 412. In some examples, an error associated with the failure may be reported through the audit log.

[0058] At 412, the critical variable data including the modified data and the previous data associated with the data attribute may be retrieved from a second storage region through the UEFI GetVariable service. At 414, a check may be made to determine whether a return status of the UEFI GetVariable service is successful (e.g., corresponding to the second storage region). When the return status is successful (at 414), a check may be made to verify the data integrity of the modified data and the previous data using the corresponding CRC32 values, at 416. When the return status is not successful (at 414) or when the verification of the data integrity fails (at 416), the process goes to block 424, where the return status may be indicated as not successful.

[0059] When the data integrity of the modified data and the previous data is successful (at 416), the process goes to block 418. At 418, a check may be made to determine whether the boot count is greater than 1 . For example, the boot count in the UEFI variable may be set to 1 when the data attribute has been modified. The boot count of greater than 1 may indicate that the pre-boot process of the electronic device has occurred after the data attribute has been modified. [0060] When the boot count is not greater than 1 , the modified data associated with the data attribute may be extracted from the first storage region or the second storage region and then the modified data may be prepared to return via the GetVariable interface, at 420. When the boot count is greater than 1, the previous data associated with the data attribute may be extracted from the first storage region or the second storage region and then the previous data may be prepared to return via the GetVariable interface, at 422. At 424, the return status may be indicated as successful and the modified data or the previous data may be returned via the UEFI GetVariable service.

[0061] FIG. 4B is an example sequence diagram 400B associated with the GetVariable service of FIG. 4A. Particularly, FIG. 4B illustrates an example sequence to retrieve the current data (i.e. , the modified data) from the first storage region when the UEFI variable does not indicate that the critical data attribute has been modified (e.g., a value of bit-7 associated with the UEFI variable is zero). At 452B, a memory (e.g. , free memory) may be allocated to obtain the critical variable data associated with the data attribute. At 454B, a hooking program that use a UEFI GetVariable service may be called to retrieve the data attribute. The UEFI GetVariable service may allocate a different memory (e.g., free memory) to obtain the critical variable data. At 456B, the critical variable data including the previous setting (e.g., the previous setting data) with CRC32 and the modified data (e.g., the modified setting data) with CRC32 may be retrieved from the first storage region. Since the UEFI variable does not indicate that the critical data attribute was modified, at 458B, the modified data (i.e., the current setting data or latest seting data) may be prepared to return via the UEFI GetVariable service. At 460B. the UEFI GetVariable service may return the modified data.

[0062] FIG. 40 is another example sequence diagram 400C associated with the GetVariable service of FIG. 4A. Particularly, FIG. 4C illustrates an example sequence to retrieve the modified data (i.e., the current setting data) from the first storage region when the UEFI variable indicates that the critical data attribute has been modified (e.g., value of bit-7 is 1 ) and the boot count indicates 1 (i.e., a preboot process of the electronic device has not occurred after the data attribute has been modified). At 452C, a memory (e.g., free memory) may be allocated to obtain the critical variable data. At 454C, a hooking program that use a UEFI GetVariable service may be called to retrieve the data attribute. The UEFI GetVariable service may allocate a different memory (e.g,, free memory) to obtain the critical variable data. At 456C, the critical variable data including the previous data (e.g., the previous setting data) with CRC32 and the modified data (e.g., the modified setting data or current setting data) with CRC32 may be retrieved from the first storage region. Since the UEFI variable indicates that the critical data attribute has been modified and the boot is not greater than 1 , at 4580, the modified data (i.e., the current setting data or latest setting data) may be prepared to return via the UEFI GetVariable service. At 460C, the UEFI GetVariable service may return the modified data.

[0063] FIG. 4D is another example sequence diagram 400D associated with the GetVariable service of FIG. 4A. Particularly, FIG. 4D illustrates an example sequence to retrieve the previous data (i.e., the previous setting data) from the first storage region when the UEFI variable indicates that the critical data attribute has been modified (e.g., value of bit-7 is 1 ) and the boot count is greater than 1 (i.e., a pre-boot process of the electronic device has occurred after the data attribute has been modified). At 452D, a memory (e.g., free memory) may be allocated to obtain the critical variable data. At 454D, a hooking program that use a UEFI GetVariable service may be called to retrieve the data attribute. The UEFI GetVariable service may allocate a different memory (e.g., free memory) to obtain the critical variable data. At 456D, the critical variable data including the previous data (e.g., the previous setting data) with CRC32 and the modified data (e.g., the modified seting data or current setting data) with CRC32 may be retrieved from the first storage region. Since the UEFI variable indicates that the critical data attribute has been modified and the boot is greater than 1 , at 458D, the previous data (i.e., the previous setting data) may be prepared to return via the UEFI GetVariable service. At 460D, the UEFI GetVariable service may return the previous data.

[0064] FIG. 4E is another example sequence diagram 400E associated with the GetVariable service of FIG. 4A. Particularly. FIG. 4E illustrates an example sequence to retrieve the modified data (i.e., the current setting data) from the second storage region when the UEFI variable indicates that the critical data attribute has been modified (e.g., value of bit-7 is 1) and the boot count indicates 1 (i.e. , a pre-boot process of the electronic device has not occurred after the data attribute has been modified). At 452E, a memory (e.g., free memory) may be allocated to obtain the critical variable data. At 454E, a hooking program that use a UEFI GetVariable service may be called to retrieve the data attribute. The UEFI GetVariable service may allocate a different memory (e.g., free memory) to obtain the critical variable data. At 456E, the critical variable data including the previous data (e.g., the previous setting data) with CRC32 and the modified data (e.g., the modified setting data or current setting data) with CRC32 may be retrieved from the first storage region. At 458E, an error occurs while retrieving the critical variable data from the first storage region. An error associated with the return status or data integrity may be recorded in an error log register. At 460E, the critical variable data including the previous data (e.g., the previous setting data) with CRC32 and the modified data (e.g., the modified setting data or current setting data) with CRC32 may be retrieved from the second storage region. Since the UEFI variable indicates that the critical data attribute has been modified and the boot is not greater than 1 , at 462E, the modified data (i.e., the current setting data or latest setting data) may be prepared to return via the UEFI GetVariable service. At 464E, the UEFI GetVariable service may return the modified data.

[0065] FIG. 4 F is another example sequence diagram 400 F associated with the GetVariable service of FIG. 4A. Particularly, FIG. 4F illustrates an example sequence to retrieve the previous data (i.e., the previous setting data) from the second storage region when the UEFI variable indicates that the critical data attribute has been modified (e.g., value of bit-7 is 1) and the boot count is greater than 1 (i.e., a pre-boot process of the electronic device has occurred after the data attribute has been modified). At 452F, a memory (e.g., free memory) may be allocated to obtain the critical variable data. At 454F, a hooking program that use a UEFI GetVariable service may be called to retrieve the data attribute. The UEFI GetVariable service may allocate a different memory (e.g., free memory) to obtain the critical variable data. At 456F, the critical variable data including the previous data (e.g., the previous setting data) with CRC32 and the modified data (e.g., the modified setting data or current seting data) with CRC32 may be retrieved from the first storage region . At 458F, an error occurs while retrieving the critical variable data from the first storage region. Further, an error associated with the return status or data integrity may be recorded in an error log register. At 460F. the critical variable data including the previous data (e.g., the previous setting data) with CRC32 and the modified data (e.g., the modified setting data or current setting data) with CRC32 may be retrieved from the second storage region. Since the UEFI variable indicates that the critical data attribute has been modified and the boot is greater than 1 , at 462F, the previous data (i.e., the previous setting data) may be prepared to return via the UEFI GetVariable service. At 464F, the UEFI GetVariable service may return the previous data.

[0066] The method 300A or 400A depicted in FIG. 3A or 4A, respectively, represents generalized illustrations, and that other processes may be added, or existing processes may be removed, modified, or rearranged without departing from the scope and spirit of the present application. In addition, the processes may represent instructions stored on a computer-readable storage medium that, when executed, may cause a processor to respond, to perform actions, to change states, and/or to make decisions. The processes of method 300A or 400A may represent functions and/or actions performed by functionally equivalent circuits like analog circuits, digital signal processing circuits, application specific Integrated circuits (ASICs), or other hardware components associated with the system. Furthermore, example method 300A or 400A may not be intended to limit the implementation of the present application, but rather example method 300A or 400A illustrates functional Information to design/fabricate circuits, generate machine-readable instructions, or use a combination of hardware and machine-readable instructions to perform the illustrated processes.

[0067] FIG. 5A is a block diagram of an example electronic device 500 including a machine-readable storage medium 504, storing instructions to update a first UEFI variable to increment a boot count after the data attribute has been modified. Electronic device 500 may include a processor 502 and machine- readable storage medium 504 communicatively coupled through a system bus. Processor 502 may be any type of central processing unit (CPU), microprocessor, or processing logic that interprets and executes machine-readable instructions stored in machine-readable storage medium 504. Machine-readable storage medium 504 may be a random-access memory (RAM) or another type of dynamic storage device that may store information and machine-readable instructions that may be executed by processor 502. For example, machine-readable storage medium 504 may be synchronous DRAM (SDRAM), double data rate (DDR), rambus DRAM (RDRAM), rambus RAM. etc., or storage memory media such as a floppy disk, a hard disk, a CD-ROM, a DVD, a pen drive, and the like. In an example, machine-readable storage medium 504 may be a non-transitory machine-readable medium. In an example, machine-readable storage medium 504 may be remote but accessible to electronic device 500.

[0068] As shown in FIG. 5A, machine-readable storage medium 504 may store instructions 506-512. In an example, instructions 506-512 may be executed by processor 502 to increment a boot count during each pre-boot after the data attribute has been modified. Instructions 506 may be executed by processor 502 to read a first UEFI variable from a first non-volatile storage device during a preboot of electronic device 500. In an example, the first UEFI variable may include data indicating a modification to a data attribute and a counter to record boot count.

[0069] Instructions 508 may be executed by processor 502 to detect the modification to the data attribute based on the first UEFI variable during the preboot of electronic device 500. In an example, the data attribute may be stored in a second UEFI variable of a second non-volatile storage device. For example, the instructions when executed further cause the processor to, in response to detecting a modification in the data attribute during a boot or an operating system environment of electronic device 500. store the second UEFI variable including the modified data and the previous data in the second non-volatile storage device via a second UEFI runtime service.

[0070] Instructions 510 may be executed by processor 502 to update, during the pre-boot of electronic device 500, the first UEFI variable to record/increment the boot count that indicates a number of times electronic device 500 is booted after the data attribute has been modified. The boot count may be used to selectively extract current data or previous data associated with the data attribute from the second UEFI variable via a first UEFI runtime service (e.g., UEFi GetVariable service).

[0071] Instructions 512 may be executed by processor 502 to boot electronic device 500 to load an OS upon recording the boot count. In one example, the instructions when executed further cause the processor to:

- when the boot count indicates that the pre-boot of electronic device 500 has not occurred after the data attribute has been modified, return the current data associated with the data attribute from the second UEFI variable via the first UEFI runtime service,

- when the boot count indicates that the pre-boot of electronic device 500 has occurred after the data atribute has been modified, return the previous data associated with the data attribute from the second UEFI variable via the first UEFI runtime service.

[0072] In one example, the extracted current data or the extracted previous data may be used to perform a boot operation of electronic device 500. Further, machine-readable storage medium 504 may store instructions to clear, during runtime and after the OS has booted, the first UEFI variable including the boot count in response to a detection of a normal power off event of electronic device 500. The first UEFI variable may be cleared via a second UEFI runtime service (e.g., UEFI Setvariable service).

[0073] FIG. 5B is a flowchart illustrating an example method 550 for recoding the boot count during a pre-boot phase and clearing the boot count during a normal power off event. The method 550 depicted in FIG. 5B represents generalized illustrations, and that other processes may be added, or existing processes may be removed, modified, or rearranged without departing from the scope and spirit of the present application. In addition, the processes may represent instructions stored on a computer-readable storage medium that, when executed, may cause a processor to respond, to perform actions, to change states, and/or to make decisions. The processes of method 550 may represent functions and/or actions performed by functionally equivalent circuits like analog circuits, digital signal processing circuits, application specific integrated circuits (ASICs), or other hardware components associated with the system. Furthermore, example method 550 may not be intended to limit the implementation of the present application, but rather example method 550 illustrates functional Information to design/fabricate circuits, generate machine-readable instructions, or use a combination of hardware and machine-readable instructions to perform the illustrated processes.

[0074] At 552, an electronic device may be powered on or reset. At 554, a check may be made to determine whether the electronic device is resumed from a S3 sleep state. When the electronic device is resumed from the S3 sleep state, a PEI phase of the boot process may be invoked, at 562. For example, the UEFI boot process may include the PEI phase, a DXE phase, a BDS phase, and a runtime (RT) phase. The PEI phase may initialize some permanent memory complement, describe the memory in hand-off blocks (HOBs), describe the firmware volume locations in HOBs, pass control into the driver execution environment (DXE) phase, and the like. During the PEI phase. DXE phase, the BDS phase, or the runtime phase, the first UEFI variable may be retrieved via the UEFI GetVariable service.

[0075] When the electronic device is not resumed from the S3 sleep state (e.g., resumed from a shut down or hibernation state), a first UEFI variable may be read from a non-volatile storage device (e.g., CMOS), at 556. The first UEFI variable my include data indicating the modification to the data attribute and a counter to record boot count. The counter may be initially set to 1 when the data attribute has been modified.

[0076] At 558, a modification to the data attribute (e.g., a critical data attribute) may be identified using the data associated with the first UEFI variable. At 560, the boot count may be increased to 2 during the pre-boot. The boot count of 2 may indicate that the pre-boot process of the electronic device has occurred after the data attribute has been modified. Upon incrementing the boot count, at 562, the PEI phase of the boot process may be invoked. In one example, when the electronic device is resumed from the S3 sleep state, the PEI phase of the boot process may be invoked without incrementing the boot count. In another example, when the electronic device is resumed from a shut down or hibernation state, the PEI phase of the boot process may be invoked by incrementing the boot count. [0077] At 564, a check may be made to determine whether the electronic device is resumed from a S3 sleep state. When the electronic device is resumed from the S3 sleep state (at 564), an OS phase of the electronic device may be initiated, at 570, in which the OS may respond to commands from users and allow user programs to run. For example, by executing the boot script, the DXE phase can be bypassed in the S3 resume boot path. In other words, the DXE phase is not available in the S3 resume boot path.

[0078] When the electronic device is not resumed from the S3 sleep state (at 564), the DXE phase of the boot process may be invoked, at 566. The PEI phase may be responsible for initializing the permanent memory in the platform so that the DXE phase can be loaded and executed. The DXE phase may include:

- DXE foundation to produce a set of Boot Services, Runtime Services, and DXE Services.

- DXE dispatcher may be responsible for discovering and executing DXE drivers in the correct order.

- DXE drivers may be responsible for initializing the processor, chipset, and platform components.

[0079] At 568, the BDS phase of the boot process may be invoked. The BDS phase may initialize console devices, load device drivers, attempt to toad and execute boot selections, and the like. At 570, the runtime phase may be initiated. The runtime phase may allow access to persistent content, via UEFI drivers and UEFI applications. During the DXE phase, the BDS phase, or the runtime phase, when a UEFI GetVariable service is called to access the second UEFI variable, the modified data or the previous data may be retrieved based on the boot count stored in the first UEFI variable.

[0080] At 572, the OS may be prepared to perform a normal reset, shutdown (s5), or hibernation (s4) of the electronic device. In response to detecting that the OS is preparing to perform the normal reset, shutdown (s5), or hibernation (s4). the data (e.g., a flag) and the boot count that identifies the critical data attribute has been modified may be cleared from the first UEFI variable, at 574. Upon clearing the first UEFI variable, at 576, a normal restart/S4/S5 of the electronic device may be performed. In other examples, when an unexpected shutdown of the electronic device occurs, the first UEFI variable may not be cleared. Thus, the boot count in the first UEFI variable may be used to identify whether to use the modified data or the previous data to perform the boot operation during a next reboot.

[0081] The above-described examples are for the purpose of illustration. Although the above examples have been described in conjunction with example implementations thereof, numerous modifications may be possible without materially departing from the teachings of the subject matter described herein. Other substitutions, modifications, and changes may be made without departing from the spirit of the subject matter. Also, the features disclosed in this specification (including any accompanying claims, abstract, and drawings), and/or any method or process so disclosed, may be combined in any combination, except combinations where some of such features are mutually exclusive.

[0082] The terms “include,” “have,” and variations thereof, as used herein, have the same meaning as the term “comprise" or appropriate variation thereof. Furthermore, the term “based on”, as used herein, means “based at least in part on.” Thus, a feature that is described as based on some stimulus can be based on the stimulus or a combination of stimuli including the stimulus. I n addition, the terms “first" and “second” are used to identify individual elements and may not meant to designate an order or number of those elements.

[0083] The present description has been shown and described with reference to the foregoing examples. It is understood, however, that other forms, details, and examples can be made without departing from the spirit and scope of the present subject matter that is defined in the following claims.

Claims

WHAT IS CLAIMED IS:

1. An electronic device comprising: a first non-volatile storage device having a first storage region; a second non-volatile storage device having a second storage region; and a processor to: detect a modification to a data attribute that affects a boot operation; generate a first unified extensible firmware interface (UEFI) variable including modified data and previous data associated with the data attribute; store the first UEFI variable in the first storage region via a first UEFI runtime service; generate a second UEFI variable to include data indicating the modification to the data attribute and a counter to record boot count upon storing of the first UEFI variable; store the second UEFI variable in the second storage region via the first UEFI runtime service; and selectively read, via a second UEFI runtime service, the modified data or previous data from the first storage region based on the second UEFI variable.

2. The electronic device of claim 1 , wherein the processor is to: during a pre-boot process of the electronic device: read the second UEFI variable from the second storage region; detect that the first UEFI variable has been updated based on the data in the second UEFI variable; and update the second UEFI variable to increment the boot count responsive to a detection that the data attribute has been modified, wherein the boot count is to indicate a number of times the electronic device is booted after the data attribute has been modified.

3. The electronic device of claim 1 , wherein the processor is to: clear the second UEFI variable including the boot count in response to a detection of a normal power off event of the electronic device, wherein the normal power off event comprises a shutdown event, a restart event, or a hibernation event of the electronic device.

4. The electronic device of ciaim 1 , wherein the processor is to: read the second UEFI variable from the second storage region via the second UEFI runtime service; detect that the modification in the data attribute associated with the first UEFI variable affects the boot operation using the second UEFI variable; determine whether a pre~boot process of the electronic device has occurred after the data attribute has been modified using the boot count stored in the second UEFI variable; when the pre-boot process of the electronic device has not occurred after the data attribute has been modified, extract the modified data from the first storage region and return the modified data via the second UEFI variable interface; and when the pre-boot process of the electronic device has occurred after the data attribute has been modified, extract the previous data from the first storage region and return the previous data via the second UEFI runtime service.

5. The electronic device of claim 1 , wherein the processor is to: generate a third UEFI variable including the modified data and previous data associated with the data attribute: and store the third UEFI variable including the modified data and the previous data in a third storage region via the first UEFI runtime service, wherein the modified data or previous data is read from the third storage region via the second UEFI runtime service during a failure to read the modified data or previous data from the first storage region, and wherein the third storage region is part of the first non-volatile storage device or a separate non-volatile storage device.

6. A non-transitory computer-readable storage medium encoded with instructions that, when executed by a processor of an electronic device, cause the processor to: identify a modification to a data attribute; generate a cyclic redundancy check (ORC) for modified data and previous data associated with the data attribute; generate, via a first unified extensible firmware interface (UEFI) runtime service, a first UEFI variable including the modified data with the CRC and the previous data with the CRC in a first non-volatile storage region; generate, via the first UEFI runtime service, a second UEFI variable in a second non-volatile storage region, wherein the second UEFI variable is to include data indicating the modification to the data attribute and a counter to record boot count; and selectively read, via a second UEFI runtime service, the modified data or previous data from the first non-volatile storage region based on the second UEFI variable.

7. The non-transitory computer-readable storage medium of claim 6, further comprising instructions to: during a pre-boot process of the electronic device: read, via the second UEFI runtime service, the second UEFI variable from the second non-volatile storage region; detect that the data attribute has been modified based on the data in the second UEFI variable: and update the second UEFI variable to increment the boot count responsive to a detection that the data attribute has been modified, wherein the boot count is to indicate an unexpected shutdown of the electronic device after the data attribute has been modified.

8. The non-transitory computer-readable storage medium of claim 6, further comprising instructions to: clear the data that indicates the data attribute has been modified and the boot count from the second UEFI variable in response to a detection of a shutdown event, a restart event, or a hibernation event of the electronic device.

9. The non-transitory computer-readable storage medium of claim 6, wherein instructions to selectively read the modified data or previous data comprise instructions to: read, via the second UEFI runtime service, the second UEFI variable from the second non-volatile storage region; detect the modification in the data attribute associated with the first UEFI variable using the second UEFI variable; read, via the second UEFI runtime service, the first UEFI variable from the first non-volatile storage region in response to the detection; upon reading the first UEFI variable, verify data integrity of the modified data and the previous data with the generated CRC associated with the modified data and the previous data, respectively; upon the verification, determine whether an unexpected shutdown of the electronic device has occurred after the data attribute has been modified using the boot count in the second UEFI variable; when the unexpected shutdown of the electronic device has not occurred after the data attribute has been modified, return the modified data via the second UEFI variable interface; and when the unexpected shutdown of the electronic device has occurred, return the previous data via the second UEFI runtime service.

10. The non-transitory computer-readable storage medium of claim 6, further comprising instructions to: generate a third UEFI variable including the modified data with the generated CRC and the previous data with the generated CRC in a third nonvolatile storage region via the first UEFI runtime service, wherein the modified data or previous data is retrieved from the third non-volatile storage region via the second UEFI runtime service during a failure to read the modified data or previous data from the first non-volatile storage region, and wherein the first non-volatile storage region and the third non-volatile storage region are part of a same nonvolatile storage device or separate non-volatile storage devices.

11. The non-transitory computer-readabie storage medium of claim 6, wherein the first UEFI runtime service is a UEFI SetVariable service and the second UEFI runtime service is a UEFI GetVariabie service.

12. A non-transitory computer-readable storage medium encoded with instructions that, when executed by a processor of an electronic device, cause the processor to: during a pre-boot of the electronic device: read a first unified extensible firmware interface (UEFI) variable from a first non-volatile storage device; detect a modification to a data attribute based on the first UEFI variable, wherein the data attribute is stored in a second UEFI variable of a second non-volatile storage device; and update the first UEFI variable to record a boot count that indicates a number of times the electronic device is booted after the data attribute has been modified, wherein the boot count is used to selectively extract current data or previous data associated with the data attribute from the second UEFI variable via a first UEFI runtime service; and boot the electronic device to load an operating system upon recording the boot count.

13. The non-transitory computer-readable storage medium of claim 12, further comprising instructions to: during runtime and after the operating system has booted: clear the first UEFI variable including the boot count in response to a detection of a normal power off event of the electronic device, wherein the first UEFI variable is cleared via a second UEFI runtime service.

14. The non-transitory computer-readable storage medium of claim 12, wherein the instructions when executed further cause the processor to, in response to detecting a modification in the data attribute during a boot or an operating system environment of the electronic device, store the second UEFI variable including the modified data and the previous data in the second non-volatile storage device via a second UEFI runtime service.

15. The non-transitory computer-readable storage medium of claim 12, wherein the instructions when executed further cause the processor to: when the boot count indicates that the pre-boot of the electronic device has not occurred after the data attribute has been modified, return the current data associated with the data attribute from the second UEFI variable via the first UEFI runtime service, when the boot count indicates that the pre-boot of the electronic device has occurred after the data attribute has been modified, return the previous data associated with the data attribute from the second UEFI variable via the first UEFI runtime service, and wherein the extracted current data or the extracted previous data is used to perform a boot operation of the electronic device.