EMBEDDED OEM CODE FOR FAULT RECOVERY

TECHNICAL FIELD

[0001] Embodiments described herein generally relate to microcontrollers and in particular, to using embedded original equipment manufacturer (OEM) code for fault recovery.

BACKGROUND

[0002] Many computing platforms include a platform controller hub, which includes multiple embedded programmable microcontrollers. Examples of such microcontrollers include a manageability engine (ME) and an innovation engine (IE) microcontroller. These microcontrollers are used to provide security, integrity checking, and other functions to the host system.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. Some embodiments are illustrated by way of example, and not limitation, in the figures of the accompanying drawings in which:

[0004] FIG. 1 is a schematic diagram illustrating a microcontroller arrangement, according to an embodiment;

[0005] FIG. 2 is a flowchart illustrating a recovery process, according to an embodiment;

[0006] FIG. 3 is a block diagram illustrating a control system for using embedded original equipment manufacturer code for fault recovery, according to an embodiment;

[0007] FIG. 4 is a flowchart illustrating a method of using embedded original equipment manufacturer code for fault recovery, according to an embodiment; and [0008] FIG. 5 is a block diagram illustrating an example machine upon which any one or more of the techniques (e.g., methodologies) discussed herein may perform, according to an example embodiment.

DETAILED DESCRIPTION

[0009] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of some example embodiments. It will be evident, however, to one skilled in the art that the present disclosure may be practiced without these specific details.

[0010] Microcontrollers load the initial piece of program code from some read-only memory (ROM). Other pieces of the code to be executed by the microcontroller are loaded from some non- volatile (NV) storage location.

Conventionally, an original equipment manufacturer (OEM) may insert code into the NV storage during manufacturing. The OEM expects such code to be executed by the microcontrollers. In some circumstances, however, NV storage may be erased or overwritten, causing unforeseeable execution of the microcontrollers that rely on the code. Such actions may compromise the integrity of the system controlled by the microcontrollers. For instance, microcontrollers may provide security features like authenticating a trusted root component. Interrupting the operation of such a microcontroller may expose the platform to malicious code, render the system inoperable, or otherwise compromise the integrity of the system.

[0011] FIG. 1 is a schematic diagram illustrating a microcontroller arrangement 100, according to an embodiment. The microcontroller arrangement 100 includes a platform controller hub (PCH) 102 and a non- volatile (NV) storage 104 that is external from the PCH 102. The NV storage 104 is a memory that is able to maintain its contents even after a power cycle. Examples of 104 include, but are not limited to erasable programmable read-only memory (EPROM), flash memory, Ferroelectric random access memory (RAM), hard disk drive (HDD), optical discs, and other types. In the context of a

microcontroller arrangement 100, the NV storage 104 is typically flash memory or EPROM.

[0012] The PCH 102 and NV storage 104 are connected with a bus 106. The bus may be a serial peripheral interface (SPI) bus. The bus 106 is used to send date between microcontrollers in the PCH 102 and other peripherals in the microcontroller arrangement 100, including the NV storage 104. Flash memory used with an SPI bus is conventionally referred to as SPI flash.

[0013] The PCH 102 may include one or more microcontrollers. In the example illustrated in FIG. 1, the PCH 102 includes a manageability engine (ME) microcontroller 108 and an innovation engine (IE) microcontroller 110. The ME microcontroller 108 is a dedicated microcontroller that provides various security and operational components to the PCH 102. For example, some aspects of the ME microcontroller 108 include, but are not limited to providing remote configuration, booting from a remote hard drive, using one-time passwords for two-factor authentication, and enabling a poison pill that may be used to disable or wipe a remote system over a 3G connection.

[0014] The IE microcontroller 110 may act in concert with the ME microcontroller 108 and provide extensibility to the ME microcontroller 108. The IE microcontroller 110 may be used to execute OEM-provided firmware that is stored outside of the PCH 102. OEMs (e.g., system builders) are able to provide their own unique, differentiating firmware for server, storage, and networking markets via the IE microcontroller 110. The IE microcontroller 110 is cryptographically bound to the OEM. Code not authenticated by the OEM will not load in the IE microcontroller 110.

[0015] As the system initializes, the ME microcontroller 108 may execute code embedded in the PCH 102 by the chip manufacturer. For instance, the ME microcontroller 108 may access a read-only memory (ROM) 112 that is built into the PCH 102, and obtain the code to execute. The ROM 112 may include low-level instructions or data, defined by the PCH 102 hardware manufacturer, and used by the PCH 102 to provide fundamental operations. However, the ROM 112 is inaccessible by OEMs.

[0016] To provide OEMs an ability to customize and control the PCH 102, the IE microcontroller 110 may load program code from the NV storage 104 to be executed. Program code may be stored by an OEM during system assembly. For example, the PCH 102 may be provided by Intel® and an OEM, such as DELL®, may program the NV storage 104 with DELL-specific basic input/output system (BIOS) code or data. When the PCH 102 is brought up, the OEM-specific code or data is loaded from the external NV storage 104 and used by the ME microcontroller 108 or IE microcontroller 110. Each OEM may provide its own programming or data and store it in the NV storage 104.

