JP6204555B1 - Method, system firmware, and computer for protecting variables stored in non-volatile memory - Google Patents

Abstract

The operation of an OS is secured while protecting a GV referenced by UEFI firmware. A firmware ROM 100 stores UEFI firmware 150, a protection target GV153, and a non-protection target GV155. The protection target GV153 and the non-protection target GV155 are referred to by the UEFI firmware for pre-booting. The OS can modify the protection target GV in order to construct a natural operating environment after the end of preboot. Since the protection target GV153 recorded in the firmware ROM includes data related to booting and system configuration, the next preboot may fail if it is modified by the OS. The UEFI firmware copies the protection target GV to the system memory before the preboot is completed. Access to the protection target GV by the OS after the end of preboot is processed on the system memory. [Selection] Figure 2

Description

  The present invention relates to a technique for preventing malfunction of a computer, and further relates to a technique for protecting a variable stored in a computer conforming to UEFI (Unified Extensible Firmware Interface) standard.

  Computer firmware is primarily code that provides an interface between hardware and a higher-level program such as an operating system (OS), device driver or application. Firmware can be divided into device firmware that exclusively controls peripheral devices and system firmware (also referred to as platform firmware) related to the operation of the entire system.

  System firmware is typically stored in non-volatile memory (NVRAM) attached to the motherboard. The BIOS is a system firmware that has been implemented in many computer systems so far, and performs POST (Power On Self-Test) and password processing after the computer power is turned on until the OS starts loading. Or provide a service for the OS to access the hardware.

  However, since BIOS has become difficult to deal with hardware that has evolved in recent years, the UEFI Forum has formulated the UEFI standard as a new system firmware that replaces legacy BIOS, which is a conventional BIOS. The UEFI standard prescribes variable services. The variable service stores global variables (GV: Global Variables), which are variables defined in the UEFI standard, in a nonvolatile memory.

  In general, a personal computer (PC) registers GV in a nonvolatile memory that stores UEFI firmware. The UEFI standard defines the openness of GV, and can modify, delete, and add to the GV in which the OS and OS application are registered. Patent Document 1 discloses an invention in which a default value registered in advance is corrected when it is determined that a predetermined GV has been altered at the time of booting.

JP2015-153198A

  The GV includes data regarding the path to the boot device used by the UEFI firmware in the boot routine, the boot device selection order, and the hardware configuration. When such GV is modified by the OS, the UEFI firmware cannot perform scheduled PC startup processing, which may result in system startup failure or hardware malfunction. Therefore, in order for the UEFI firmware to correctly execute the boot routine, it is necessary to maintain the consistency of the main GV.

  However, due to the publicity of GV according to the UEFI standard, GV may be altered by writing due to incorrect parameter settings or writing by malware. In the legacy BIOS, the nonvolatile memory in which a variable corresponding to GV is written can be write-protected with respect to the OS execution environment. Can not be adopted.

  Further, the OS may not be installed unless a predetermined GV is modified. Therefore, it is impossible to individually write protect the protection target GV using the authentication service (Variable Authentication) defined by the UEFI standard, and to write lock the nonvolatile memory. In the invention of Patent Document 1, if the OS modifies or deletes the GV in the previous boot, the UEFI firmware rewrites the GV with a default value at the time of this boot, so the UEFI firmware allows the OS to rewrite the GV. The boot routine can be made unimpeded.

  However, rewriting the non-volatile memory causes a delay in boot time. In addition, since the OS frequently changes the GV, rewriting occurs at every boot. In the nonvolatile memory, when the number of times of erasing and writing increases, the oxide film deteriorates and the reliability of memory retention decreases. The present invention is based on such a background, and an object thereof is to solve various problems for protecting a variable referred to by a system firmware such as UEFI firmware at startup.

  In one aspect of the invention, the non-volatile memory stores variables that can be modified by the operating system. The system firmware allows the computer to perform a pre-boot by referring to the variable, to recognize the variable as either a protected variable or an unprotected variable, and to copy the protected variable to alternative memory, A function for determining an access destination according to a request for accessing a variable is realized. The variable may be a global variable defined in the UEFI standard.

  In another aspect of the invention, the computer protects variables stored in non-volatile memory. Dividing the variable into protected and unprotected variables, performing a boot with reference to the variable, copying the protected variable to alternate memory, and requesting the variable to be modified from the operating system. And receiving and modifying the protection target variable copied to the alternative memory when the target of the request is the protection target variable. When the target of the request is an unprotected variable, the unprotected variable stored in the non-volatile memory can be modified

  According to the present invention, any or all of the following effects could be achieved. First, the variables accessed by the system firmware could be protected. Secondly, such variables could be protected while allowing the OS to operate normally. Furthermore, such variables could be protected while not causing boot delays. Furthermore, such a variable could be protected while preventing the number of writes to the nonvolatile memory from increasing.

