Secure recovery apparatus and method

A system and method is disclosed for recovering a boot image from a secure location. Hardware instructions initiate a sequence of boot cycles to launch a computer operating system on a computer-enabled device. During the boot cycles, multiple levels of boot code are verified and a determination is made whether each level is usable by the device. If a level of boot code is determined to be unusable, a secure copy of the boot code is loaded from a secure read-only location to repair the unusable code to launch the computer operating system.

TECHNICAL FIELD

The subject technology relates generally to computer recovery systems and methods, namely recovering an operating system or firmware.

BACKGROUND

Some computers (for example, notebooks) support a recovery mode, which is capable of restoring a computer back to a good state when its rewritable operating system and/or firmware becomes corrupted or compromised. Generally, a user initiates a recovery mode via a keystroke on boot-up of the computer. In some cases, the notebook can initiate the recovery mode on its own, if it determines there is a problem with the firmware and/or operating system. While the foregoing solution has been the mainstream approach, the user nevertheless needs a separate recovery device. If the user doesn't have a recovery device (SD card or USB stick), the user must create one by downloading and running an installer on a second computer. After the recovery device is inserted, the system will boot from recovery device and attempt to repair itself. If the user has an old recovery device, the user must first manually update it.

SUMMARY

The subject technology provides a system and method for loading a boot image from a secure location. The system includes a machine-readable medium having machine-executable instructions stored thereon, which when executed by a machine or computer cause the machine or computer to perform a method of loading a boot image. According to one aspect, the method includes initiating a sequence of boot cycles, each cycle loading a level of boot code from a memory medium, determining a level of boot code is unusable, and loading a secure copy of the level of boot code from a secure read-only location, wherein the secure read-only location is not associated with the memory medium. The secure read-only location may include an integrated circuit chip located on a system control board of a computer. In another aspect, the method may include verifying a last known verifiable level of code before determining the level of boot code is unusable, stopping the sequence of boot cycles on determining the level of boot code is unusable, repairing the unusable level of boot code using the secure copy, and resuming the boot cycle at the last known verifiable level. The method may be initiated automatically on the detection of a boot failure, or on indication by a user (for example, via, a dedicated button or keystroke during boot-up of the machine or computer).

DETAILED DESCRIPTION

Modern computers may include various backup and recovery mechanisms. Due to data corruption (for example, resulting from malicious software or hardware failures), it may be desirable to replace or repair an image of firmware or an operating system on a bootable hard drive or other storage mechanism. However, restoring the image using a recovery image may be a complex, if not a difficult process, and the recovery image itself may also be susceptible to data corruption. Thus, recovering a corrupted image may inevitably require intervention by a computer technician at substantial cost. The subject technology provides a secure bank of data that a user can turn to when everything else fails, alleviating the need for intervention by the user or computer technician.

FIG. 1is an exemplary diagram of an apparatus and system for loading a boot image, including a firmware and secure memory location, according to one aspect of the subject technology. According to one aspect, a computer system100may include a system board101(for example, a motherboard), including a processor102and one or more firmware103, and a hard drive104. System100may be configured to startup operations using one or more boot images105spanning both firmware, kernel partitions, and/or a root file system of an operating system, with each boot image including multiple levels of boot code. For example, a boot image105may be stored on hard drive104. In other aspects, one or more redundant boot images106may be included (for example, on a hidden partition of hard drive104or other rewritable memory) which correspond to and are redundant to boot image105, providing a copy of boot image105should it fail.

System100may also include a secure memory location107associated with, or located on, system board101. For example, secure memory location107may be implemented as an integrated circuit chip located on, or integrated with, system control board101. This secure bank of data may be implemented as a secure read-only memory hardware that stores one or more secure images108, including a trusted boot code for restoring all or a portion of a boot path of a computer-enabled device. In one aspect, secure image108may provide a copy of boot image105. Because it is a read-only copy of a known good image, and separated from the kernel and/or hard disk, the boot code therein may be considered trusted. In some aspects, on a boot failure, a recovery using secure image108may be triggered by a hardware switch or by a series of keystrokes during the boot cycle. In other aspects, as described below, secure memory location107may be automatically accessed by system100on the boot failure.

Firmware103may include initiation and recovery instructions109, that, when executed by the processor, may be operable to cause the processor to load and perform a verification of a boot image. In the case boot image105, or one or more portions thereof, is determined by the verification to be unusable (for example, corrupted), instructions109may access secure location107to load the operating system using secure image108. Alternatively, on determining boot image105cannot be verified or is unusable, instructions109may attempt to load and perform a second verification of a redundant boot image106. In the case redundant boot image106is also determined by the second verification to be unusable, the software may load and execute secure boot image108.