[0017] The contents of the NV storage 104 may be corrupted, altered, or erased, either intentionally (e.g., in a cyber-attack) or unintentionally (e.g., with a memory failure). The microcontrollers in the PCH 102 include authentication mechanisms to guarantee that only the code put in the NV storage 104 by an OEM is executed. For instance, the OEM may sign the contents of NV storage 104 and the ME microcontroller 108 or IE microcontroller 110 may authenticate the contents using the OEM's signature. If the ME microcontroller 108 or IE microcontroller 110 is unable to authenticate the contents, the ME

microcontroller 108 and IE microcontroller 110 will not execute some other arbitrary code. As such, when the PCH 102 attempts to bring up the system and the contents of the NV storage 104 are inaccessible or unexecutable, then the system may be vulnerable to additional attacks or may be unstable or inoperable.

[0018] In traditional systems, to recover from these types of situations, external memory (e.g., flash devices) was used to store a golden image of the OEM code and data. When a fault occurred, the PCH 102 would read the external memory and load the golden image into the NV storage 104. This would allow the microcontroller arrangement 100 to reinitialize to a known state.

However, using an external memory device is risky because of a potential man- in-the-middle (MITM) attack. An MITM attack may be conducted on the bus 106, for example.

[0019] Thus, in the embodiment illustrated in FIG. 1, a non- volatile, one-time programmable (OTP) memory structure 114 is used to store code or data to recover. When a fault occurs, the PCH 102 may access the memory structure 114 to obtain code to execute, and attempt to recover from the fault. The memory structure 114 may be a set of field programmable fuses (FPFs). Programmable read-only memory (PROM), field programmable read-only memory (FPROM), and one-time programmable non- volatile memory (OTP NVM) are types of digital read-only memory (ROM) where the setting of each bit is set by a fuse or an antifuse. In fuse-based technology, the fuse starts with a low resistance and is designed to permanently break an electrically conductive path when the current applied to the path exceeds a specified limit. Similarly, in antifuse technology, each antifuse starts with a high resistance and is designed to permanently create an electrically conductive path when voltage across the antifuse exceeds a specified limit. Each fuse or antifuse represents a digital bit, and burning specific fuses or antifuses creates digital data on the ROM. The memory structure 114 may be fuse-based or antifuse-based memory.

[0020] In a fuse-based example, an unburnt fuse is assumed to be associated with the binary value "1" because the fuse is conductive and allows a charge to pass through. When the fuse is burnt, the structure is altered to be non- conductive and then has a binary value of "0". Antifuses operate in the opposite manner. An antifuse is a structure that changes state from not conducting to conducting (e.g., from higher resistance to lower resistance) in response to electrical stress (e.g., programming voltage or current). Thus, in its initial state, an antifuse has a binary value of "0" and after being "blown" (e.g., "burnt") the antifuse is conductive and has a binary value of "1". While much of the present disclosure discusses examples in terms of a fuse-based PROM, it is understood that variants using antifuses are within the scope of this disclosure.

[0021] The memory structure 114 is protected from being erased once programmed. The embedded microcontrollers are able to access the memory structure 114 and load the code from there even if the external NV storage 104 is not available. Thus, the IE microcontroller 110 arrangement provides a guarantee that the critical code will be executed by the microcontrollers.

[0022] The code to be embedded in the memory structure 114 may be defined by the OEM as opposed to the ROM code in ROM 112 being defined by the PCH 102 hardware manufacturer. The code to be embedded in the memory structure 114 may be defined and modified according to the set of features expected to be fulfilled by the microcontroller by the OEM, while the ROM code in the ROM 112 must always be the same across all different OEM product configurations.

[0023] As a result of the microcontroller arrangement 100, OEMs are able to customize and tailor the response performed by the PCH 102 when a fault occurs. For instance, one OEM may prioritize security and decide to include a piece of code in the memory structure 114 that will halt the main host processor and toggle a PCH pin in order to trigger an alarm. Another OEM may decide instead to prioritize reliability and let the system to continue booting even if there is no code loaded from the NV storage 104. The microcontroller arrangement 100 provides OEMs full flexibility to store code, configuration parameters, and other information in the memory structure 114 according to their preferred platform design.

[0024] The memory structure 114 may also store other information, such as core microcode for the IE microcontroller 110, for instance when firmware updates are available, core CPU microcode, or a BIOS initial boot block. In situations where the PCH 102 hardware vendor generates microcode patches, but the OEM ecosystem integrates them into the BIOS image. If the end user does not patch the BIOS, then the microcode patches may not be applied to the PCH 102. By storing the patches in the memory structure 114, the PCH 102 is more likely to be timely updated.

