Operating system repairs via recovery agents

- Hewlett Packard

An example computing device includes a first storage device storing a firmware. The computing device also includes a second storage device storing an operating system of the computing device. The computing device further includes a processor. The processor is to retrieve a recovery agent from another computing device via the firmware; validate the recovery agent; execute the recovery agent to retrieve recovery data; validate the recovery data; and repair the operating system using the recovery data via the recovery agent.

Skip to: Description  ·  Claims  ·  References Cited  · Patent History  ·  Patent History
Description
BACKGROUND

An operating system of a computing device may control many aspects of computing device. When the operating system is corrupted or damaged, the operations of the computing device may be severely limited or the computing device may be rendered inoperable.

BRIEF DESCRIPTION OF THE DRAWINGS

Some examples of the present application are described with respect to the following figures:

FIG. 1 illustrates a computing device to repair an operating system of the computing device via a recovery agent, according to an example;

FIG. 2 illustrates a computing device to repair an operating system of the computing device via a recovery agent, according to another example;

FIG. 3 illustrates a method of operation at a computing device to retrieve a recovery agent, according to an example;

FIG. 4 illustrates a method of operation at a computing device to prepare a recovery agent for subsequent retrieval, according to an example;

FIG. 5 illustrates a computing device including to repair an operating system of the computing device via a recovery agent, according to another example; and

FIG. 6 illustrates a computing device to repair an operating system of the computing device via a recovery agent, according to another example.

 DETAILED DESCRIPTION

When an operating system of a computing device is corrupted or damaged, the operating system may be repaired via a recovery operation. Some recovery operations depend on external bootable media (e.g., a Universal Serial Bus (USB) drive, a DVD, etc.). Some recovery operations may involve extensive manual configurations. Thus, the recovery operation may be time consuming and inconvenient for the user of the computing device.

Examples described herein provide an approach to repair an operating system via a recovery agent in a secure and automated manner. For example, a computing device may include a first storage device storing a firmware and a second storage device storing an operating system of the computing device. The computing device may also include a processor to: retrieve a recovery agent from another computing device via the firmware; validate the recovery agent; execute the recovery agent to retrieve recovery data; validate the recovery data; and repair the operating system using the recovery data.

In another example, a non-transitory computer-readable storage medium may include instructions that when executed cause a processor of a computing device to: in response to detecting a recovery trigger, perform a recovery operation at the first computing device upon a completion of a Power On Self-Test (POST) of the first computing device. The recovery operation may include: retrieve a recovery agent from a second computing device via a firmware of the computing device; validate the recovery agent; execute the recovery agent to retrieve recovery data from a third computing device: validate the recovery data; and repair the operating system using the recovery data via the recovery agent.

In another example, a non-transitory computer-readable storage medium may include instructions that when executed cause a processor of a computing device to: in response to detecting a recovery trigger during an execution of an operating system of the computing device or detecting a failed execution of the operating system, perform a recovery operation at the computing device. The recovery operation may include: retrieve a recovery agent from a first remote repository via a firmware of the computing device; validate the recovery agent; execute the recovery agent to retrieve recovery data from a second remote repository; validate the recovery data; and repair the operating system using the recovery data via the recovery agent. Thus, examples described herein may reduce difficulty and/or time associated with repairing an operating system. Examples described herein may also reduce the security risks (e.g., repairing the operating system using compromised recovery data) associated with repairing an operating system.

FIG. 1 illustrates a computing device 100 to repair an operating system 10 of computing device 100 via a recovery agent, according to an example. Computing device 100 may be, for example, a web-based server, a local area network server, a cloud-based server, a notebook computer, a desktop computer, an all-in-one system, a tablet computing device, a mobile phone, an electronic book reader, or any other electronic device suitable to execute an agent application to repair an operating system.

Computing device 100 may include a processor 102, a first storage device 104, and a second storage device 106. Processor 102 may be in communication with first storage device 104 and/or second storage device 106. Processor 102 may control operations of computing device 100. Storage devices 104 and 106 may store data. In some examples, storage devices 104 and/or 106 may be implemented using non-volatile memory, such as hard disk drives, solid state storage, flash memory, Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. In some examples, first storage device 104 may store firmware 108. Second storage device 106 may store an operating system 110.