As system100is booted, a cryptographic key may be used to verify the boot image, or a portion of the boot image. In this regard, system100may perform a checksum at each level up from a core trusted piece of boot code, and, if a code abnormality and/or boot failure is determined, a redundant copy of the image, or one or more portions thereof, may be loaded to recover the boot path. Redundant image106(and secure image108) may include a copy of the entire image or one or more levels of boot code, and may also be verified with the cryptographic key. As previously described, if the redundant copy is determined to be unusable, system100may recover the level of boot code from secure memory location107.

Boot image105, redundant boot image106, and secure boot image108may include a boot code for a single boot level, or may include code partitioned into multiple levels. Since boot code may be restored on a level by level basis, once an unusable image, or portion thereof, is determined, the process may be operable to stop the boot cycle, access redundant copy106and/or secure copy108to repair that portion of code, and then resume the boot cycle at the last known verifiable level. For example, if there is a failure at the firmware level (EC to read-only to rewritable) the process may restart at the next firmware level. However, if the kernel fails then it may restart the boot verification process at the end of the firmware levels. During the recovery process, if redundant boot code stored, for example, on a recovery partition of a hard drive is also found to be unusable, the system (automatically, or on a user-initiated keystroke or switch) may copy the relevant portion of secure image108from secure location107to hard drive104or the like, replacing the unusable redundant boot code. The redundant boot code may be further checked using the cryptographic key to verify that the secure image was copied correctly and/or that there are no hardware errors.

As described previously, secure location107may include a non-removable chip, for example, eMMC, EEPROM, NAND flash, or the like. Alternatively, the secure recovery image may be stored in a host protected area of a solid state drive, hidden from the operating system. For example, secure recovery image108may be stored on a write-protected partition of an eMMC of the drive, in another aspect, secure recovery image108may be stored on a secure digital (SD) or micro SD card. A computer implementation of system100may include a hidden slot inside the device, for example, inside the battery compartment. A recovery image may be updated by removing it from the computer and programming it on a separate computer (or by inserting it into the normal SD card slot on the device itself). In one example, an SD or micro SD recovery image may be kept separate from the main memory medium of the device, with system100configured ignore the advertisement of the memory medium's write protect switch to the operating system.

According to one aspect, an additional circuit may be provided with the SD device to prevent intrusion. This circuit may be latched in either an enabled state or disabled state. Once a state has been selected, it may stay active (for example, cannot be changed) until the system resets. When the circuit is enabled, the SD card may be electrically connected so that system100can boot from it. When the circuit is disabled, the SD card may be electrically disconnected, and the system may not boot to or write from it, protecting it from being altered by a malfunctioning operating system or remote attacker. In one aspect, the circuit state may be selected via a read-only boot stub firmware (for example, in firmware103). If system100determines that a recovery mode has been selected, it may enable the circuit. Otherwise, if it determines that the firmware should be rewritable, it may disable the circuit. In one example, the circuit state may be selected if a recovery button is activated on hardware associated with system100.

The previously described additional circuitry may also be included in an integrated circuit and/or full chip protection implementation so that the chip is operable only in recovery mode. In this regard, the additional circuit may control the write protect state of the chip so that the chip is writable in recovery mode, but read-only in other modes. To this end, the chip may be protected from accidental or malicious alteration during normal hoot, but may still allow updating the recovery image when in recovery mode.

FIG. 2is an exemplary diagram of an apparatus and system for restoring an operating system over a network according to one aspect of the subject technology. In some aspects, the previously described recovery mechanism may only install enough information to get to the operating system to a known good state, wherein the remainder of a core image may be pulled from other sources. For example, a computer-enabled device200may include one or more boot images on a firmware201, memory medium202(for example, a hard drive), and/or secure memory203to restore the operating system to a default version (for example, as discussed with reference toFIG. 1). In one aspect, the one or more boot images may include a network recovery image of a default operating system, including a limited feature set with network accessibility. After installation, the default operating system may automatically, or on user action, initiate a predefined sequence to pull updates from over a network204in order to update the operating system to the latest version. Updates to the operating system may be provided by one or more remote servers205. In this manner, the recovery process may first restore the computer to a usable place within a short period of time (for example, 30 seconds for a fast boot path) using the onboard recovery process, and then update the operating system in one or more background processes, providing the up-to-date operating system for use the next time the user reboots the computer.

In some aspects, as further operating system and firmware updates are released, secure image108may be automatically updated. In this manner, when the system needs to recover, the operating system and/or firmware can recover to an updated state instead of that which was available when the device already shipped from the factory. This may be significant in that the original factory software may have had security vulnerabilities at the time of its release. In a further aspect, system100may be configured to prevent the installation of an operating system that is older than the secure image. In this regard, on an attempt to install an operating system, a check may be performed against boot image105, redundant image106, or secure image107to verify that the operating system is at least as old as the image. The recovery image may also be able to disable the operating system protection so it can install the operating system and firmware which it contains, or it may include the previously described network recovery image so that it can fetch a current operating system and firmware over a network.