[0025] Fuse-based memory devices are expensive hardware resources. For this reason, ROM code in the ROM 112 may implement a library of procedures that may be later used by the code embedded in the memory structure 114 by the OEM. As such, the OEM may only need to store library calls in the memory structure 114, thereby reducing the amount of fuses needed. It is understood that a mixture of library calls and self-contained executable code may be stored in the memory structure 114 by the OEM.

[0026] FIG. 2 is a flowchart illustrating a recovery process 200, according to an embodiment. System power is applied (operation state 202). The ME microcontroller 108 or IE microcontroller 110 determine whether an attack is in progress (decision block 204). The ME microcontroller 108 or IE

microcontroller 110 may make this determination in a number of ways. A non- limiting example is by use of an OEM signature. The OEM may sign the BIOS image or other core files. Upon startup, the ME microcontroller 108 or IE microcontroller 110 may verify that the BIOS image, for example, is authentic before allowing the BIOS to execute.

[0027] If there is no detected attack at decision block 204, then the initialization continues normally (operational block 206). Normal initiation may include obtaining a copy of the BIOS from the NV storage 104 and using it to complete the boot process. The BIOS may be stored in a local memory to the PCH 102, such as a static random access module (SRAM) device incorporated in the PCH 102. As a result, the operating system is booted (operational state 208). [0028] If there is an attack detected at decision block 204, then the ME microcontroller 108 and IE microcontroller 110 causes code from the memory structure 114 to be executed (operational block 210). For example, the ME microcontroller 108 or IE microcontroller 110 may direct a reset vector to the code's location in the memory structure 114. The reset vector is the default location a CPU will go to find the first instruction it will execute after a reset. The reset vector is a pointer or address where the CPU begins execution. The code in the memory structure 114 may cause the CPU to send an alert to a system administrator using one or more of available communication channels or protocols, such as HTTP, JSON, etc. The CPU may initiate alerts to an administrator upon attack via any outward facing communication path, e.g., HTTP, IPMI alerts, SMBus, Omni-Path fabric, etc.

[0029] Although discussed here that either the ME microcontroller 108 or the IE microcontroller 110 may cause code from the memory structure 114 to be executed, in some embodiments, it may be only the ME microcontroller 108 or the IE microcontroller 110 that performs this activity.

[0030] At operational block 212, the recovery code in the memory structure 114 may access a storage location to obtain a clean BIOS image. The storage location may be a NAND flash storage, a 3D XPoint™ non- volatile memory, an NVMe device accessible via an IE PCIe interface, or other memory. The storage location may be internal to the PCH 102 or external, such as in NV storage 104.

[0031] At operational block 214, the clean BIOS image is downloaded into the local memory in the PCH 102. The local memory may be a SRAM device incorporated into the PCH 102 architecture. The BIOS image may be downloaded using memory mapped input/output (MMIO). After the BIOS is verified in the local memory of the PCH 102, the reset vector will be allowed to be consumed (operational block 216). The operating system brought up using the clean BIOS image (operational state 208).

[0032] It is understood that in some embodiments, the ME microcontroller 108 and IE microcontroller 110 work in tandem. The ME microcontroller 108 may have access to interfaces for external ports, memory structures, or communication circuits, that the IE microcontroller 110 may not have access to depending on the design of the PCH 102. As such, the ME microcontroller 108 and IE microcontroller 110 may pass control data between one another in order to perform the functions described herein.

[0033] FIG. 3 is a block diagram illustrating a control system 300 for using embedded original equipment manufacturer code for fault recovery, according to an embodiment. The control system 300 includes a microcontroller 302, a fuse- based memory device 304, and an interface to an external memory storage 306. The interface 306 may be a SPI interface. The external memory storage may be a NAND flash, EPROM, or other NV storage device.

[0034] The microcontroller 302 may include a manageability engine microcontroller, an innovation engine microcontroller, or be otherwise configured or programmed to provide similar or additional functions as an ME or IE microcontroller, either alone or combined.

[0035] The fuse-based memory device 304 may use fuses or antifuses, depending on the design. The fuses (or antifuses) may be blown (e.g., programmed) by an OEM or system builder during manufacturing or assembly.

[0036] In operation, the microcontroller 302 used to verify the BIOS and initiate the boot operation. The microcontroller 302 may be configured or otherwise programmed to access a BIOS over an SPI interface to external memory storage, and detect when the BIOS is not authentic. For instance, the BIOS may be signed by the OEM and the microcontroller 302 may check a signature of the OEM. If the microcontroller 302 determines that the BIOS is invalid, then the microcontroller 302 may initiate a recovery operation.

[0037] Alternatively, the microcontroller 302 may be unable to access the BIOS from its regular location. For example, the BIOS may be corrupted or erased due to malicious intervention or some hardware failure. The

microcontroller 302 may attempt to recover from either type of situation by obtaining a clean BIOS image from an alternative storage location, and loading the clean BIOS image into local storage to complete the boot sequence. Alerts, logs, or other notifications may be generated to inform a user, system

