WO2022173439A1 - Status information of auxiliary devices - Google Patents
Status information of auxiliary devices Download PDFInfo
- Publication number
- WO2022173439A1 WO2022173439A1 PCT/US2021/017785 US2021017785W WO2022173439A1 WO 2022173439 A1 WO2022173439 A1 WO 2022173439A1 US 2021017785 W US2021017785 W US 2021017785W WO 2022173439 A1 WO2022173439 A1 WO 2022173439A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- auxiliary
- controller
- firmware
- computing device
- bios
- Prior art date
Links
- 238000011084 recovery Methods 0.000 claims description 29
- 230000004044 response Effects 0.000 claims description 15
- 238000004891 communication Methods 0.000 claims description 12
- 238000012545 processing Methods 0.000 description 10
- 238000000034 method Methods 0.000 description 4
- 230000008569 process Effects 0.000 description 3
- 238000010586 diagram Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
- G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
- G06F11/1004—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's to protect a block of data words, e.g. CRC or checksum
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4403—Processor initialisation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0751—Error or fault detection not based on redundancy
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1417—Boot up procedures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/83—Indexing scheme relating to error detection, to error correction, and to monitoring the solution involving signatures
Definitions
- a computing device can include a processor and auxiliary devices. Such auxiliary devices can be utilized in combination with the processor to allow the computing device to perform computing device operations.
- a computing device can allow a user to utilize such computing device operations for work, education, gaming, multimedia, and/or other general use.
- Figure 1 illustrates an example of a computing device including a controller and an auxiliary device consistent with the disclosure.
- Figure 2 illustrates an example of a computing device including a controller, a memory including an auxiliary access register, and an auxiliary device consistent with the disclosure.
- Figure 3 illustrates an example of a computing device including a controller, a memory including an auxiliary access register, an auxiliary device, and a pin consistent with the disclosure.
- Figure 4 illustrates a block diagram of an example system to obtain status information of auxiliary devices consistent with the disclosure.
- Figure 5 illustrates an example flow chart for a controller for status information of auxiliary devices consistent with the disclosure.
- Figure 6 illustrates an example flow chart for a basic input/output system (BIOS) for status information of auxiliary devices consistent with the disclosure.
- BIOS basic input/output system
- a user may utilize a computing device for various purposes, such as for business and/or recreational use.
- the term “computing device” refers to an electronic system having a processing resource, memory resource, and/or an application-specific integrated circuit (ASIC) that can process information.
- a computing device can be, for example, a laptop computer, a notebook, a tablet, and/or a mobile device, among other types of computing devices.
- a computing device can utilize a processor as well as auxiliary devices to perform computing device operations.
- auxiliary device refers to an ancillary device to a main central processing unit (CPU) of a computing device, where the ancillary device includes firmware storing instructions that when executed cause the ancillary device to perform computing device operations.
- the auxiliary device can be, for example, a controller, a microcontroller, a microprocessor, etc.
- the processor and the auxiliary device can each execute respective instructions in order to facilitate the computing device to perform computing device operations.
- An auxiliary device may execute instructions to facilitate performance of computing device operations that are stored in firmware.
- firmware refers to a set of instructions included in memory that provide for low-level control of a hardware device.
- an auxiliary device can execute instructions stored in the firmware of the auxiliary device (e.g., via a microprocessor, controller, etc. of the auxiliary device) that can instruct the auxiliary device to perform computing device operations and/or perform computing device operations in combination with other auxiliary devices and/or the processor of the computing device.
- the firmware of an auxiliary device can be utilized to facilitate performance of computing device operations, the auxiliary device may not have sufficient processing capability to detect a firmware failure of its own firmware.
- a microprocessor of an auxiliary device may not be sufficiently capable of detecting a failure of the firmware of the auxiliary device.
- the auxiliary device may no longer be able to perform computing device operations which may affect other auxiliary devices and/or the processor of the computing device.
- a firmware failure of one auxiliary device may cause other errors in computing device operations with respect to remaining auxiliary devices and/or the processor of the computing device. This can lead to a negative user experience for a user of the computing device.
- the computing device can utilize a controller to communicate with such an auxiliary device to retrieve status information from the auxiliary device.
- a basic input/output system (BIOS) of the computing device can determine a status of the auxiliary device utilizing the computing capabilities of the processor and BIOS of the computing device.
- the BIOS can cause the auxiliary device to perform a firmware recovery.
- Such an approach can allow for detection of firmware errors while maintaining security between the auxiliary device and the BiOS.
- Figure 1 illustrates an example of a computing device 100 including a controller 108 and an auxiliary device 110 consistent with the disclosure.
- the computing device 100 can include a memory 102, a BiOS 106, a controller 108, and an auxiliary device 110.
- the memory 102 can include an auxiliary access register 104.
- the computing device 100 can include a memory 102 having an auxiliary access register 104,
- auxiliary access register refers to a data holding element to store instructions, addresses, and/or other data directly accessible by a processor.
- the auxiliary access register 104 can store data related to the auxiliary device 110 and can be accessible by the BIOS 108 to determine a status of the auxiliary device 110, as is further described herein.
- auxiliary device 110 can be an ancillary device of the computing device 100 to perform and/or assist in performing computing device operations.
- the auxiliary device 110 can be, for example, a controller, a microcontroller, a microprocessor, etc.
- the auxiliary device 110 can be connected to the controller 108 via an electrical connection. Such an electrical connection can allow the controller 108 to communicate with (e.g., transmit information to and/or receive information from) the auxiliary device 110, as is further described in connection with Figure 2.
- the computing device 100 can include a BIOS 106.
- BIOS refers to hardware or hardware and instructions to initialize, control, or operate a computing device prior to execution of an operating system (OS) of the computing device
- instructions included within the BIOS 106 may be software, firmware, microcode, or other programming that defines or controls functionality or operation of a BIOS 106.
- the BIOS 106 may be implemented using instructions, such as platform firmware of a computing device, executable by a processor.
- the BIOS 106 may operate or execute prior to the execution of the OS of the computing device 100.
- the BIOS 106 may initialize, control, or operate components such as hardware components of the computing device 100 and may load or boot the OS of computing device 100.
- the BIOS 106 may provide or establish an interface between hardware devices or platform firmware of the computing device 100 and an OS of the computing device 100, via which the OS of the computing device 100 may control or operate hardware devices or platform firmware of the computing device 100.
- the BIOS 106 may implement the Unified Extensible Firmware Interface (UEFi) specification or another specification or standard for initializing, controlling, or operating a computing device 100.
- UEFi Unified Extensible Firmware Interface
- the BIOS 106 can access the auxiliary access register 104 to determine a status of the auxiliary device 110.
- the BIOS 106 can access status information included in the auxiliary access register 104 to determine the status of the auxiliary device 110, as is further described in connection with Figure 2.
- the memory 102 can be a secured shared memory.
- the term “secured shared memory” refers to a memory space in which two or more processes can utilize the same memory space.
- the controller 108 can save information to the memory 102 (e.g., the auxiliary access register 104) and the BIOS 106 can access that saved information.
- the secured shared memory 102 can define a root of trust between the controller 108 and the BIOS 108. That is, the secured shared memory 102 can allow for secure Interactions between the controller 108 and the BIOS 106 to ensure security therebetween.
- Figure 2 illustrates an example of a computing device 200 including a controller 208, a memory 202 Including an auxiliary access register 204, and an auxiliary device 210 consistent with the disclosure.
- the auxiliary device 210 can include firmware 212.
- the computing device 200 can include a memory 202 having an auxiliary access register 204 and an auxiliary device 210.
- Data e.g,, status information
- a firmware 212 of the auxiliary device 210 can be retrieved by the controller 208 and stored in the auxiliary access register 204 for access by the BIOS 206, as is further described herein. Access to such information by the BIOS 206 can allow for a determination as to the status of the firmware 212, as is further described herein.
- the computing device 200 can include a controller 208.
- the term “controller” refers to a hardware device or a software program that directs the flow of data between two entities.
- the controller 208 can direct the flow of data between the auxiliary device 210 and the auxiliary access register 204.
- Controller 208 can be, for example, an embedded controller, a super input/output (I/O), Integrated circuit, etc.
- the controller 208 can retrieve status information about a firmware 212 of the auxiliary device 210 connected to the controller 208 from the auxiliary device 210.
- the term "status information” refers to data describing a state of an item.
- the status information about the firmware 212 can include data describing whether the firmware 212 is In an operational condition or whether the firmware 212 is In a non-operationai condition (e.g., corrupted).
- the controller 208 can retrieve the status information about the firmware 212 of the auxiliary device 210 from the auxiliary device 210 by communicating with the auxiliary device 210.
- the controller 208 can include a driver (e.g., included in firmware of the controller 208, not illustrated in Figure 2) corresponding to a particular communication protocol associated with the auxiliary device 210 to perform such communication.
- the term “driver” refers to computing device software to enable a computing device to interface and communicate with another device.
- the driver included with the controller 208 can allow the controller 208 to communicate with the auxiliary device 210 via a communication protocol associated with the auxiliary device 210.
- Such a communication protocol can include, for example, serial peripheral interface (SPI), inter-integrated circuit (I2C), etc., and such a driver can allow the controller 208 to communicate with the auxiliary device 210 via the SRI communication protocol, the I2C communication protocol, among other types of communication protocols.
- SPI serial peripheral interface
- I2C inter-integrated circuit
- the controller 208 can retrieve the status information from the auxiliary device 210 according to the communication protocol associated with the auxiliary device 210. For instance, the controiler can retrieve the status information about the firmware 212 from the auxiliary device 210 via the I2C communication protocol.
- the controller 208 can store the status Information in the auxiliary access register 204.
- the controller 208 can perform a write function to the auxiliary access register 204 to store the status information about the firmware 212 in the auxiliary access register 204.
- the BIOS 206 can then retrieve such status information and determine the status of the firmware 212 utilizing the processing capabilities associated with the BIOS 206, as is further described herein.
- the BIOS 206 can transmit a signed read request to the controller 208.
- the term “signed read request” refers to a message sent from an applicant to a registrant for verification of a signature.
- the BIOS 206 can transmit the signed read request to the controller 208 for verification the BIOS 206 is a trusted entity.
- the controller 208 can verify the signed read request from the BIOS 206. in response to the signed read request being verified by the controller 208, the BIOS 206 can access the auxiliary access register 204 to determine a status of the firmware 212 via the status information.
- auxiliary access register 204 for the BIOS 206 can be granted during a pre-boot stage of the computing device 200.
- pre-boot stage refers to the stages of a power-up sequence of a computing device prior to transfer of control of the computing device to an OS of the computing device.
- Restricting access by the BIOS 206 to the auxiliary access register 204 to the pre-boot stage of the computing device 200 can prevent any malicious components in the OS of the computing device 200 from utilizing the auxiliary access register 204 to exploit the auxiliary device 210, Accordingly, in response to the computing device 200 being in the pre-boot stage and the controller 208 verifying the signed read request from the BIOS 206, the controller 208 can grant access to the auxiliary access register 204 for the BIOS 206 to allow the BIOS 206 to determine a status of the firmware 212 via the status information stored in the auxiliary access register 204.
- the controller can deny the BIOS 206 access to the auxiliary access register 204.
- the BIOS 206 can transmit a signed read request to the controller 208, and in response to the computing device 200 not being in the pre-boot stage, the controller 208 can deny the BIOS 206 access to the auxiliary access register 204.
- the BIOS 206 can determine the status of the auxiliary device 210 by determining a status of the firmware 212 of the auxiliary device 210. Such a status of the firmware 212 (e.g,, whether it is in an operational condition or a non-operationai condition) can dictate whether the auxiliary device 210 is functioning properiy or not.
- the BIOS 206 can determine the status of the firmware 212 by checking a signature of an image of the firmware 212 (e.g., included in the status information retrieved by the controller 208 from the auxiliary device 210 and stored in the auxiliary access register 204). For example, the BIOS 208 can verify the image of the firmware 212 with a compute signature and if any changes are present in the image of the firmware 212, the signature check can fail, in such an example, the BIOS 206 can determine the status of the firmware 212 to be in a non-operationai condition (e.g,, the firmware 212 is corrupted).
- a non-operationai condition e.g, the firmware 212 is corrupted.
- the BIOS 206 can determine the status of the firmware 212 by comparing a checksum of the firmware 212 (e.g., included in the status information retrieved by the controller 208 from the auxiliary device 210 and stored in the auxiliary access register 204) with a predetermined checksum. For example, the BIOS 206 can compare the checksum of the firmware 212 with a predetermined checksum and if they do not match, the comparison can fail. In such an example, the BIOS 206 can determine the status of the firmware 212 to be in a non-operational condition (e.g., the firmware 212 is corrupted).
- the BIOS 208 can determine the status of the firmware 212 by checking a particular set of registers of the firmware 212 (e.g., included in the status information retrieved by the controller 208 from the auxiliary device 210 and stored in the auxiliary access register 204) to make sure configuration parameters included in the registers are valid. If such registers are not vaiid, the BIOS 206 can determine the status of the firmware 212 to be in a non-operationai condition (e.g., the firmware 212 is corrupted).
- BIOS 206 is described above as determining the status of the firmware 212 via a signature, a checksum comparison, and/or checking the validity of configuration parameters in a set of registers, examples of the disclosure are not so limited. For instance, the BIOS 206 can determine the status of the firmware 212 by any other method.
- BIOS 206 is described above as determining the status of the firmware 212 is in a non-operational condition, examples of the disclosure are not so limited. For example, If the signature of the image of the firmware 212 matches the compute signature, if the checksum of the firmware 212 matches the predetermined checksum, and/or if the configuration parameters in a set of registers are valid, the BIOS 206 can determine the status of the firmware 212 to be in an operational condition and take no further action.
- the BIOS 206 can cause the auxiliary device 210 to perform a firmware recovery based on the status of the firmware 212.
- firmware recovery refers to reverting a state of firmware to previous state.
- the BIOS 206 in response to the firmware 212 being in a non-operational condition, can cause the firmware 212 to be reverted to a previous operational condition.
- the BIOS 206 can cause the auxiliary device 210 to perform a firmware recovery of the firmware 212 in response to the status of the firmware 212 indicating the firmware is corrupted to revert the firmware 212 to an operational condition, as is further described in connection with Figure 3.
- Figure 3 illustrates an example of a computing device 300 including a controller 308, a memory 302 including an auxiliary access register 304, an auxiliary device 310, and a pin 314 consistent with the disclosure.
- the auxiliary device 310 can include firmware 312.
- the computing device 300 can include a memory 302 having an auxiliary access register 304 and an auxiliary device 310. Status information about the firmware 312 of the auxiliary device 310 can be retrieved by the controller 308 and stored in the auxiliary access register 304.
- the BIOS 306 can access the auxiliary access register 304 to determine a status of the firmware 312 during a pre-boot stage of the computing device 300.
- the BIOS 306 can cause the auxiliary device 310 to perform a firmware recovery in response to the status of the firmware 312 indicating the firmware is corrupted to revert the firmware 312 to an operational condition, as is further described herein.
- the BIOS 306 can cause the firmware recovery of the auxiliary device 310 by transmitting a write request for the auxiliary access register 304 to the controller 308.
- the term “write request” refers to a message sent from one device to another device to ask to move data to a location.
- the BIOS 306 can transmit a write request for the auxiliary access register 304 to the controller 308 with the intention of writing data (e.g,, recovery information) to the auxiliary access register 304 to cause the firmware 312 to perform a recovery operation.
- the BIOS 306 can write recovery information to the auxiliary access register 304.
- recovery information refers to instructions for flashing a firmware. That is, the BIOS 306 can write instructions to the auxiliary access register 304 that can enable the controller 308 to cause the auxiliary device 310 to perform the firmware recovery.
- the controller 308 can read the recovery information in the auxiliary access register 304. In response, the controller 308 can cause the auxiliary device 310 to perform the firmware recovery by causing the pin 314 to be asserted.
- the term “pin” refers to an electrical contact used in a signal interface between two devices.
- the pin 314 can be asserted to cause the controller 308 to access a recovery package to flash the firmware 312 of the auxiliary device 310.
- the term “recovery package” refers to a set of instructions associated with a particular firmware to flash the particular firmware.
- the controller 308 can access a recovery package corresponding to the firmware 312 of the auxiliary device 310 when the pin 314 is asserted.
- the controller 308 can cause the auxiliary device 310 to flash the firmware 312 utilizing the recovery package.
- the controller 308 can cause the auxiliary device 310 to perform a power cycle.
- the term “power cycle” refers to powering off a device and then powering the device back on.
- the controller 308 can cause the auxiliary device 310 to power off and then power on to complete the firmware recovery process.
- Figure 4 illustrates a block diagram of an example system 416 to obtain status information of auxiliary devices consistent with the disclosure.
- system 416 includes a processing resource 418 and a non-transitory machine-readable storage medium 420.
- the following descriptions refer to a single processing resource and a single machine- readable storage medium, the descriptions may also apply to a system with multiple processors and multiple machine-readable storage mediums.
- the instructions may be distributed across multiple machine-readable storage mediums and the instructions may be distributed across multiple processors. Put another way, the instructions may be stored across multiple machine-readable storage mediums and executed across multiple processors, such as in a distributed computing environment.
- Processing resource 418 may be a central processing unit (CPU), microprocessor, and/or other hardware device suitable for retrieval and execution of instructions stored in the non-transitory machine-readable storage medium 420.
- the processing resource 418 may receive, determine, and send instructions to cause a BIOS (e.g., BIOS 106, 206, 306, previously described in connection with Figures 1-3 respectively) to interact with an auxiliary access register stored in memory.
- a BIOS e.g., BIOS 106, 206, 306, previously described in connection with Figures 1-3 respectively
- the processing resource 418 may include an electronic circuit comprising a number of electronic components for performing the operations of the instructions in the non-transitory machine-readable storage medium 420.
- the non-transitory machine-readable storage medium 420 may be any electronic, magnetic, optical, or other physical storage device that stores executable instructions.
- non-transitory machine-readable storage medium 420 may be, for example, Random Access Memory (RAM), an E!ectrical!y-Erasable Programmable Read-Only Memory (EEPROM), a storage drive, an optical disc, and the like.
- RAM Random Access Memory
- EEPROM E!ectrical!y-Erasable Programmable Read-Only Memory
- the non-transitory machine-readable storage medium 420 may be a portable, external or remote storage medium, for example, that allows the system 416 to download the instructions from the portabie/external/remote storage medium. In this situation, the executable instructions may be part of an “installation package”.
- Figure 5 illustrates an example flow chart 522 for a controller for status information of auxiliary devices consistent with the disclosure.
- the controller of a computing device can generate an auxiliary access register.
- the auxiliary access register can store data related to an auxiliary device and can be generated in a secured shared memory of the computing device between the controller and a BIOS of the computing device.
- the controller can retrieve status information about firmware of an auxiliary device from the auxiliary device.
- the status information can be data describing a status of the firmware of the auxiliary device, such as whether the firmware is in an operational condition or a non-operationai condition (e,g., corrupted).
- the controller can retrieve the status information about the firmware from the auxiliary device utilizing a driver for a particular communication protocol associated with the auxiliary device (e.g., SRI, I2C, etc.)
- the controller can store the retrieved status information in the auxiliary access register.
- the controller can perform a write function on the auxiliary access register to store the retrieved status information.
- the BIOS can transmit a read request to the controller, as is further described in connection with Figure 8.
- the controller can, at 534, grant access to the auxiliary access register to allow the BIOS to access the auxiliary access register. If the computing device is not in the pre-boot stage or the read request received by the controller Is not verified by the controller, the controller can, at 532, deny access to the auxiliary access register.
- FIG. 6 illustrates an example flow chart 836 for a BIOS for status information of auxiliary devices consistent with the disclosure.
- the BIOS can transmit a signed read request to the controller.
- the controller can, at 842, deny access to the auxiliary access register to the BIOS. If the computing device is in the pre-boot stage and the read request is verified by the controller, the controller can grant access to the auxiliary access register to allow the BIOS to access the auxiliary access register. Accordingly, at 644, the BIOS can access the auxiliary access register to determine a status of the firmware of the auxiliary device.
- the BIOS can determine the status of the firmware of the auxiliary device to determine whether the firmware of the auxiliary device is in an operational condition or a non-operational condition, as such a condition can dictate whether the auxiliary device is functioning properly or not.
- the BIOS can determine the status of the firmware by, for instance, checking a signature of an image of the firmware, comparing a checksum of the firmware with a predetermined checksum, checking a set of registers to make sure configuration parameters included in the registers are valid, etc.
- the BIOS can determine whether the status of the firmware is in an operational condition. If the BIOS determines the status of the firmware is in an operational condition, at 648 the BIOS and the controller can stop operations, if the BIOS determines the status of the firmware is in a non- operationa! condition, the BIOS can, at 650, cause a firmware recovery of the auxiliary device to occur by transmitting a write request to the auxiliary access register to cause the controller to perform a recovery operation.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Stored Programmes (AREA)
Abstract
Example implementations relate to status information of auxiliary devices. In some examples, a computing device can include a memory having an auxiliary access register, an auxiliary device, a controller to retrieve status information from the auxiliary device connected to the controller and store the status information in the auxiliary access register, and a BIOS to access the auxiliary access register to determine a status of the auxiliary device via the status information.
Description
STATUS INFORMATION OF AUXILIARY DEVICES
Background
[0001] A computing device can include a processor and auxiliary devices. Such auxiliary devices can be utilized in combination with the processor to allow the computing device to perform computing device operations. A computing device can allow a user to utilize such computing device operations for work, education, gaming, multimedia, and/or other general use.
Brief Description of the Drawings
[0002] Figure 1 illustrates an example of a computing device including a controller and an auxiliary device consistent with the disclosure.
[0003] Figure 2 illustrates an example of a computing device including a controller, a memory including an auxiliary access register, and an auxiliary device consistent with the disclosure.
[0004] Figure 3 illustrates an example of a computing device including a controller, a memory including an auxiliary access register, an auxiliary device, and a pin consistent with the disclosure.
[0005] Figure 4 illustrates a block diagram of an example system to obtain status information of auxiliary devices consistent with the disclosure. [0006] Figure 5 illustrates an example flow chart for a controller for status information of auxiliary devices consistent with the disclosure.
[0007] Figure 6 illustrates an example flow chart for a basic input/output system (BIOS) for status information of auxiliary devices consistent with the disclosure.
Detailed Description
[0008] A user may utilize a computing device for various purposes, such as for business and/or recreational use. As used herein, the term “computing device” refers to an electronic system having a processing resource, memory resource, and/or an application-specific integrated circuit (ASIC) that can
process information. A computing device can be, for example, a laptop computer, a notebook, a tablet, and/or a mobile device, among other types of computing devices.
[0009] As described above, a computing device can utilize a processor as well as auxiliary devices to perform computing device operations. As used herein, the term “auxiliary device” refers to an ancillary device to a main central processing unit (CPU) of a computing device, where the ancillary device includes firmware storing instructions that when executed cause the ancillary device to perform computing device operations. The auxiliary device can be, for example, a controller, a microcontroller, a microprocessor, etc. In a computing device including a processor (e.g., a CPU) and an auxiliary device, the processor and the auxiliary device can each execute respective instructions in order to facilitate the computing device to perform computing device operations. [0010] An auxiliary device may execute instructions to facilitate performance of computing device operations that are stored in firmware. As used herein, the term “firmware” refers to a set of instructions included in memory that provide for low-level control of a hardware device. For example, an auxiliary device can execute instructions stored in the firmware of the auxiliary device (e.g., via a microprocessor, controller, etc. of the auxiliary device) that can instruct the auxiliary device to perform computing device operations and/or perform computing device operations in combination with other auxiliary devices and/or the processor of the computing device.
[0011] While the firmware of an auxiliary device can be utilized to facilitate performance of computing device operations, the auxiliary device may not have sufficient processing capability to detect a firmware failure of its own firmware. For example, a microprocessor of an auxiliary device may not be sufficiently capable of detecting a failure of the firmware of the auxiliary device.
If such a firmware failure were to occur, the auxiliary device may no longer be able to perform computing device operations which may affect other auxiliary devices and/or the processor of the computing device. In other words, a firmware failure of one auxiliary device may cause other errors in computing device operations with respect to remaining auxiliary devices and/or the
processor of the computing device. This can lead to a negative user experience for a user of the computing device.
[0012] As described below, the computing device can utilize a controller to communicate with such an auxiliary device to retrieve status information from the auxiliary device. Utilizing such status information, a basic input/output system (BIOS) of the computing device can determine a status of the auxiliary device utilizing the computing capabilities of the processor and BIOS of the computing device. In an event in which the BiOS determines there is an issue with the firmware of the auxiliary device, the BIOS can cause the auxiliary device to perform a firmware recovery. Such an approach can allow for detection of firmware errors while maintaining security between the auxiliary device and the BiOS.
[0013] Figure 1 illustrates an example of a computing device 100 including a controller 108 and an auxiliary device 110 consistent with the disclosure. As illustrated in Figure 1, the computing device 100 can include a memory 102, a BiOS 106, a controller 108, and an auxiliary device 110. The memory 102 can include an auxiliary access register 104.
[0014] The computing device 100 can include a memory 102 having an auxiliary access register 104, As used herein, the term “auxiliary access register” refers to a data holding element to store instructions, addresses, and/or other data directly accessible by a processor. For example, the auxiliary access register 104 can store data related to the auxiliary device 110 and can be accessible by the BIOS 108 to determine a status of the auxiliary device 110, as is further described herein.
[0015] Data related to the auxiliary device 110 can be retrieved and stored in the auxiliary access register 104, As described above, the auxiliary device 110 can be an ancillary device of the computing device 100 to perform and/or assist in performing computing device operations. The auxiliary device 110 can be, for example, a controller, a microcontroller, a microprocessor, etc. [0018] As illustrated in Figure 1, the auxiliary device 110 can be connected to the controller 108 via an electrical connection. Such an electrical connection can allow the controller 108 to communicate with (e.g., transmit
information to and/or receive information from) the auxiliary device 110, as is further described in connection with Figure 2.
[0017] The computing device 100 can include a BIOS 106. As used herein, the term “BIOS” refers to hardware or hardware and instructions to initialize, control, or operate a computing device prior to execution of an operating system (OS) of the computing device, instructions included within the BIOS 106 may be software, firmware, microcode, or other programming that defines or controls functionality or operation of a BIOS 106. In one example, the BIOS 106 may be implemented using instructions, such as platform firmware of a computing device, executable by a processor. The BIOS 106 may operate or execute prior to the execution of the OS of the computing device 100. The BIOS 106 may initialize, control, or operate components such as hardware components of the computing device 100 and may load or boot the OS of computing device 100.
[0018] in some examples, the BIOS 106 may provide or establish an interface between hardware devices or platform firmware of the computing device 100 and an OS of the computing device 100, via which the OS of the computing device 100 may control or operate hardware devices or platform firmware of the computing device 100. In some examples, the BIOS 106 may implement the Unified Extensible Firmware Interface (UEFi) specification or another specification or standard for initializing, controlling, or operating a computing device 100.
[0019] Accordingly, the BIOS 106 can access the auxiliary access register 104 to determine a status of the auxiliary device 110. For example, the BIOS 106 can access status information included in the auxiliary access register 104 to determine the status of the auxiliary device 110, as is further described in connection with Figure 2.
[0020] The memory 102 can be a secured shared memory. As used herein, the term “secured shared memory” refers to a memory space in which two or more processes can utilize the same memory space. For example, the controller 108 can save information to the memory 102 (e.g., the auxiliary access register 104) and the BIOS 106 can access that saved information. The
secured shared memory 102 can define a root of trust between the controller 108 and the BIOS 108. That is, the secured shared memory 102 can allow for secure Interactions between the controller 108 and the BIOS 106 to ensure security therebetween.
[0021] Figure 2 illustrates an example of a computing device 200 including a controller 208, a memory 202 Including an auxiliary access register 204, and an auxiliary device 210 consistent with the disclosure. The auxiliary device 210 can include firmware 212.
[0022] As previously described in connection with Figure 1, the computing device 200 can include a memory 202 having an auxiliary access register 204 and an auxiliary device 210. Data (e.g,, status information) about a firmware 212 of the auxiliary device 210 can be retrieved by the controller 208 and stored in the auxiliary access register 204 for access by the BIOS 206, as is further described herein. Access to such information by the BIOS 206 can allow for a determination as to the status of the firmware 212, as is further described herein.
[0023] As illustrated in Figure 2, the computing device 200 can include a controller 208. As used herein, the term “controller” refers to a hardware device or a software program that directs the flow of data between two entities. For example, the controller 208 can direct the flow of data between the auxiliary device 210 and the auxiliary access register 204. Controller 208 can be, for example, an embedded controller, a super input/output (I/O), Integrated circuit, etc.
[0024] The controller 208 can retrieve status information about a firmware 212 of the auxiliary device 210 connected to the controller 208 from the auxiliary device 210. As used herein, the term "status information” refers to data describing a state of an item. For example, the status information about the firmware 212 can include data describing whether the firmware 212 is In an operational condition or whether the firmware 212 is In a non-operationai condition (e.g., corrupted).
[0025] The controller 208 can retrieve the status information about the firmware 212 of the auxiliary device 210 from the auxiliary device 210 by
communicating with the auxiliary device 210. The controller 208 can include a driver (e.g., included in firmware of the controller 208, not illustrated in Figure 2) corresponding to a particular communication protocol associated with the auxiliary device 210 to perform such communication. As used herein, the term “driver" refers to computing device software to enable a computing device to interface and communicate with another device. For example, the driver included with the controller 208 can allow the controller 208 to communicate with the auxiliary device 210 via a communication protocol associated with the auxiliary device 210. Such a communication protocol can include, for example, serial peripheral interface (SPI), inter-integrated circuit (I2C), etc., and such a driver can allow the controller 208 to communicate with the auxiliary device 210 via the SRI communication protocol, the I2C communication protocol, among other types of communication protocols.
[0026] Utilizing the driver, the controller 208 can retrieve the status information from the auxiliary device 210 according to the communication protocol associated with the auxiliary device 210. For instance, the controiler can retrieve the status information about the firmware 212 from the auxiliary device 210 via the I2C communication protocol.
[0027] Once the status information is retrieved from the auxiliary device 210, the controller 208 can store the status Information in the auxiliary access register 204. For example, the controller 208 can perform a write function to the auxiliary access register 204 to store the status information about the firmware 212 in the auxiliary access register 204. The BIOS 206 can then retrieve such status information and determine the status of the firmware 212 utilizing the processing capabilities associated with the BIOS 206, as is further described herein.
[0028] In order to access the auxiliary access register 204, the BIOS 206 can transmit a signed read request to the controller 208. As used herein, the term “signed read request” refers to a message sent from an applicant to a registrant for verification of a signature. For example, the BIOS 206 can transmit the signed read request to the controller 208 for verification the BIOS 206 is a trusted entity.
[0029] The controller 208 can verify the signed read request from the BIOS 206. in response to the signed read request being verified by the controller 208, the BIOS 206 can access the auxiliary access register 204 to determine a status of the firmware 212 via the status information.
[0030] Access to the auxiliary access register 204 for the BIOS 206 can be granted during a pre-boot stage of the computing device 200. As used herein, the term “pre-boot stage” refers to the stages of a power-up sequence of a computing device prior to transfer of control of the computing device to an OS of the computing device. Restricting access by the BIOS 206 to the auxiliary access register 204 to the pre-boot stage of the computing device 200 can prevent any malicious components in the OS of the computing device 200 from utilizing the auxiliary access register 204 to exploit the auxiliary device 210, Accordingly, in response to the computing device 200 being in the pre-boot stage and the controller 208 verifying the signed read request from the BIOS 206, the controller 208 can grant access to the auxiliary access register 204 for the BIOS 206 to allow the BIOS 206 to determine a status of the firmware 212 via the status information stored in the auxiliary access register 204.
[0031] In an example in which the computing device 200 is not in the preboot stage, the controller can deny the BIOS 206 access to the auxiliary access register 204. For example, the BIOS 206 can transmit a signed read request to the controller 208, and in response to the computing device 200 not being in the pre-boot stage, the controller 208 can deny the BIOS 206 access to the auxiliary access register 204.
[0032] The BIOS 206 can determine the status of the auxiliary device 210 by determining a status of the firmware 212 of the auxiliary device 210. Such a status of the firmware 212 (e.g,, whether it is in an operational condition or a non-operationai condition) can dictate whether the auxiliary device 210 is functioning properiy or not.
[0033] In some examples, the BIOS 206 can determine the status of the firmware 212 by checking a signature of an image of the firmware 212 (e.g., included in the status information retrieved by the controller 208 from the auxiliary device 210 and stored in the auxiliary access register 204). For
example, the BIOS 208 can verify the image of the firmware 212 with a compute signature and if any changes are present in the image of the firmware 212, the signature check can fail, in such an example, the BIOS 206 can determine the status of the firmware 212 to be in a non-operationai condition (e.g,, the firmware 212 is corrupted).
[0034] in some examples, the BIOS 206 can determine the status of the firmware 212 by comparing a checksum of the firmware 212 (e.g., included in the status information retrieved by the controller 208 from the auxiliary device 210 and stored in the auxiliary access register 204) with a predetermined checksum. For example, the BIOS 206 can compare the checksum of the firmware 212 with a predetermined checksum and if they do not match, the comparison can fail. In such an example, the BIOS 206 can determine the status of the firmware 212 to be in a non-operational condition (e.g., the firmware 212 is corrupted).
[0035] In some examples, the BIOS 208 can determine the status of the firmware 212 by checking a particular set of registers of the firmware 212 (e.g., included in the status information retrieved by the controller 208 from the auxiliary device 210 and stored in the auxiliary access register 204) to make sure configuration parameters included in the registers are valid. If such registers are not vaiid, the BIOS 206 can determine the status of the firmware 212 to be in a non-operationai condition (e.g., the firmware 212 is corrupted). [0038] Although the BIOS 206 is described above as determining the status of the firmware 212 via a signature, a checksum comparison, and/or checking the validity of configuration parameters in a set of registers, examples of the disclosure are not so limited. For instance, the BIOS 206 can determine the status of the firmware 212 by any other method.
[0037] Further, although the BIOS 206 is described above as determining the status of the firmware 212 is in a non-operational condition, examples of the disclosure are not so limited. For example, If the signature of the image of the firmware 212 matches the compute signature, if the checksum of the firmware 212 matches the predetermined checksum, and/or if the configuration parameters in a set of registers are valid, the BIOS 206 can determine the
status of the firmware 212 to be in an operational condition and take no further action.
[0038] The BIOS 206 can cause the auxiliary device 210 to perform a firmware recovery based on the status of the firmware 212. As used herein, the term “firmware recovery” refers to reverting a state of firmware to previous state. For example, in response to the firmware 212 being in a non-operational condition, the BIOS 206 can cause the firmware 212 to be reverted to a previous operational condition. In other words, the BIOS 206 can cause the auxiliary device 210 to perform a firmware recovery of the firmware 212 in response to the status of the firmware 212 indicating the firmware is corrupted to revert the firmware 212 to an operational condition, as is further described in connection with Figure 3.
[0039] Figure 3 illustrates an example of a computing device 300 including a controller 308, a memory 302 including an auxiliary access register 304, an auxiliary device 310, and a pin 314 consistent with the disclosure. The auxiliary device 310 can include firmware 312.
[0040] As previously described in connection with Figure 1 , the computing device 300 can include a memory 302 having an auxiliary access register 304 and an auxiliary device 310. Status information about the firmware 312 of the auxiliary device 310 can be retrieved by the controller 308 and stored in the auxiliary access register 304. The BIOS 306 can access the auxiliary access register 304 to determine a status of the firmware 312 during a pre-boot stage of the computing device 300. The BIOS 306 can cause the auxiliary device 310 to perform a firmware recovery in response to the status of the firmware 312 indicating the firmware is corrupted to revert the firmware 312 to an operational condition, as is further described herein.
[0041] The BIOS 306 can cause the firmware recovery of the auxiliary device 310 by transmitting a write request for the auxiliary access register 304 to the controller 308. As used herein, the term “write request” refers to a message sent from one device to another device to ask to move data to a location. For example, the BIOS 306 can transmit a write request for the auxiliary access register 304 to the controller 308 with the intention of writing
data (e.g,, recovery information) to the auxiliary access register 304 to cause the firmware 312 to perform a recovery operation.
[0042] In response to the controller 308 granting the write request when the computing device 300 is in the pre-boot stage, the BIOS 306 can write recovery information to the auxiliary access register 304. As used herein, the term “recovery information” refers to instructions for flashing a firmware. That is, the BIOS 306 can write instructions to the auxiliary access register 304 that can enable the controller 308 to cause the auxiliary device 310 to perform the firmware recovery.
[0043] The controller 308 can read the recovery information in the auxiliary access register 304. In response, the controller 308 can cause the auxiliary device 310 to perform the firmware recovery by causing the pin 314 to be asserted. As used herein, the term “pin” refers to an electrical contact used in a signal interface between two devices. The pin 314 can be asserted to cause the controller 308 to access a recovery package to flash the firmware 312 of the auxiliary device 310. As used herein, the term “recovery package” refers to a set of instructions associated with a particular firmware to flash the particular firmware. For example, the controller 308 can access a recovery package corresponding to the firmware 312 of the auxiliary device 310 when the pin 314 is asserted. The controller 308 can cause the auxiliary device 310 to flash the firmware 312 utilizing the recovery package.
[0044] When the firmware flash of the firmware 312 is completed, the pin 314 can be de-asserted. To complete the firmware flash of the firmware 312, the controller 308 can cause the auxiliary device 310 to perform a power cycle. As used herein, the term “power cycle” refers to powering off a device and then powering the device back on. For example, the controller 308 can cause the auxiliary device 310 to power off and then power on to complete the firmware recovery process.
[0045] Figure 4 illustrates a block diagram of an example system 416 to obtain status information of auxiliary devices consistent with the disclosure. In the example of Figure 4, system 416 includes a processing resource 418 and a non-transitory machine-readable storage medium 420. Although the following
descriptions refer to a single processing resource and a single machine- readable storage medium, the descriptions may also apply to a system with multiple processors and multiple machine-readable storage mediums. In such examples, the instructions may be distributed across multiple machine-readable storage mediums and the instructions may be distributed across multiple processors. Put another way, the instructions may be stored across multiple machine-readable storage mediums and executed across multiple processors, such as in a distributed computing environment.
[0046] Processing resource 418 may be a central processing unit (CPU), microprocessor, and/or other hardware device suitable for retrieval and execution of instructions stored in the non-transitory machine-readable storage medium 420. In the particular example shown in Figure 4, the processing resource 418 may receive, determine, and send instructions to cause a BIOS (e.g., BIOS 106, 206, 306, previously described in connection with Figures 1-3 respectively) to interact with an auxiliary access register stored in memory. As an alternative or In addition to retrieving and executing instructions, the processing resource 418 may include an electronic circuit comprising a number of electronic components for performing the operations of the instructions in the non-transitory machine-readable storage medium 420.
[0047] The non-transitory machine-readable storage medium 420 may be any electronic, magnetic, optical, or other physical storage device that stores executable instructions. Thus, non-transitory machine-readable storage medium 420 may be, for example, Random Access Memory (RAM), an E!ectrical!y-Erasable Programmable Read-Only Memory (EEPROM), a storage drive, an optical disc, and the like. The non-transitory machine-readable storage medium 420 may be a portable, external or remote storage medium, for example, that allows the system 416 to download the instructions from the portabie/external/remote storage medium. In this situation, the executable instructions may be part of an “installation package”.
[0048] Figure 5 illustrates an example flow chart 522 for a controller for status information of auxiliary devices consistent with the disclosure. At 524, the controller of a computing device can generate an auxiliary access register. The
auxiliary access register can store data related to an auxiliary device and can be generated in a secured shared memory of the computing device between the controller and a BIOS of the computing device.
[0049] At 528, the controller can retrieve status information about firmware of an auxiliary device from the auxiliary device. The status information can be data describing a status of the firmware of the auxiliary device, such as whether the firmware is in an operational condition or a non-operationai condition (e,g., corrupted). The controller can retrieve the status information about the firmware from the auxiliary device utilizing a driver for a particular communication protocol associated with the auxiliary device (e.g., SRI, I2C, etc.)
[0050] At 528, the controller can store the retrieved status information in the auxiliary access register. The controller can perform a write function on the auxiliary access register to store the retrieved status information. When the BIOS is to access the auxiliary access register, the BIOS can transmit a read request to the controller, as is further described in connection with Figure 8. [0051] At 530, when the computing device is in the pre-boot stage and the read request is verified by the controller, the controller can, at 534, grant access to the auxiliary access register to allow the BIOS to access the auxiliary access register. If the computing device is not in the pre-boot stage or the read request received by the controller Is not verified by the controller, the controller can, at 532, deny access to the auxiliary access register.
[0052] Figure 6 illustrates an example flow chart 836 for a BIOS for status information of auxiliary devices consistent with the disclosure. At 638, in order to access the auxiliary access register, the BIOS can transmit a signed read request to the controller. At 640, if the computing device is not in the pre-boot stage or the read request received by the controller is not verified by the controller, the controller can, at 842, deny access to the auxiliary access register to the BIOS. If the computing device is in the pre-boot stage and the read request is verified by the controller, the controller can grant access to the auxiliary access register to allow the BIOS to access the auxiliary access
register. Accordingly, at 644, the BIOS can access the auxiliary access register to determine a status of the firmware of the auxiliary device.
[0053] The BIOS can determine the status of the firmware of the auxiliary device to determine whether the firmware of the auxiliary device is in an operational condition or a non-operational condition, as such a condition can dictate whether the auxiliary device is functioning properly or not. The BIOS can determine the status of the firmware by, for instance, checking a signature of an image of the firmware, comparing a checksum of the firmware with a predetermined checksum, checking a set of registers to make sure configuration parameters included in the registers are valid, etc.
[0054] At 646, the BIOS can determine whether the status of the firmware is in an operational condition. If the BIOS determines the status of the firmware is in an operational condition, at 648 the BIOS and the controller can stop operations, if the BIOS determines the status of the firmware is in a non- operationa! condition, the BIOS can, at 650, cause a firmware recovery of the auxiliary device to occur by transmitting a write request to the auxiliary access register to cause the controller to perform a recovery operation.
[0055] In the foregoing detailed description of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration how examples of the disclosure may be practiced. These examples are described in detail to enable those of ordinary skill in the art to practice the examples of this disclosure, and it is to be understood that other examples may be utilized and that process, electrical, and/or structural changes may be made without departing from the scope of the disclosure.
[0058] The figures herein follow a numbering convention in which the first digit corresponds to the drawing figure number and the remaining digits identify an element or component in the drawing. Similar elements or components between different figures may be identified by the use of similar digits. For example, 102 may reference element “02" in Figure 1, and a similar element may be referenced as 202 in Figure 2.
[0057] Elements illustrated in the various figures herein can be added, exchanged, and/or eliminated so as to provide a plurality of additional examples
of the disclosure, in addition, the proportion and the reiative scale of the elements provided in the figures are intended to iilustrate the examples of the disclosure and should not be taken in a limiting sense. As used herein, "a plurality of an element and/or feature can refer to more than one of such elements and/or features.
Claims
1. A computing device, comprising: a memory having an auxiliary access register; an auxiliary device; a controller, wherein the controller is to: retrieve status information from the auxiliary device connected to the controller; and store the status information in the auxiliary access register: and a basic input/output system (BIOS) to access the auxiliary access register to determine a status of the auxiliary device via the status information.
2. The computing device of claim 1 , wherein the controller is to allow the BIOS to access the auxiliary access register during a pre-boot stage of the computing device.
3. The computing device of claim 1 , wherein in response to the computing device not being in a pre-boot stage, the controller is to deny the BIOS access to the auxiliary access register.
4. The computing device of claim 1 , wherein the BIOS is to determine the status of the auxiliary device by determining a status of a firmware of the auxiliary device.
5. The computing device of claim 1, wherein the controller includes a driver corresponding to a communication protocol associated with the auxiliary device.
8. The computing device of claim 5, wherein the controller is to retrieve the status information from the auxiliary device via the driver according to the communication protocol.
7. The computing device of claim 1, wherein the memory is a secured shared memory defining a root of trust between the controller and the BIOS.
8. A computing device, comprising: a memory having an auxiliary access register; an auxiliary device; a controller, wherein the controller is to: retrieve status information about a firmware of the auxiliary device connected to the controller from the auxiliary device; and store the status information in the auxiliary access register; and a basic input/output system (BIOS) to: access the auxiliary access register to determine a status of the firmware via the status information during a pre-boot stage of the computing device; and cause the auxiliary device to perform a firmware recovery based on the status of the firmware.
9. The computing device of claim 8, wherein: the BIOS is to access the auxiliary access register to determine the status of the firmware by transmitting a read request for the auxiliary access register to the controller; and the controller is to grant access to the auxiliary access register for the BIOS in response to the computing device being in the pre-boot stage.
10. The computing device of claim 9, wherein the controller is to deny access to the auxiliary access register for the BIOS in response to the computing device not being in the pre-boot stage.
11. The computing device of claim 8, wherein the BIOS is to cause the firmware recovery of the auxiliary device by: transmitting a write request for the auxiliary access register to the controller; and
in response to the controller granting the write request when the computing device is in the pre-boot stage, writing recovery information to the auxiliary access register.
12. The computing device of claim 11 , wherein the controller is to: read the recovery information in the auxiliary access register; and cause the auxiliary device to perform a firmware recovery.
13. A computing device, comprising: a memory having an auxiliary access register; an auxiliary device; a controller, wherein the controller is to: generate the auxiliary access register; retrieve status information about a firmware of the auxiliary device connected to the controller from the auxiliary device; and store the status information in the auxiliary access register; and a basic input/output system (BIOS) to: transmit a signed read request to the controller; in response to the signed read request being verified by the controller, access the auxiliary access register to determine a status of the firmware via the status information during a pre-boot stage of the computing device; and cause the auxiliary device to perform a firmware recovery based on the status of the firmware.
14. The computing device of claim 13, wherein the BIOS is to cause the auxiliary device to perform the firmware recovery in response to the status of the firmware indicating the firmware is corrupted.
15. The computing device of claim 13, wherein the BIOS is to cause the auxiliary device to perform the firmware recovery by causing:
a pin of the computing device to be asserted to cause the controller to access a recovery package to flash the firmware of the auxiliary device; the pin to be de-asserted in response to the firmware flash of the auxiliary device being completed; and the auxiliary device to perform a power cycle.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/US2021/017785 WO2022173439A1 (en) | 2021-02-12 | 2021-02-12 | Status information of auxiliary devices |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/US2021/017785 WO2022173439A1 (en) | 2021-02-12 | 2021-02-12 | Status information of auxiliary devices |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2022173439A1 true WO2022173439A1 (en) | 2022-08-18 |
Family
ID=82837824
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2021/017785 WO2022173439A1 (en) | 2021-02-12 | 2021-02-12 | Status information of auxiliary devices |
Country Status (1)
Country | Link |
---|---|
WO (1) | WO2022173439A1 (en) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7704147B2 (en) * | 1999-10-06 | 2010-04-27 | Igt | Download procedures for peripheral devices |
US9891996B2 (en) * | 2014-07-15 | 2018-02-13 | Dell Poducts, L.P. | Apparatus and method for recovering an information handling system from a non-operational state |
US10409584B1 (en) * | 2018-02-09 | 2019-09-10 | American Megatrends International, Llc | Peripheral device firmware update using rest over IPMI interface firmware update module |
-
2021
- 2021-02-12 WO PCT/US2021/017785 patent/WO2022173439A1/en active Application Filing
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7704147B2 (en) * | 1999-10-06 | 2010-04-27 | Igt | Download procedures for peripheral devices |
US9891996B2 (en) * | 2014-07-15 | 2018-02-13 | Dell Poducts, L.P. | Apparatus and method for recovering an information handling system from a non-operational state |
US10409584B1 (en) * | 2018-02-09 | 2019-09-10 | American Megatrends International, Llc | Peripheral device firmware update using rest over IPMI interface firmware update module |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10353779B2 (en) | Systems and methods for detection of firmware image corruption and initiation of recovery | |
US10185828B2 (en) | Systems and methods using virtual UEFI path for secure firmware handling in multi-tenant or server information handling system environments | |
CN103718165B (en) | BIOS flash memory attack protection and notice | |
US7584347B2 (en) | System and method for identifying bootable device by generating a signature for each bootable device where the signature is independent of a location of the bootable device | |
US10055357B2 (en) | Systems and methods for secure multi-access of system firmware during pre-boot | |
KR20080108526A (en) | Platform boot with bridge support | |
CN107567629B (en) | Dynamic firmware module loader in trusted execution environment container | |
US20050132177A1 (en) | Detecting modifications made to code placed in memory by the POST BIOS | |
US9047491B2 (en) | Encryption acceleration | |
US10909247B2 (en) | Computing device having two trusted platform modules | |
WO2014175866A1 (en) | Retrieving system boot code from a non-volatile memory | |
US9928367B2 (en) | Runtime verification | |
US11531760B1 (en) | Baseboard management controller (BMC)-based security processor | |
US10684904B2 (en) | Information handling systems and methods to selectively control ownership of a hardware based watchdog timer (WDT) | |
US11651077B2 (en) | Systems and methods for providing secured boot and scan for devices with limited access | |
US11429723B2 (en) | Multi-domain boot and runtime status code drift detection | |
US11106457B1 (en) | Updating firmware runtime components | |
US20070162733A1 (en) | Secure CMOS | |
US10198270B2 (en) | Dynamic hardware configuration via firmware interface at computing device boot | |
US8627054B2 (en) | Method and apparatus to create single firmware image for multiple server platforms | |
US20200319975A1 (en) | Early boot event logging system | |
US20240028433A1 (en) | Reporting pcie device error information | |
US11803454B2 (en) | Chained loading with static and dynamic root of trust measurements | |
US11809876B2 (en) | Trusted platform module protection for non-volatile memory express (NVMe) recovery | |
WO2022173439A1 (en) | Status information of auxiliary devices |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 21925986 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 21925986 Country of ref document: EP Kind code of ref document: A1 |