2 is a schematic functional block diagram showing a configuration of main hardware of a PC 10. FIG. 3 is a diagram illustrating an example of a data structure of a firmware ROM 100. FIG. It is a figure which shows the hierarchical structure in the execution state of the software which PC10 mounts. It is a flowchart which shows an example of the procedure in which UEFI firmware 150 controls access with respect to a variable area. It is a flowchart which shows an example of the procedure which copies the protection object GV153 to the SMRAM area | region 15a. It is a flowchart which shows an example of the operation | movement procedure of variable service.

[General hardware configuration]
FIG. 1 is a functional block diagram showing a main hardware configuration of a notebook type or laptop type PC 10. Many hardware configurations are well known and will be described within the scope necessary for understanding the present invention. The chip set 13 has interface functions of various standards, and includes a CPU 11, a system memory (RAM) 15, a GPU 17, an HDD 21, a USB connector 23, a network module 25 for connecting to a wired or wireless LAN, and a keyboard. 29 and the like are connected. An LCD 19 is connected to the GPU 17. Further, a firmware ROM 100 is connected to an SPI (Serial Peripheral Interface) controller 14 included in the chip set 13.

  In the memory space of the system memory 15, an SMRAM area 15a is secured when the system power supply is activated. The SMRAM area 15a is an area for loading a code to be executed when the CPU 11 operates in the system management mode (SMM). The HDD 21 is a boot device and stores an OS boot image corresponding to the UEFI standard.

  The boot sector of the HDD 21 stores a UEFI_OS loader 163 (FIG. 3) for loading an OS boot image. A USB device such as an external USB memory, USB_CD, USB_FDD, or USB_HDD can be connected to the USB connector 23. The PC 10 can also boot from a USB device that stores a boot image connected to the USB connector 23. The PC 10 can receive a boot image of the OS through the network module 25 and perform PXE boot by using a function such as PXE (Preboot eXecution Environment).