administrator, or the like. Further remediation may be used to bring the system back to its intended state.

[0038] Alternatively, the microcontroller 302 may determine that the host system (e.g., user computing device) has been stolen, lost, or compromised. In order to maintain the user's privacy, the host system may be disabled, wiped, or transmit a "phone home" beacon. Code to control such activities may be stored in the fuse-based memory device 304.

[0039] As such, in an embodiment, a system for using embedded original equipment manufacturer code for fault recovery, includes a microcontroller 302 and a fuse-based memory device 304. The microcontroller 302 may be configured to detect that a fault has occurred and load executable code from the fuse-based memory device when the fault has been detected.

[0040] In an embodiment, the microcontroller 302 comprises a manageability engine microcontroller. In a related embodiment, the microcontroller 302 comprises an innovation engine microcontroller.

[0041] In an embodiment, the fuse-based memory device 304 is an antifuse device. In a related embodiment, the fuse-based memory device 304 is programmed only by an original equipment manufacturer (OEM). In an embodiment, the system comprises a platform controller hub.

[0042] In an embodiment, to detect that the fault has occurred, the microcontroller 302 is to attempt to access a basic input/output system (BIOS) image from a default storage location that is external from the system, and detect that the fault has occurred when the BIOS image is inaccessible or invalid. In a further embodiment, the BIOS image is signed with a signature, and the microcontroller 302 is to determine that the BIOS image is invalid by analyzing the signature.

[0043] In an embodiment, the executable code accesses a clean BIOS image and loads the clean BIOS image into local memory to recover from the fault. In another embodiment, the executable code transmits an alert to a system administrator.

[0044] In a different embodiment, to detect that the fault has occurred, the microcontroller 302 is to obtain information that the system has been stolen and detect that the fault has occurred based on the information. In a further embodiment, the executable code disables the system. In a related embodiment, the executable code transmits an alert to a user of the system. In a related embodiment, the executable code transmits an alert to a system administrator.

[0045] In an embodiment, to load the executable code, the microcontroller 302 is to direct a reset vector to a location in the fuse-based memory device 304, the location indicating the executable code. [0046] In an embodiment, to load the executable code, the microcontroller 302 is to read executable instructions from the fuse-based memory device 304 into operational memory.

[0047] In an embodiment, the microcontroller 302 has access to an outward facing communication path, and the microcontroller 302 uses the outward facing communication path to transmit information to an external destination. In a related embodiment, the outward facing communication path is to a cellular radio. In another related embodiment, the outward facing communication path is to a network interface card.

[0048] The microcontroller 302, fuse-based memory device 304, and interface 306 are understood to encompass tangible entities that are physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operations described herein. Such tangible entitles may be constructed using one or more circuits, such as with dedicated hardware (e.g., field programmable gate arrays (FPGAs), logic gates, system on chip, etc.). As such, the tangible entities described herein may be referred to as circuits, circuitry, processor units, subsystems, or the like.

[0049] FIG. 4 is a flowchart illustrating a method 400 of using embedded original equipment manufacturer code for fault recovery, according to an embodiment. At block 402, a microcontroller determines that a fault has occurred.

[0050] At block 404, executable code is loaded from the fuse-based memory device when the fault has been detected.

[0051] In an embodiment, the microcontroller comprises a manageability engine microcontroller. In a related embodiment, the microcontroller comprises an innovation engine microcontroller. In an embodiment, the microcontroller is incorporated in a platform controller hub.

[0052] In an embodiment, the fuse-based device is an antifuse device. In a related embodiment, the fuse-based device is programmed only by an original equipment manufacturer (OEM).

[0053] In an embodiment, detecting that the fault has occurred comprises attempting to access a basic input/output system (BIOS) image from a default storage location that is external from the system and detecting that the fault has occurred when the BIOS image is inaccessible or invalid. In a further embodiment, the BIOS image is signed with a signature, and detecting that the fault occurred when the BIOS image is invalid comprises determining that the BIOS image is invalid by analyzing the signature.

[0054] In an embodiment, the executable code accesses a clean BIOS image and loads the clean BIOS image into local memory to recover from the fault. In a related embodiment, the executable code transmits an alert to a system administrator.

[0055] In an embodiment, detecting that the fault has occurred comprises obtaining information that the system has been stolen and detecting that the fault has occurred based on the information. In a further embodiment, the executable code disables the system. In a related embodiment, the executable code transmits an alert to a user of the system. In a related embodiment, the executable code transmits an alert to a system administrator.

[0056] In an embodiment, loading the executable code comprises directing a reset vector to a location in the fuse-based memory device, the location indicating the executable code.

[0057] In an embodiment, loading the executable code comprises reading executable instructions from the fuse-based memory device into operational memory.

[0058] In an embodiment, the microcontroller has access to an outward facing communication path, and the method 400 comprises using the outward facing communication path to transmit information to an external destination. In a further embodiment, the outward facing communication path is to a cellular radio. In a related embodiment, the outward facing communication path is to a network interface card.