FIG. 3is a flowchart illustrating an exemplary process for loading a boot image from a secure location according to one aspect of the subject technology. In step301, system100initiates a sequence of boot cycles, with each cycle loading a level of boot code from a memory medium. In step302, system100attempts to load and execute boot code for a boot cycle, and, in step303, determines whether the boot code is usable. In one aspect, a verification of the code may be performed to determine whether it is usable to boot the device. In another aspect, the determination may result from a verification that the boot cycle did not fully execute, failed or produced errors, was corrupted, or the like.

If the boot code is usable, it is executed. Otherwise, in optional step304, on determining the boot image is determined by the verification to be unusable, system100attempts to load a redundant copy of the boot code. As described previously, this copy may be loaded from a hidden partition on hard drive104or other memory medium. In some aspects, one or more cycles of boot code, including a redundant copy, may be loaded from a firmware, for example, a read/write firmware. If system100attempts to load a redundant copy of boot code, in step305, system100will make a determination as to whether the redundant copy is also unusable. If the redundant boot code is usable, it is executed and the process ends. Otherwise, in step306, on determining the both original and redundant boot images are determined to be unusable, system100attempts to load a secure copy of the boot code from a secure location. In some aspects, the secure location used to load the secure image is not associated with the memory medium. To this end, if a redundant copy is stored on one memory medium such as a hard drive or memory stick, the secure location may be implemented as a read only firmware, for example, in an integrated circuit

FIG. 4is a diagram illustrating an exemplary server system for loading a boot image from a secure location, including a processor and other internal components, according to one aspect of the subject technology. In some aspects, a computerized device400(for example, computer system100or the like) includes several internal components such as a processor401, a system bus402, read-only memory403, system memory404, network interface405, I/O interface406, and the like. In one aspect, processor401may also be communication with a storage medium407(for example, a hard drive, database, or data cloud) via I/O interface406. In some aspects, all of these elements of device400may be integrated into a single device. In other aspects, these elements may be configured as separate components.

Processor401may be configured to execute code or instructions to perform the operations and functionality described herein, manage request flow and address mappings, and to perform calculations and generate commands. Processor401is configured to monitor and control the operation of the components in server400. The processor may be a general-purpose microprocessor, a microcontroller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a programmable logic device (PLD), a controller, a state machine, gated logic, discrete hardware components, or a combination of the foregoing. One or more sequences of instructions may be stored as firmware on a ROM within processor401. Likewise, one or more sequences of instructions may be software stored and read from system memory405, RUM403, or received from a storage medium407(for example, via I/O interface406). ROM403, system memory405, and storage medium407represent examples of machine or computer readable media on which instructions/code may be executable by processor401. Machine or computer readable media may generally refer to any medium or media used to provide instructions to processor401, including both volatile media, such as dynamic memory used for system memory404or for buffers within processor401, and non-volatile media, such as electronic media, optical media, and magnetic media.

In some aspects, processor401is configured to communicate with one or more external devices (for example, via I/O interface406). Processor401is further configured to read data stored in system memory404and/or storage medium407and to transfer the read data to the one or more external devices in response to a request from the one or more external devices. The read data may include one or more web pages and/or other software presentation to be rendered on the one or more external devices. The one or more external devices may include a computing system such as a personal computer, a server, a workstation, a laptop computer, PDA, smart phone, and the like.

In some aspects, system memory404represents volatile memory used to temporarily store data and information used to manage device400. According to one aspect of the subject technology, system memory404is random access memory (RAM) such as double data rate (DDR) RAM, Other types of RAM also may be used to implement system memory504. Memory404may be implemented using a single RAM module or multiple RAM modules. While system memory404is depicted as being part of device400, those skilled in the art will recognize that system memory404may be separate from device400without departing from the scope of the subject technology. Alternatively, system memory404may be a non-volatile memory such as a magnetic disk, flash memory, peripheral SSD, and the like.

I/O interface406may be configured to be coupled to one or more external devices, to receive data from the one or more external devices and to send data to the one or more external devices. I/O interface406may include both electrical and physical connections for operably coupling I/O interface406to processor401, for example, via, the bus402. I/O interface406is configured to communicate data, addresses, and control signals between the internal components attached to bus402(for example, processor401) and one or more external devices (for example, a hard drive). I/O interface406may be configured to implement a standard interface, such as Serial-Attached SCSI (SAS), Fiber Channel interface, PCI Express (PCIe), SATA, USB, and the like. I/O interface406may be configured to implement only one interface. Alternatively, I/O interface406may be configured to implement multiple interfaces, which are individually selectable using a configuration parameter selected by a user or programmed at the time of assembly. I/O interface406may include one or more buffers for buffering transmissions between one or more external devices and bus402and/or the internal devices operably attached thereto.