[Firmware ROM data structure]
FIG. 2 is a diagram showing a data structure of the firmware ROM 100, and FIG. 3 is a diagram showing a hierarchical structure of software loaded in the system memory 15 and in an execution state. The firmware ROM 100 is a flash memory that is non-volatile and can be electrically rewritten, and, as an example, is divided into memory blocks including a code area 101, variable areas 103 to 109, and a data area 111. The storage blocks of the variable areas 103 to 109 and the data area 111 may be provided in a nonvolatile memory different from the firmware ROM 100.

  The code area 101 stores codes of the UEFI firmware 150 and the UEFI application 165. The variable area 103 stores a default GV 151, and the variable area 105 stores a GV composed of a protection target GV 153 and a non-protection target GV 155. In the following, when the protection target GV153 and the non-protection target GV155 are not distinguished, they are simply referred to as GV. The variable area 107 stores Configuration Variables (CV) 157, and the variable area 109 stores User Variables (UV) 159. The data area 111 stores a control list 161.

  First, the variables stored in the variable areas 103 to 109 will be described. The default GV 151 is a GV written by the UEFI vendor, and is used by the user to initialize the system when an abnormality occurs in the operation of the system or for some reason. In this embodiment, the default GV 151 is not used to replace the GV in the variable area 105 at every boot.

  GV is defined in the UEFI standard, and is guaranteed to be accessible from any of the UEFI firmware 150, the UEFI application 165, the OS 167, and the OS application 169 (FIG. 3). In the following, the OS application 169 may be included when referred to as the OS 167. Access to the GV corresponds to writing, changing, deleting, reading, etc. of a new GV. Writing, changing, and deleting GV calls a function called SetVariable that constitutes a function of the original variable service 150b or the new variable service 150f.

  Reading GV calls a function called GetVariable that constitutes the function of the original variable service 150b or the new variable service 150f. For example, the protection target GV153 is related to booting such as boot device type such as Boot ####, BootOrder, BootNext, Driver ####, DriverOrder, and its selection order, and device driver type and its selection order. Variable to be included. Furthermore, the protection target GV includes variables related to the hardware configuration such as paths to input / output devices such as ConIn and ConOut.

  If the protection target GV 153 is rewritten by a program other than the UEFI firmware 150, the system may not be able to start up normally. A modification with a GV problem occurs when the OS 167, UEFI application 165 or malware calls SetVariable. The protection target GV153 corresponds to a variable that is a target to be protected from a problematic modification.

  The user can modify the protection target GV 153 through the setup screen of the UEFI firmware 150. In this case, since the UEFI firmware 150 recognizes it, it does not correspond to a problematic modification. The protection of GV means that the protection target GV153 stored in the variable area 105, which is an example of a place where the UEFI firmware 150 accesses to execute the boot routine, is not modified by a program other than the UEFI firmware 150. .

  In this embodiment, the OS 167 can access the protection target GV 153 necessary for a predetermined operation while protecting the GV as described with reference to FIGS. The non-protection target GV155 is a GV other than the protection target GV153, and corresponds to a variable not related to the boot or hardware configuration. The unprotected target GV 155 may exist in a state modified by a program other than the UEFI firmware 150 in the variable area 105 when the UEFI firmware 150 executes a boot routine.

  The CV 157 corresponds to a variable written in the variable area 107 by the UEFI firmware 150 for processing such as device recognition and initialization at the time of booting. CV157 is defined by the UEFI firmware 150 vendor. The UEFI firmware 150 can write the CV 157 using the original variable service 150b.

  The CV157 is device attribute information set by the UEFI firmware 150 and parameters to be set in the device, device type set by the user by calling the setup screen, device operation mode, and setting information such as device enable / disable, It includes information such as the path of the partition where the boot image is stored and the type of OS to be loaded. The CV 157 includes variables indispensable for booting. However, since the publicity is not required in the UEFI standard, the variable area 107 can be write-locked to be protected from modification by the OS 167 or malware.

  UV159 is an environment variable that allows the OS 167 and UEFI application 165 to customize itself during execution, and a dump file such as a debug log or error log that can be freely written without being restricted by the UEFI standard. Equivalent to. The UEFI firmware 150 can write UV159 using the original variable service 150b.

  In the present embodiment, recording areas that can be write-locked by the SPI controller 14 of the chipset 13 are allocated to the code area 101, the variable areas 103 and 107, and the data area 109. In the recording area where the write lock is executed, writing of all programs is prohibited until the chip set 13 is reset. The UEFI firmware 150 writes and locks the code area 101, the variable areas 103 and 107, and the data area 111 of the firmware ROM 100 before passing the control right of the CPU 11 to other codes from the code guaranteed to be safe at the time of booting. be able to.

  The UEFI firmware 150 includes an initialization code 150a, an original variable services 150b, a boot manager 150c, a setup code 150d, a GV control code 150e, a new variable service 150f, and a UEFI driver 150g. . In one example, the UEFI firmware 150 can employ a boot block method in order to reduce the risk associated with rewriting. In the boot block method, an area for storing the initialization code 150a is set as a boot block. The code stored in the boot block is handled as CRTM (Core Root Of Trust Measurement) defined in the TPM (Trusted Platform Module) specification and cannot be rewritten without special authority.

  The CRTM is configured as a part of the platform initialization code where integrity is guaranteed and is always executed first when the platform is reset. The CRTM is always executed at the time of so-called cold boot, which is an operation process for the PC 10 to transition from the hibernation state (S4 state) or the power-off state (S5 state) to the power-on state (S0 state) specified in ACPI. First run.

  The initialization code 150a is stored in the CPU 11, the system memory 15 and other basic devices necessary for loading the UEFI firmware 150 into the system memory 15 and starting execution when the PC 10 is cold booted. Perform detection, inspection, and initialization as necessary. The initialization code 150a also initializes a predetermined device such as a controller of the chipset 13 or a peripheral device in a period from when the CPU 11 is reset to when control is transferred to the UEFI_OS loader 163. The initialization code 150a stops booting if it checks for consistency or integrity from the original of the UEFI firmware 150 code and finds tampering.

  The original variable service 150 b includes functions such as GetVariable, GetNextVariableName, and SetVariable for accessing the GV stored in the variable area 105. The boot manager 150c performs boot processing and password authentication processing. When the boot routine by the UEFI firmware 150 is completed, the boot manager 150 c loads the UEFI application 165 and the UEFI_OS loader 163 into the system memory 15. Here, the operation state from when the system is cold booted until the control right of the CPU 11 is transferred to a code other than the UEFI firmware 150 is referred to as preboot.

  Preboot can be said to be an operating state in which code whose consistency has been verified by CRTM is executed. It can also be said that the pre-boot is an operation state until the code area 101 is write-locked by the SPI controller 14. During the preboot, only the UEFI firmware 150 that is secured can modify the GV in the variable area 105. The boot manager 150c can read out the UEFI_OS loader 163 to the system memory 15 and verify the integrity immediately before the end of pre-boot and the control of the CPU 11 from the UEFI firmware 150 to the OS 167.

  In this specification, booting refers to a series of processes from when the power is activated until the loading of the OS 167 is completed via preboot. The UEFI_OS loader 163 has an electronic signature obtained by encrypting a hash value calculated by the creator with a secret key. The boot manager 150c compares the hash value calculated from the code of the UEFI_OS loader 163 with the hash value of the electronic signature obtained by decrypting with the public key acquired from the signature data base. Is permitted to execute the UEFI_OS loader 163.

  The set-up code 150d displays a set-up screen on the LCD 19 when a predetermined function key of the keyboard 29 is pressed at the pre-boot stage. Through the setup screen, the user can determine the priority of the boot device, set the startup method, set the device to be used, set the password, and set the power management.

  The setup code 150d writes the setting information input through the setup screen as a CV in the variable area 107 as an example. The modification of the protection target GV performed through the setup code 150d does not cause a problem in the boot routine because the UEFI firmware 150 recognizes it. Also, the UEFI application 165 and the OS 167 can modify the GV based on unique needs.

  As a result, since the modification of the protection target GV 153 may affect the boot routine of the UEFI firmware 150, in this embodiment, the protection target GV 153 in the variable area 105 is protected from modification by the UEFI application 165 or the OS 167. On the other hand, there are cases where the intended operating environment cannot be constructed unless the OS 167 modifies the protection target GV153. In order to cope with such a situation, the setup screen includes a menu for setting enable / disable for the protection function of the GV according to the present embodiment. Enable / disable setting information is recorded in a predetermined location of the firmware ROM 100.

  The GV control code 150e performs processing for protecting the GV, which is described in the procedure of FIGS. The new variable service 150f includes functions such as GetVariable, GetNextVariableName, and SetVariable for accessing the protection target GV153 copied by the OS 167 and the UEFI application 165 to the SMRAM area 15a, as described with reference to FIGS. The UEFI application 165 operates on the upper layer of the UEFI firmware 150, and the UEFI driver 150g performs processing for the UEFI firmware 150 to access specific hardware. The control list 161 describes the identifiers (VendorGuid and VariableName) of the protection target GV153.