[0059] Embodiments may be implemented in one or a combination of hardware, firmware, and software. Embodiments may also be implemented as instructions stored on a machine-readable storage device, which may be read and executed by at least one processor to perform the operations described herein. A machine-readable storage device may include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a machine-readable storage device may include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and other storage devices and media.

[0060] A processor subsystem may be used to execute the instruction on the machine-readable medium. The processor subsystem may include one or more processors, each with one or more cores. Additionally, the processor subsystem may be disposed on one or more physical devices. The processor subsystem may include one or more specialized processors, such as a graphics processing unit (GPU), a digital signal processor (DSP), a field programmable gate array (FPGA), or a fixed function processor.

[0061] Examples, as described herein, may include, or may operate on, logic or a number of components, modules, or mechanisms. Modules may be hardware, software, or firmware communicatively coupled to one or more processors in order to carry out the operations described herein. Modules may be hardware modules, and as such modules may be considered tangible entities capable of performing specified operations and may be configured or arranged in a certain manner. In an example, circuits may be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. In an example, the whole or part of one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware processors may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software may reside on a machine- readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations. Accordingly, the term hardware module is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein. Considering examples in which modules are temporarily configured, each of the modules need not be instantiated at any one moment in time. For example, where the modules comprise a general-purpose hardware processor configured using software; the general-purpose hardware processor may be configured as respective different modules at different times. Software may accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time. Modules may also be software or firmware modules, which operate to perform the methodologies described herein.

[0062] Circuitry or circuits, as used in this document, may comprise, for example, singly or in any combination, hardwired circuitry, programmable circuitry such as computer processors comprising one or more individual instruction processing cores, state machine circuitry, and/or firmware that stores instructions executed by programmable circuitry. The circuits, circuitry, or modules may, collectively or individually, be embodied as circuitry that forms part of a larger system, for example, an integrated circuit (IC), system on-chip (SoC), desktop computers, laptop computers, tablet computers, servers, smart phones, etc.

[0063] FIG. 5 is a block diagram illustrating a machine in the example form of a computer system 500, within which a set or sequence of instructions may be executed to cause the machine to perform any one of the methodologies discussed herein, according to an example embodiment. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of either a server or a client machine in server-client network environments, or it may act as a peer machine in peer-to-peer (or distributed) network environments. The machine may be a wearable device, personal computer (PC), a tablet PC, a hybrid tablet, a personal digital assistant (PDA), a mobile telephone, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine.

Further, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. Similarly, the term "processor-based system" shall be taken to include any set of one or more machines that are controlled by or operated by a processor (e.g., a computer) to individually or jointly execute instructions to perform any one or more of the methodologies discussed herein.

[0064] Example computer system 500 includes at least one processor 502 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both, processor cores, compute nodes, etc.), a main memory 504 and a static memory 506, which communicate with each other via a link 508 (e.g., bus). The computer system 500 may further include a video display unit 510, an alphanumeric input device 512 (e.g., a keyboard), and a user interface (UI) navigation device 514 (e.g., a mouse). In one embodiment, the video display unit 510, input device 512 and UI navigation device 514 are incorporated into a touch screen display. The computer system 500 may additionally include a storage device 516 (e.g., a drive unit), a signal generation device 518 (e.g., a speaker), a network interface device 520, and one or more sensors (not shown), such as a global positioning system (GPS) sensor, compass, accelerometer, gyrometer, magnetometer, or other sensor.