Firmware 108 may perform hardware initialization and/or configuration of components (such as storage device 106, processor 102, etc.) of computing device 100. Firmware 108 may also perform runtime services for operation system(s) and application(s) executing at computing device 100. In some examples, firmware 108 may be implemented as a Unified Extensible Firmware Interface (UEFI). Operating system 110 may control and manage resources (hardware and software) of computing device 100. Operating system 110 may take control of computing device 100 when the boot up process of computing device 100 is completed and firmware 108 passes control to operating system 110.

During operation, firmware 108 may determine if operating system 110 is to be repaired. In some examples, firmware 108 may initiate a recovery operation in response to detecting a recovery trigger. A recovery trigger may be an event that informs firmware 108 a recovery operation is to be initiated. A recovery trigger may include:

an operating system failure, such as operating system corruption due to malware attack:

a failure to execute the operating system, such as when an operating system fails to load after a Power-On Self-Test (POST);

an external recovery instruction, such as a user initiated keypress during boot-time, a command from a system administrator, etc.;

a recovery instruction from a monitoring application, such as a software application that monitors the health of computing device 100; or

a combination thereof.

Firmware 108 may initiate a recovery operation from a secure, stable state. Thus, even though firmware 108 may have detected the recovery trigger(s) at various points in the pre-boot through runtime environment, firmware 108 may not immediately initiate the recovery operation. Instead, firmware 108 may initiate the recovery operation upon completion of a POST subsequent to the detection of a recovery trigger. For example, during the runtime environment (i.e., operating system 110 may be executing), firmware 108 detects a recovery trigger. Computing device 100 then may be rebooted. During the reboot, immediately after the completion of the POST, firmware 108 may initiate the recovery operation.

During the recovery operation, firmware 108 may retrieve (e.g., download) a recovery agent 112 from a repository 114. In some examples, repository 114 may be a second computing device (computing device 100 may be the first computing device) or a set of computing devices. In some examples, repository 114 may be implemented as a cloud storage (e.g., a public cloud or a private cloud). Recovery agent 112 may be a software application that repairs operating system 110. Recovery agent 112 may be implemented using instructions executable by processor 102. Firmware 108 may validate recovery agent 112 to ensure recovery agent 112 is not compromised. Once validated, firmware 108 may execute recovery agent 112 at computing device 100. Recovery agent 112 may retrieve recovery data 116. In some examples, recovery data 116 may be an operating system image (e.g. a file containing the complete contents and structure of an operating system, such as operating system 110). Recovery agent 112 may validate recovery data 116. When validated, recovery agent 112 may use recovery data 116. The recovery operation is described in more detail in FIG. 2.

Turning to FIG. 2, when firmware 108 is to retrieve recovery agent 112, firmware 108 may use an embedded network stack to retrieve recovery agent 112 from repository 114. Firmware 108 may first retrieve a manifest file 202 and a signature 204 of manifest file 202. Manifest file 202 may indicate components (e.g., files) that make up recovery agent 112 and a unique hash value for each of the component. Signature 204 may be any digital cryptography signature that can be used to prove or verify the integrity or authenticity of manifest file 202. Signature 204 may be generated using a signing algorithm, such as Secure Hash Algorithm (SHA-1), and manifest file 202.

When computing device 100 receives manifest file 202 and signature 204, firmware 108 may use a signature verifying algorithm to determine if signature 204 is to be accepted. If signature 204 is accepted, then manifest file 202 is validated. In response to validating manifest file 202, firmware 108 may retrieve/download the remaining components of recovery agent 112, such as components 206 and 208. Retrieving recovery agent 112 is described in more detail in FIG. 3.

When firmware 108 has retrieved recovery agent 112, firmware 108 may execute recovery agent 112. For example, firmware 108 may use a UEFI boot manager to execute recovery agent 112. Recovery agent 112 may retrieve/download recovery data 116 from a repository 210 that is similar to repository 114. Recovery agent 112 may store recovery data 116 in second storage device 106. Recovery agent 112 may validate recovery data 116. For example, recovery agent 112 may validate recovery data 116 via a digital signature. In some examples, a controller (not shown) of computing device 100 may be used to validate manifest file 202 and recovery data 116. In response to validating recovery data 116, recovery agent 112 may repair operating system 110 using recovery data 116. Repairing operating system 110 may include replacing the current copy of operating system 110 with a new copy of operating system 110 (e.g., re-imaging operating system 110 using recovery data 116), replacing portions of operating system 110 with new copies of the corresponding files, or a combination thereof.