[Procedure to prohibit modification of protected GV]
4 to 7 are flowcharts illustrating an example of a procedure in which the UEFI firmware 150 protects the GV. In block 201 of FIG. 4, the PC 10 is powered on and the system starts a cold boot. At this time, as shown in FIG. 2, the protection target GV 153 and the non-protection target GV 155 are stored in the variable area 105, the CV 157 is stored in the variable area 107, the UV 159 is stored in the variable area 109, and the data area 111. Stores a control list 161. Since there is a procedure of block 217 described in detail in FIG. 6, it is guaranteed that the protection target GV 153 stored in the variable area 105 has not been modified in the previous boot.

  The power-on-reset chipset 13 releases the write lock on the code area 101, variable areas 103 and 107, and data area 111 of the firmware ROM 100 set in the SPI controller 14 in block 203. Subsequently, the UEFI firmware 150 is loaded into the system memory 15 when the initialization code 150a initializes a device required for preboot in block 205. The initialization code 150a refers to the protection target GV 153 stored in the variable area 105 and the CV 157 stored in the variable area 107, and initializes other devices within a necessary range. Subsequently, the UEFI firmware 150 starts POST (Power On Self-Test).

  During preboot, the UEFI firmware 150 modifies the GV in the variable area 105 at block 207. The UEFI firmware 150 is verified for consistency by the initialization code 150a, or is protected by the write lock of the SPI controller 15a in the operating environment of the OS, so there is no risk of contamination by malware, and the protected GV153 is modified. But it won't interfere with the next pre-boot. At block 208, the user can invoke a setup screen to enable or disable GV protection.

  In block 209, the GV control code 150 e copies only the protection target GV 153 in the GV stored in the variable area 105 to an alternative memory such as the SMRAM area 15 a of the system memory 15. The system memory 15 is desirable as an alternative memory because of its high writing speed, but it is not necessary to limit the save destination to the system memory 15. Further, since the protection target GV 153 to be copied to the alternative memory is not used in the next preboot, the alternative memory may be a volatile memory or a nonvolatile memory. The timing for copying the protection target GV 153 can be from the end of the modification of the protection target GV 153 by the UEFI firmware 150 to the end of preboot.

  FIG. 5 is a flowchart showing an example of the procedure of block 209 in FIG. The GV control code 150e that has recognized the end timing of preboot in block 213 calls GetNextVariableName of the original variable service 150b and reads GV from the variable area 105 in block 233. GetNextVariableName is a function that enumerates all the variables of GV, CV, and UV that can be used in the system, and returns the identifier of the variable next to the variable that is held when called to the GV control code 150e. GetNextVariableName returns an error when called further after returning all identifiers of GV, CV, and UV. In block 235, the GV control code 150e determines that all GV, CV, and UV variables have been read when an error is received from the original variable service 150b, and the process ends in block 241.

  The GV control code 150e that received the variable identifier from the original variable service 150b determines in block 237 whether the GV read with reference to the control list 161 is the protection target GV 153 registered in the control list 161. To do. When it is determined that it is the protection target GV153, the process proceeds to block 239, and when it is determined that it is the non-protection target GV155, the process returns to block 233. In block 239, the GV control code 150e copies the protection target GV153 to the SMRAM area 15a, and then returns to block 233.

  The GV control code 150e further calls GetNextVariableName at block 233 to acquire the identifier of the next variable, and at block 237, determines whether or not it is a protection target GV153. When the procedures of blocks 231 to 241 are executed, all of the protection target GV153 in the GV stored in the variable area 105 is copied to the SMRAM area 15a.

  Copying to the SMRAM area 15a can also be performed by other methods. For example, the variable area 105 is divided into a storage block that stores only the protection target GV153 and a storage block that stores only the non-protection target GV155. At the time of copying, the address of the storage block that stores only the protection target GV153 is designated. According to this method, it is possible to copy all the protection target GV153 without using the control list 161.

  Returning to FIG. 4, in block 211, the GV control code 150e sets the SPI controller 14 of the chipset 13 to write / lock the code area 101, the variable areas 103 and 107, and the data area 111 immediately before the preboot is completed. To do. When the preboot is completed in block 213, the boot manager 150c loads the UEFI application 165 from the code area 101 to the system memory 150 and loads the UEFI_OS loader 163 from a predetermined sector of the HDD 21 in block 215.

  Eventually, the OS 167 is loaded and the PC 10 shifts to the OS boot state. At block 217, the OS 167 can access the GV. Details of the procedure of block 217 will be described with reference to FIG. After the transition to the power-off state at block 219, the process returns to block 201 to perform the next cold boot. At this time, since the protection target GV153 in the variable area 103 is protected in the procedure of the block 217, the next pre-boot does not fail.

  FIG. 6 is a flowchart showing an example of the procedure of block 217 in FIG. In block 251, a caller corresponding to any of the UEFI firmware 150, the UEFI application 165, and the OS 167 calls GetVariable or SetVariable to access the GV. Blocks 253 to 256 correspond to determination of GV protection conditions. In block 253, the GV control code 150e shifts to block 261 when it is determined that the access was performed during pre-boot, and shifts to block 255 when it is determined that the access was performed after the pre-boot was completed.

  When shifting from the block 253 to the block 261, either the protection target GV153 or the non-protection target GV155 is an access target. If the modification of the protection target GV153 stored in the variable area 105 is permitted in the operating environment after the preboot is completed, there is a possibility that a problem will occur in the next boot. Therefore, the protection function of GV should be enabled in principle. Is desirable. However, the user may need to permit modification of the protection target GV 153 in the variable area 105 in consideration of the safety of the protection target GV 153.

  For example, when the protection target GV 153 is set to boot the OS 167 from a local boot device, it may be desired to perform a PXE boot via a network. At this time, the remote boot cannot be realized unless the OS 167 modifies the boot order of the protection target GV 153 in the variable area 105. Some anti-virus software is loaded and executed prior to the OS after pre-boot is completed. In this case as well, it is necessary to allow modification of the protection target GV153 in the variable area 153 by the anti-virus software.

  When the OS 167 needs to modify the protection target GV 153 in the variable area 105, the user sets the GV protection function to disabled through the setup screen. In block 255, the GV control code 150e determines the GV protection function from the setting information recorded in the firmware ROM 100. The GV control code 150e shifts to block 256 when the GV protection function is set to enable, and shifts to block 261 when the GV control code 150e is disabled.

  When moving from the block 255 to the block 261, either the protection target GV153 or the non-protection target GV155 is an access target. In block 256, the GV control code 150e refers to the control list 161. When the GV accessed by the caller is determined to be the protection target GV153, the process proceeds to block 257. When the GV control code 150e is determined to be the non-protection target GV155, the process proceeds to block 261. To do. In block 257, the GV control code 150e passes the identifier of the GV requested by the caller to the new variable service 150f.

  In block 259, the new variable service 150f accesses the protected GV 153 copied to the SMRAM area 15a and returns an identifier to the caller. In block 261, the GV control code 150e passes the identifier of the GV requested by the caller to the original variable service 150b. In block 263, the original variable service 150 b accesses the unprotected GV 155 in the variable area 105 and returns a return value to the caller.

  In the procedure of FIG. 6, when the GV protection condition is satisfied, the protection target GV153 copied to the SMRAM area 15a is modified by the OS 167, but the protection target GV153 of the variable area 105 is not modified. The OS 167 does not need to specify the access destination in the SMRAM area 15a, and can operate by reading the modified protection target GV153 by modifying the protection target GV153 in the same procedure as accessing the original variable service 150b.

  The OS 167 may not be installed unless the protection target GV 153 is modified. For example, when installing the OS 167 in a state where the PXE boot is set as the first order in the protection target GV 153 in the variable area 105, the installation may fail unless the OS 167 sets itself as the first order of boot. According to the procedure of FIG. 6, the OS 167 can set the boot order on the SMRAM area 15a to make the installation successful. However, since the protection target GV 153 in the variable area 105 is not modified, the UEFI firmware 105 can subsequently perform PXE boot.

  The OS 167 can modify the non-protection target GV155 stored in the variable area 105, but the modification of the non-protection target GV155 does not cause a failure in the operation of the system. In the procedure of FIG. 6, it takes time to copy the protection target GV153 to the SMRAM area 15a. However, copying to the SMRAM area 15a can be completed in a shorter time than rewriting the variable area 105 with the default GV151. There is no problem.

  When a transition to the power-off state is made at block 219 in FIG. 4, the protection target GV153 in the SMRAM area 15a is erased. Even though the OS 167 intends to modify the protection target GV153, the protection target GV153 in the variable area 105 has not been modified. However, even if the OS 167 modifies the protection target GV153 in the variable area 105, the user may modify the protection target GV153 through the setup screen at the next preboot.

  Even if the OS 167 normally rewrites the protection target GV 153 stored in the variable area 105 in the previous boot, the OS 167 performs processing to modify the protection target GV 153 even in the current boot in order to surely set the environment. Accordingly, since the OS 167 repeats the same modification procedure every boot, even if the protection target GV 153 in the SMRAM area 15a is erased, no additional processing occurs at the next boot.

  4 to 6, modification of the protection target GV 153 of the variable area 105 by the OS 167 is prohibited, and modification of the non-protection target GV 155 is permitted. Here, it may be considered that the OS 167 prohibits modification of the unprotected GV 155 in the variable area 105. However, since the modification of the unprotected GV 155 does not interfere with the boot routine of the UEFI firmware 150 and rather it is desirable to maintain the operating environment intended by the OS 167, in this embodiment, the modification of the unprotected GV by the OS 167 is performed. Is allowed.

  In addition, once the protection target GV153 and the non-protection target GV155 are copied to the SMRAM area 15a, the modification is performed in the SMRAM area 15a, and only the modified non-protection target GV155 is changed in the power-off state. It is also conceivable to write in the area 105. At this time, when the power supply is suddenly shut down and the data in the SMRAM area 15a is lost, the modified unprotected object GV155 is lost. However, in this embodiment, such a situation does not occur.

  The procedures shown in FIGS. 4 to 6 are exemplifications for explaining the present invention, and all are not essential procedures of the present invention. The essential steps of the invention are as set out in the claims. Further, the order of the blocks is not limited to the order shown in FIGS. For example, the procedures in blocks 253 to 256 in FIG. 6 may be performed in any order. The present invention can also be understood as a system realized by hardware elements configured by the cooperation of the hardware shown in FIG. 1 and the software shown in FIGS.

  Although the present invention has been described with the specific embodiments shown in the drawings, the present invention is not limited to the embodiments shown in the drawings, and is known so far as long as the effects of the present invention are achieved. It goes without saying that any configuration can be adopted.