[0065] The storage device 516 includes a machine-readable medium 522 on which is stored one or more sets of data structures and instructions 524 (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. The instructions 524 may also reside, completely or at least partially, within the main memory 504, static memory 506, and/or within the processor 502 during execution thereof by the computer system 500, with the main memory 504, static memory 506, and the processor 502 also constituting machine-readable media.

[0066] While the machine-readable medium 522 is illustrated in an example embodiment to be a single medium, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions 524. The term "machine-readable medium" shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions. The term "machine-readable medium" shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media include nonvolatile memory, including but not limited to, by way of example,

semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD- ROM disks.

[0067] The instructions 524 may further be transmitted or received over a communications network 526 using a transmission medium via the network interface device 520 utilizing any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, mobile telephone networks, plain old telephone (POTS) networks, and wireless data networks (e.g., Bluetooth, Wi-Fi, 3G, and 4G LTE/LTE-A or WiMAX networks). The term "transmission medium" shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.

Additional Notes & Examples:

[0068] Example 1 is a system for using embedded original equipment manufacturer code for fault recovery, the system comprising: a microcontroller; and a fuse-based memory device; wherein the microcontroller is to: detect that a fault has occurred; and load executable code from the fuse-based memory device when the fault has been detected.

[0069] In Example 2, the subject matter of Example 1 optionally includes wherein the microcontroller comprises a manageability engine microcontroller.

[0070] In Example 3 , the subject matter of any one or more of Examples 1-2 optionally include wherein the microcontroller comprises an innovation engine microcontroller.

[0071] In Example 4, the subject matter of any one or more of Examples 1-3 optionally include wherein the fuse-based device is an antifuse device.

[0072] In Example 5 , the subject matter of any one or more of Examples 1-4 optionally include wherein the fuse-based device is programmed only by an original equipment manufacturer (OEM).

[0073] In Example 6, the subject matter of any one or more of Examples 1-5 optionally include wherein the system comprises a platform controller hub. [0074] In Example 7, the subject matter of any one or more of Examples 1-6 optionally include wherein to detect that the fault has occurred, the

microcontroller is to: attempt to access a basic input/output system (BIOS) image from a default storage location that is external from the system; and detect that the fault has occurred when the BIOS image is inaccessible or invalid.

[0075] In Example 8, the subject matter of Example 7 optionally includes wherein the BIOS image is signed with a signature, and wherein the

microcontroller is to determine that the BIOS image is invalid by analyzing the signature.

[0076] In Example 9, the subject matter of any one or more of Examples 7-8 optionally include wherein the executable code accesses a clean BIOS image and loads the clean BIOS image into local memory to recover from the fault.

[0077] In Example 10, the subject matter of any one or more of Examples 7-9 optionally include wherein the executable code transmits an alert to a system administrator.

[0078] In Example 11, the subject matter of any one or more of Examples 1- 10 optionally include wherein to detect that the fault has occurred, the microcontroller is to: obtain information that the system has been stolen; and detect that the fault has occurred based on the information.

[0079] In Example 12, the subject matter of Example 11 optionally includes wherein the executable code disables the system.

[0080] In Example 13, the subject matter of any one or more of Examples 11-

12 optionally include wherein the executable code transmits an alert to a user of the system.

[0081] In Example 14, the subject matter of any one or more of Examples 11-

13 optionally include wherein the executable code transmits an alert to a system administrator.

[0082] In Example 15, the subject matter of any one or more of Examples 1-

14 optionally include wherein to load the executable code, the microcontroller is to direct a reset vector to a location in the fuse-based memory device, the location indicating the executable code.

[0083] In Example 16, the subject matter of any one or more of Examples 1-

15 optionally include wherein to load the executable code, the microcontroller is to read executable instructions from the fuse-based memory device into operational memory.

[0084] In Example 17, the subject matter of any one or more of Examples 1- 16 optionally include wherein the microcontroller has access to an outward facing communication path, and the microcontroller uses the outward facing communication path to transmit information to an external destination.

[0085] In Example 18, the subject matter of Example 17 optionally includes wherein the outward facing communication path is to a cellular radio.

[0086] In Example 19, the subject matter of any one or more of Examples 17- 18 optionally include wherein the outward facing communication path is to a network interface card.

[0087] Example 20 is a method of using embedded original equipment manufacturer code for fault recovery, the method comprising: detecting, at a microcontroller, that a fault has occurred; and loading executable code from the fuse-based memory device when the fault has been detected.

[0088] In Example 21, the subject matter of Example 20 optionally includes wherein the microcontroller comprises a manageability engine microcontroller.

[0089] In Example 22, the subject matter of any one or more of Examples 20-

21 optionally include wherein the microcontroller comprises an innovation engine microcontroller.

[0090] In Example 23, the subject matter of any one or more of Examples 20-

22 optionally include wherein the fuse-based device is an antifuse device.

[0091] In Example 24, the subject matter of any one or more of Examples 20-

23 optionally include wherein the fuse-based device is programmed only by an original equipment manufacturer (OEM).

[0092] In Example 25, the subject matter of any one or more of Examples 20-

24 optionally include wherein the microcontroller is incorporated in a platform controller hub.

[0093] In Example 26, the subject matter of any one or more of Examples 20- 25 optionally include wherein detecting that the fault has occurred comprises: attempting to access a basic input/output system (BIOS) image from a default storage location that is external from the system; and detecting that the fault has occurred when the BIOS image is inaccessible or invalid. [0094] In Example 27, the subject matter of Example 26 optionally includes wherein the BIOS image is signed with a signature, and wherein detecting that the fault occurred when the BIOS image is invalid comprises determining that the BIOS image is invalid by analyzing the signature.

[0095] In Example 28, the subject matter of any one or more of Examples 26-

27 optionally include wherein the executable code accesses a clean BIOS image and loads the clean BIOS image into local memory to recover from the fault.

[0096] In Example 29, the subject matter of any one or more of Examples 26-

28 optionally include wherein the executable code transmits an alert to a system administrator.

[0097] In Example 30, the subject matter of any one or more of Examples 20-

29 optionally include wherein detecting that the fault has occurred comprises: obtaining information that the system has been stolen; and detecting that the fault has occurred based on the information.

[0098] In Example 31 , the subject matter of Example 30 optionally includes wherein the executable code disables the system.

[0099] In Example 32, the subject matter of any one or more of Examples 30-

31 optionally include wherein the executable code transmits an alert to a user of the system.

[00100] In Example 33, the subject matter of any one or more of Examples 30-

32 optionally include wherein the executable code transmits an alert to a system administrator.

[00101] In Example 34, the subject matter of any one or more of Examples 20-

33 optionally include wherein loading the executable code comprises directing a reset vector to a location in the fuse-based memory device, the location indicating the executable code.

[00102] In Example 35, the subject matter of any one or more of Examples 20-

34 optionally include wherein loading the executable code comprises reading executable instructions from the fuse-based memory device into operational memory.

[00103] In Example 36, the subject matter of any one or more of Examples 20-

35 optionally include wherein the microcontroller has access to an outward facing communication path, and the method comprises using the outward facing communication path to transmit information to an external destination. [00104] In Example 37, the subject matter of Example 36 optionally includes wherein the outward facing communication path is to a cellular radio.

[00105] In Example 38, the subject matter of any one or more of Examples 36- 37 optionally include wherein the outward facing communication path is to a network interface card.

[00106] Example 39 is at least one machine-readable medium including instructions, which when executed by a machine, cause the machine to perform operations of any of the methods of Examples 20-38.

[00107] Example 40 is an apparatus comprising means for performing any of the methods of Examples 20-38.

[00108] Example 41 is an apparatus for using embedded original equipment manufacturer code for fault recovery, the apparatus comprising: means for detecting, at a microcontroller, that a fault has occurred; and means for loading executable code from the fuse-based memory device when the fault has been detected.

[00109] In Example 42, the subject matter of Example 41 optionally includes wherein the microcontroller comprises a manageability engine microcontroller.

[00110] In Example 43, the subject matter of any one or more of Examples 41-

42 optionally include wherein the microcontroller comprises an innovation engine microcontroller.

[00111] In Example 44, the subject matter of any one or more of Examples 41-

43 optionally include wherein the fuse-based device is an antifuse device.

[00112] In Example 45, the subject matter of any one or more of Examples 41-

44 optionally include wherein the fuse-based device is programmed only by an original equipment manufacturer (OEM).

[00113] In Example 46, the subject matter of any one or more of Examples 41-

45 optionally include wherein the microcontroller is incorporated in a platform controller hub.

[00114] In Example 47, the subject matter of any one or more of Examples 41- 46 optionally include wherein the means for detecting that the fault has occurred comprise: means for attempting to access a basic input/output system (BIOS) image from a default storage location that is external from the system; and means for detecting that the fault has occurred when the BIOS image is inaccessible or invalid. [00115] In Example 48, the subject matter of Example 47 optionally includes wherein the BIOS image is signed with a signature, and wherein the means for detecting that the fault occurred when the BIOS image is invalid comprise means for determining that the BIOS image is invalid by analyzing the signature.

[00116] In Example 49, the subject matter of any one or more of Examples 47-

48 optionally include wherein the executable code accesses a clean BIOS image and loads the clean BIOS image into local memory to recover from the fault.

[00117] In Example 50, the subject matter of any one or more of Examples 47-

49 optionally include wherein the executable code transmits an alert to a system administrator.

[00118] In Example 51, the subject matter of any one or more of Examples 41-

50 optionally include wherein the means for detecting that the fault has occurred comprise: means for obtaining information that the system has been stolen; and means for detecting that the fault has occurred based on the information.

[00119] In Example 52, the subject matter of Example 51 optionally includes wherein the executable code disables the system.

[00120] In Example 53, the subject matter of any one or more of Examples 51-

52 optionally include wherein the executable code transmits an alert to a user of the system.

[00121] In Example 54, the subject matter of any one or more of Examples 51-

53 optionally include wherein the executable code transmits an alert to a system administrator.

[00122] In Example 55, the subject matter of any one or more of Examples 41-

54 optionally include wherein the means for loading the executable code comprise means for directing a reset vector to a location in the fuse-based memory device, the location indicating the executable code.

[00123] In Example 56, the subject matter of any one or more of Examples 41-

55 optionally include wherein the means for loading the executable code comprise means for reading executable instructions from the fuse-based memory device into operational memory.

[00124] In Example 57, the subject matter of any one or more of Examples 41-

56 optionally include wherein the microcontroller has access to an outward facing communication path, and the apparatus comprises means for using the outward facing communication path to transmit information to an external destination.

[00125] In Example 58, the subject matter of Example 57 optionally includes wherein the outward facing communication path is to a cellular radio.

[00126] In Example 59, the subject matter of any one or more of Examples 57- 58 optionally include wherein the outward facing communication path is to a network interface card.

[00127] Example 60 is at least one machine-readable medium including instructions for using embedded original equipment manufacturer code for fault recovery, which when executed by a machine, cause the machine to: detect, at a microcontroller, that a fault has occurred; and load executable code from a fuse- based memory device when the fault has been detected.

[00128] In Example 61, the subject matter of Example 60 optionally includes wherein the microcontroller comprises a manageability engine microcontroller.

[00129] In Example 62, the subject matter of any one or more of Examples 60-

61 optionally include wherein the microcontroller comprises an innovation engine microcontroller.

[00130] In Example 63, the subject matter of any one or more of Examples 60-

62 optionally include wherein the fuse-based device is an antifuse device.

[00131] In Example 64, the subject matter of any one or more of Examples 60-

63 optionally include wherein the fuse-based device is programmed only by an original equipment manufacturer (OEM).

[00132] In Example 65, the subject matter of any one or more of Examples 60-

64 optionally include wherein the machine comprises a platform controller hub.

[00133] In Example 66, the subject matter of any one or more of Examples 60-

65 optionally include wherein to detect that the fault has occurred, the microcontroller is to: attempt to access a basic input/output system (BIOS) image from a default storage location that is external from the machine; and detect that the fault has occurred when the BIOS image is inaccessible or invalid.

[00134] In Example 67, the subject matter of Example 66 optionally includes wherein the BIOS image is signed with a signature, and wherein the

microcontroller is to determine that the BIOS image is invalid by analyzing the signature. [00135] In Example 68, the subject matter of any one or more of Examples 66- 67 optionally include wherein the executable code accesses a clean BIOS image and loads the clean BIOS image into local memory to recover from the fault.

[00136] In Example 69, the subject matter of any one or more of Examples 66- 68 optionally include wherein the executable code transmits an alert to a system administrator.

[00137] In Example 70, the subject matter of any one or more of Examples 60- 69 optionally include wherein to detect that the fault has occurred, the microcontroller is to: obtain information that the machine has been stolen; and detect that the fault has occurred based on the information.

[00138] In Example 71 , the subject matter of Example 70 optionally includes wherein the executable code disables the machine.

[00139] In Example 72, the subject matter of any one or more of Examples 70-

71 optionally include wherein the executable code transmits an alert to a user of the machine.

[00140] In Example 73, the subject matter of any one or more of Examples 70-

72 optionally include wherein the executable code transmits an alert to a system administrator.

[00141] In Example 74, the subject matter of any one or more of Examples 60- 73 optionally include wherein to load the executable code, the microcontroller is to direct a reset vector to a location in the fuse-based memory device, the location indicating the executable code.

[00142] In Example 75, the subject matter of any one or more of Examples 60-

74 optionally include wherein to load the executable code, the microcontroller is to read executable instructions from the fuse-based memory device into operational memory.

[00143] In Example 76, the subject matter of any one or more of Examples 60-

75 optionally include wherein the microcontroller has access to an outward facing communication path, and the microcontroller uses the outward facing communication path to transmit information to an external destination.

[00144] In Example 77, the subject matter of Example 76 optionally includes wherein the outward facing communication path is to a cellular radio. [00145] In Example 78, the subject matter of any one or more of Examples 76- 77 optionally include wherein the outward facing communication path is to a network interface card.

[00146] The above detailed description includes references to the

accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, specific embodiments that may be practiced. These embodiments are also referred to herein as "examples." Such examples may include elements in addition to those shown or described.

However, also contemplated are examples that include the elements shown or described. Moreover, also contemplated are examples using any combination or permutation of those elements shown or described (or one or more aspects thereof), either with respect to a particular example (or one or more aspects thereof), or with respect to other examples (or one or more aspects thereof) shown or described herein.

[00147] Publications, patents, and patent documents referred to in this document are incorporated by reference herein in their entirety, as though individually incorporated by reference. In the event of inconsistent usages between this document and those documents so incorporated by reference, the usage in the incorporated reference(s) are supplementary to that of this document; for irreconcilable inconsistencies, the usage in this document controls.

[00148] In this document, the terms "a" or "an" are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of "at least one" or "one or more." In this document, the term "or" is used to refer to a nonexclusive or, such that "A or B" includes "A but not B," "B but not A," and "A and B," unless otherwise indicated. In the appended claims, the terms "including" and "in which" are used as the plain-English equivalents of the respective terms "comprising" and "wherein." Also, in the following claims, the terms "including" and "comprising" are open-ended, that is, a system, device, article, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms "first," "second," and "third," etc. are used merely as labels, and are not intended to suggest a numerical order for their objects. [00149] The above description is intended to be illustrative, and not restrictive. For example, the above-described examples (or one or more aspects thereof) may be used in combination with others. Other embodiments may be used, such as by one of ordinary skill in the art upon reviewing the above description. The Abstract is to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above Detailed Description, various features may be grouped together to streamline the disclosure. However, the claims may not set forth every feature disclosed herein as embodiments may feature a subset of said features. Further, embodiments may include fewer features than those disclosed in a particular example. Thus, the following claims are hereby incorporated into the Detailed Description, with a claim standing on its own as a separate embodiment. The scope of the embodiments disclosed herein is to be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.