FIG. 3 illustrates a method 300 of operation at computing device 100 to retrieve recovery agent 112, according to an example. At 302, firmware 108 may retrieve manifest file 202 and signature 204. At 304, firmware 108 may determine if manifest file 202 has been validated. In response to determining that manifest file 202 has not been validated, firmware 108 may generate an error message to be displayed (e.g., at a display connected to computing device 100) and lock computing device 100, at 306. In response to determining that manifest file 202 has been validated, firmware 108 may retrieve a component of recovery agent 112 based on manifest file 202, such as component 206, at 308. At 310, firmware 108 may calculate the hash value of the retrieved component.

At 312, firmware 108 may validate the component by comparing the calculated hash value to the corresponding hash value in manifest file 202. In response to a determination that the calculated hash value matches the corresponding hash value, firmware 108 may determine that the component has been validated. Firmware 108 may read manifest file 202 to determine if there is any more component of recovery agent 112 left to be retrieved, at 314. In response to a determination that there is more component left to be retrieved, method 300 may return to 308. In response to a determination that there is no more component left to be retrieved, firmware 108 may execute recovery agent 112, at 316. When firmware 108 determines that the calculated hash value does not match the corresponding hash value at 312, method 300 may return to 306.

FIG. 4 illustrates a method 400 of operation at a computing device to prepare a recovery agent for subsequent retrieval, according to an example. Method 400 may be described with reference to computing device 100, although it should be understood that method 400 may be implemented by any other computing device. At 402, computing device 100 may download an Operating System Pre-installation Environment (OSPE) image. An OSPE may be a software application used for deploying/installing an operating system. At 404, particular tools (e.g., software applications) and scripts may be added to the OSPE image to generate a customized copy of the OSPE. Recovery agent 112 may be implemented as the customized copy. At 406, recovery agent 112 may be digitally signed to generate signatures of the components of recovery agent 112. For example, the signatures may be hash values of components of recovery agents 112. The signatures of the components may be stored in manifest file 202.

At 408, manifest fife 202 may be created to catalog components of recovery agent 112 and store the unique hash values for each component of recovery agent 112. Also, manifest file 202 may be digitally signed to create signature 204. At 410, recovery agent 112, manifest file 202, and signature 204 may be uploaded to a repository, such as repository 114 for subsequent retrieval.

FIG. 5 illustrates a computing device 500 including to repair an operating system of the computing device via a recovery agent, according to another example. Computing device 500 may implement computing device 100 of FIGS. 1-2. Computing Device 500 may include a processor 502 and a computer-readable storage medium 504.

Processor 502 may be a central processing unit (CPU), a semiconductor-based microprocessor, and/or other hardware devices suitable for retrieval and execution of instructions stored in computer-readable storage medium 504. Computer-readable storage medium 504 may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Thus, computer-readable storage medium 504 may be, for example, Random Access Memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage device, an optical disc, etc. In some examples, computer-readable storage medium 504 may be a non-transitory storage medium, where the term “non-transitory” does not encompass transitory propagating signals. Computer-readable storage medium 504 may be encoded with instructions 506-514.

Recovery agent retrieving instructions 506 may retrieve a recovery agent in response to detecting a recovery trigger. For example, referring to FIG. 1, firmware 108 may retrieve recovery agent 112 in response to detecting a recovery trigger. Recovery agent validating instructions 508 may validate the recovery agent. For example, referring to FIG. 2, firmware 108 may validate recovery agent 112. Recovery agent execution instructions 510 may execute the recovery agent when the recovery agent is validated. For example, referring to FIG. 2, firmware 108 may execute recovery agent 112. Recovery data validating instructions 512 may validate recovery data used to repair an operating system (not shown) of computing device 500. For example, referring to FIG. 2, recovery agent 112 may validate recovery data 116. Operating system repair instructions 514 may repair the operating system via the recovery agent. For example, referring to FIG. 2, recovery agent 112 may use recovery data 116 to repair operating system 110.