10 PC
15 System memory 15a SMRAM area 100 Firmware ROM
101 Code area 103, 105, 107, 109 Variable area 150 UEFI firmware 150b Original variable service 150f New variable service 153 Protection target GV
155 Unprotected GV

Claims (17)

A computer that implements non-volatile memory that stores variables that the operating system can modify,
A function of performing a pre-boot with reference to the variable;
A function of recognizing the variable as either a protected variable or a non-protected variable;
A function of copying the protected variable to an alternative memory;
In order to realize a function of determining that the access destination of the request is the non-volatile memory when there is a request for accessing the variable, in accordance with the recognition that the request has occurred before the end of the preboot. System firmware.   The system firmware according to claim 1, wherein the protection target variable is a variable that the system firmware refers to in the preboot in order to execute a boot routine.   The system firmware according to claim 1, wherein the protection target variable is a variable that specifies a storage location of a boot image loaded by the operating system.   The system firmware of claim 1, wherein the request is a write of the variable.   The system firmware according to claim 1, wherein the recognition function refers to a list in which identifiers of the protection target variables are registered.   The system firmware of claim 1, wherein the alternative memory is a volatile memory.   The system firmware according to claim 1, wherein the copying function is executed before the nonvolatile memory is write-locked. A computer that implements non-volatile memory that stores variables that the operating system can modify,
A function of performing a pre-boot with reference to the variable;
A function of recognizing the variable as either a protected variable or a non-protected variable;
A function of copying the protected variable to an alternative memory;
When there is a request to access the variable, the access destination of the request is set to the non-volatile in accordance with the recognition that the protection of the variable is disabled through the setup screen of the system firmware. System firmware for realizing the function of determining the volatile memory . A computer that implements non-volatile memory that stores variables that the operating system can modify,
A function of performing a pre-boot with reference to the variable;
A function of recognizing the variable as either a protected variable or a non-protected variable;
A function of copying the protected variable to an alternative memory;
When there is a request for accessing the variable, a function for determining that the access destination of the request is the non-volatile memory according to recognition that the target of the request is the non-protected variable System firmware for. A computer that implements non-volatile memory that stores variables that the operating system can modify,
A function of performing a pre-boot with reference to the variable;
A function of recognizing the variable as either a protected variable or a non-protected variable;
A function of copying the protected variable to an alternative memory;
When there is a request to access the variable, the request is generated after completion of the preboot, and the access destination of the request is determined according to recognition that the target of the request is the protection target variable. System firmware for realizing the function of determining the replacement memory . A method for protecting variables stored in non-volatile memory by a computer,
Partitioning the variables into protected variables and unprotected variables;
Performing a boot with reference to the variable;
Copying the protected variable to an alternative memory;
Receiving a request to modify the variable from an operating system;
Modifying the protected variable copied to the alternative memory when the target of the request is the protected variable. The method according to claim 11 , further comprising modifying the non-protection target variable stored in the nonvolatile memory when the target of the request is the non-protection target variable. 12. The method of claim 11 , comprising erasing the modified protected variable stored in the alternate memory prior to a next boot. Non-volatile memory for storing variables referenced by system firmware;
A control list capable of distinguishing the variables into protected variables and unprotected variables;
A saving unit that saves the protection target variable in an alternative memory before pre-booting is completed;
A variable protection unit that sets the access destination of the request in the nonvolatile memory in response to recognition that the request has occurred before the end of the preboot when there is a request to access the variable Computer. Non-volatile memory for storing variables referenced by system firmware;
A control list capable of distinguishing the variables into protected variables and unprotected variables;
A saving unit that saves the protection target variable in an alternative memory before pre-booting is completed;
When there is a request to access the variable, the access destination of the request is set to the non-volatile in accordance with the recognition that the protection of the variable is disabled through the setup screen of the system firmware. And a variable protection unit to be set in the memory . Non-volatile memory for storing variables referenced by system firmware;
A control list capable of distinguishing the variables into protected variables and unprotected variables;
A saving unit that saves the protection target variable in an alternative memory before pre-booting is completed;
When there is a request for accessing the variable, a variable protection unit that sets the access destination of the request in the nonvolatile memory according to recognition that the target of the request is the non-protection target variable. Computer with. Non-volatile memory for storing variables referenced by system firmware;
A control list capable of distinguishing the variables into protected variables and unprotected variables;
A saving unit that saves the protection target variable in an alternative memory before pre-booting is completed;
When there is a request to access the variable, the request is generated after completion of the preboot, and the access destination of the request is determined according to recognition that the target of the request is the protection target variable. A computer having a variable protection unit set in the alternative memory ;

Images