FIG. 6 illustrates computing device 500 to repair an operating system of the computing device via a recovery agent, according to another example. In some examples, recovery agent retrieving instructions 506 may include manifest file and signature retrieving instructions 602 and recovery agent component retrieving instructions 604. Manifest file and signature retrieving instructions 602 may retrieve a manifest file and a signature of the manifest file so that the manifest file can be validated. For example, referring to FIG. 2, firmware 108 may retrieve manifest file 202 and signature 204 from repository 114. Recovery agent component retrieving instructions 604 may retrieve components that make up a recovery agent. For example, referring to FIG. 2, firmware 108 may retrieve components 206 and 208 of recovery agent 112.

In some examples, recovery agent validating instructions 508 may include manifest file validating instructions 606 and hash value comparison instructions 608. Manifest file validating instructions 606 may validate a manifest file. For example, referring to FIG. 2, firmware 108 may validate manifest file 202 based on signature 204. Hash value comparison instructions 608 may validate each retrieved component of a recovery agent. For example, referring to FIG. 3, at 312, firmware 108 may validate the component by comparing the calculated hash value to the corresponding hash value in manifest file 202.

The use of “comprising”, “including” or “having” are synonymous and variations thereof herein are meant to be inclusive or open-ended and do not exclude additional unrecited elements or method steps.

Claims

1. A first computing device comprising:

a first storage device storing a firmware;
a second storage device storing an operating system of the first computing device; and
a processor to: retrieve, with the firmware in the first computing device, a recovery agent over a network from a second computing device, wherein the processor is to retrieve the recovery agent by: downloading a manifest file and a signature of the manifest file, wherein the manifest file indicates components that make up the recovery agent, and the manifest file includes hash values of the components that make up the recovery agent, validating the manifest file based on the signature, and retrieving, based on the manifest file, the components that make up the recovery agent; validate the recovery agent by validating each respective component of the components by comparing a calculated hash value of the respective component with the hash value of the respective component in the manifest file; in response to the validating of the components, execute the recovery agent to retrieve recovery data; validate the recovery data; and repair, using the recovery agent, the operating system based on the recovery data.

2. The first computing device of claim 1, wherein the processor is to retrieve the recovery agent subsequent to a reboot of the first computing device.

3. The first computing device of claim 1, wherein the recovery data includes an operating system image.

4. The first computing device of claim 1, wherein the firmware is a Unified Extensible Firmware Interface (UEFI).

5. The first computing device of claim 1, wherein the processor is to retrieve the recovery agent, validate the recovery agent, execute the recovery agent, validate the recovery data, and repair the operating system as part of a recovery operation at the first computing device after a completion of a Power On Self-Test (POST) of the first computing device.

6. A non-transitory computer-readable storage medium comprising instructions that when executed cause a first computing device to:

in response to detecting a recovery trigger, perform a recovery operation at the first computing device after a completion of a Power On Self-Test (POST) of the first computing device, wherein the recovery operation includes: retrieving, with a firmware of the first computing device, a recovery agent over a network from a second computing device, wherein the retrieving of the recovery agent comprises: downloading a manifest file and a signature of the manifest file, wherein the manifest file indicates components that make up the recovery agent, and the manifest file includes hash values of the components that make up the recovery agent, validating the manifest file based on the signature, and retrieving, based on the manifest file, the components that make up the recovery agent; validating the recovery agent by validating each respective component of the components by comparing a calculated hash value of the respective component with the hash value of the respective component in the manifest file; in response to the validating of the components, executing the recovery agent to retrieve recovery data from a third computing device; validating the recovery data; and repairing, with the recovery agent, an operating system of the first computing device using the recovery data.

7. The non-transitory computer-readable storage medium of claim 6, wherein the instructions when executed further cause the first computing device to detect the recovery trigger during an execution of the operating system, wherein the execution of the operating system is prior to the POST.

8. The non-transitory computer-readable storage medium of claim 6, wherein the recovery data includes an operating system image.

9. The non-transitory computer-readable storage medium of claim 8, wherein the instructions when executed further cause the first computing device to repair the operating system by re-imaging the first computing device using the operating system image via the recovery agent.

10. The non-transitory computer-readable storage medium of claim 6, wherein the firmware is a Unified Extensible Firmware Interface (UEFI).

11. A non-transitory computer-readable storage medium comprising instructions that when executed cause a first computing device to:

in response to detecting a recovery trigger during an execution of an operating system of the first computing device, perform a recovery operation at the first computing device, wherein the recovery operation includes: retrieving, with a firmware of the first computing device, a recovery agent over a network from a first remote repository, wherein the retrieving of the recovery agent comprises: downloading a manifest file and a signature of the manifest file, wherein the manifest file indicates components that make up the recovery agent, and the manifest file includes hash values of the components that make up the recovery agent, validating the manifest file based on the signature, and retrieving, based on the manifest file, the components that make up the recovery agent; validating the recovery agent by validating each respective component of the components by comparing a calculated hash value of the respective component with the hash value of the respective component in the manifest file; in response to the validating of the components, executing the recovery agent to retrieve recovery data from a second remote repository; validating the recovery data; and repairing, with the recovery agent, the operating system using the recovery data.

12. The non-transitory computer-readable storage medium of claim 11, wherein the recovery trigger includes an operating system failure, a failure to execute the operating system, an external recovery instruction, a recovery instruction from a monitoring application, or a combination thereof.

13. The non-transitory computer-readable storage medium of claim 11, wherein the instructions that when executed cause the first computing device to perform the recovery operation at the first computing device after a completion of a Power On Self-Test (POST) of the first computing device.

Referenced Cited
U.S. Patent Documents
5732268 March 24, 1998 Bizzarri
7673301 March 2, 2010 Righi et al.
8261126 September 4, 2012 Sosnosky et al.
8707086 April 22, 2014 Poisner
8990902 March 24, 2015 McCarron et al.
20040172578 September 2, 2004 Chen et al.
20050081004 April 14, 2005 Zhang
20050204199 September 15, 2005 Harper et al.
20060015711 January 19, 2006 Bang
20060145133 July 6, 2006 Komarla
20080155331 June 26, 2008 Rothman et al.
20100098243 April 22, 2010 Chopart
20120144383 June 7, 2012 Mishra
20120159254 June 21, 2012 Su
20120272090 October 25, 2012 Poisner
20130326260 December 5, 2013 Wei
20140065958 March 6, 2014 Yao
20140136893 May 15, 2014 Xie
20140181579 June 26, 2014 Whitehead
20140330784 November 6, 2014 Sundaram
20150143172 May 21, 2015 Huang
20160014175 January 14, 2016 Somuah
20160026518 January 28, 2016 Foster
20160117227 April 28, 2016 Hetrick
20170085383 March 23, 2017 Rao
Foreign Patent Documents
I271651 January 2007 TW
Other references
  • Deployment Image Servicing and Management, May 2, 2017.
  • HP Sure Start Gen3—Technical whitepaper, Jan. 2017.
  • Image Based Backup to the Cloud Storage Specifics, https://www.cloudberrylab.com/image-based-backup-to-the-cloud-storage-specifics.aspx, Sep. 18, 2017.
  • NIST Special Publication 800-147, BIOS Protection Guidelines, Apr. 2011.
  • Operating System Deployment Security Best Practices and Privacy Information, 2007.
  • Windows Recovery Environment (Windows RE), May 2, 2017.
Patent History
Patent number: 11422901
Type: Grant
Filed: Nov 6, 2017
Date of Patent: Aug 23, 2022
Patent Publication Number: 20210286685
Assignee: Hewlett-Packard Development Company, L.P. (Spring, TX)
Inventors: Vali Ali (Houston, TX), Michael Provencher (Houston, TX), Charles Ricardo Staub (Porto Alegre), Juliano Francisco Cagnini Ciocari (Porto Alegre), Paulo Alcantara (Porto Alegre)
Primary Examiner: Sarai E Butler
Application Number: 16/478,800
Classifications
Current U.S. Class: Recovery Techniques (epo) (714/E11.122)
International Classification: G06F 11/00 (20060101); G06F 11/14 (20060101); G06F 9/4401 (20180101); G06F 11/22 (20060101);