Secure collection and communication of computing device operational data

Abstract

The technology described herein provides a secure data logger that allows for the targeted collection and storage of both high-level and low-level operational data from any subsystem of a computing device. The data logger acquires and stores device operational data based on stored configuration data. The configuration data indicates one or more memory and / or storage locations from which operational data is acquired on the device, as well as one or more storage locations where the data logger stores acquired operational data. The data logger is implemented in a secure execution environment and operates during all pre-boot phases of the device. The data logger also allows a user to update the BIOS of the computing device based on, for example, a firmware image provided via a network. The data logger also facilitates the acquisition of operational data over time, which makes it easy to operate with a particular hardware configuration and / or a particular software configuration.

Description

Background Technology

[0001] During the execution of a computing device, the device generates and stores many types of operational data, including data stored in persistent storage, in memory, and in hardware registers. Collecting this operational data (e.g., for fault diagnosis) can be challenging, especially when low-level operational data (such as firmware-level data) or hardware-level data (such as register transfer-level data) are required. Accessing the device's operational data using physical access to the device itself is the most efficient method. However, traveling to the target computing device in person can be expensive and / or difficult, particularly when non-controlling parties (such as manufacturers / suppliers of part of the system, third parties hired to diagnose system faults, etc.) require the device's operational data.

[0002] Debugging tools used to collect low-level working data during device development (such as the Joint Test Access Group (JTAG) interface) are typically disabled or removed from the production stack of a device and are therefore unavailable on the deployed system. Developers can remotely access low-level working data of devices on remote computing systems based on knowledge of the remote system's "signature key" infrastructure, or when the system has an unlocked debug port. However, allowing such access to computing systems introduces serious security vulnerabilities, and therefore not all clients will grant the necessary permissions to remotely access device working data.

[0003] To perform remote troubleshooting, developers can attempt to recreate the problems encountered on remote computing devices on their local system. However, establishing such a test system environment requires significant time and engineering effort to faithfully reproduce the specific problems of the target device, especially when the problems are specific to the original equipment manufacturer (OEM) board.

[0004] Furthermore, several telemetry / debugging solutions exist that rely on a deployment system running a specific operating system (OS) or application. These software-based solutions can collect operational data specific to the desired OS or application from a remote system, but typically cannot collect low-level data. Additionally, software-based solutions can only collect operational data when the software is running on the device, i.e., after the OS is initiated via the device's boot sequence following a reboot. Therefore, software-based solutions cannot collect data during the pre-boot phase of a computing device. Moreover, software-based solutions are disadvantageous for firmware updates, which are necessary for troubleshooting firmware-based issues. These limitations significantly reduce the practicality of software-based telemetry / debugging solutions for many applications involving operational data, including debugging device firmware.

[0005] Some remote debugging solutions exist that are implemented at a lower level than software-based solutions (i.e., in firmware or hardware). However, these solutions typically collect a predefined set of working data, and users cannot specify the specific working data they want to collect from the target device. Therefore, if the required working data is not part of the predefined dataset collected by such debugging solutions, developers may need to use different techniques to collect the required working data. Furthermore, these solutions generally do not facilitate firmware updates to aid in troubleshooting firmware issues.

[0006] Furthermore, firmware-level debugging solutions typically assume that one or more subsystems of the target computing device are fully functional (such as a fully functional central processing unit), or require the computing device to complete at least a portion of the initialization sequence before operational data can be acquired. Therefore, these solutions cannot operate during at least a portion of the computing device's pre-boot phase. This can be a significant drawback when the purpose of the required operational data is to diagnose errors occurring early in the initialization sequence. Additionally, some of these solutions do not allow the storage of operational data for later review.

[0007] One technique for collecting operational data during the pre-boot phase of a computing device involves collecting information via external hardware that has access to the target device's operational data. However, the operational data is passively collected by the external hardware and is not controlled by the remote party. Furthermore, the system cannot target specific operational data. Instead, the external hardware collects a predefined dataset of operational data from the attached target device. Moreover, this technique does not allow remote applications to perform firmware updates required for fault diagnosis of the target system's firmware.

[0008] Therefore, a better method is needed to remotely collect hardware-independent operational data, and to allow for targeted collection and storage of operational data to facilitate firmware updates and operate throughout the pre-boot phase of the target device.

[0009] The methods described in this section are feasible methods, but not necessarily methods that have been previously conceived or implemented. Therefore, unless otherwise stated, it should not be assumed that any method described in this section conforms to the prior art solely by virtue of its inclusion in this section. Consequently, it should not be assumed that any method described in this section is fully understood, or is well-known, routine, or conventional solely by virtue of its inclusion in this section. Attached Figure Description

[0010] The embodiments are described in the accompanying drawings by way of example rather than limitation, and the same reference numerals in the drawings refer to similar elements.

[0011] Figure 1 It is a block diagram depicting an exemplary computing device.

[0012] Figure 2 A flowchart is depicted for securely acquiring and storing target working data for computing devices based on configuration information.

[0013] Figure 3 A more detailed flowchart is provided, illustrating an exemplary implementation of securely collecting and storing target operational data for a target device based on configuration information.

[0014] Figure 4 Exemplary configuration data for targeting specific work data is described.

[0015] Figure 5 A flowchart is depicted for performing active debugging by accepting firmware update information and applying the firmware update information to update the firmware of a computing device. Detailed Implementation

[0016] In the following description, numerous specific details are set forth for illustrative purposes in order to provide a thorough understanding of the described techniques. However, it will be apparent to those skilled in the art that the techniques described herein can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to avoid unnecessarily obscuring the described techniques.

[0017] Overview

[0018] The technology described herein provides a secure data logger framework that allows for the targeted collection and storage of operational data from any subsystem of a computing device. More specifically, a protocol is provided for data loggers operating in a secure execution environment to configurably collect and store both high-level and low-level operational data (including software-level data, firmware-level data, and register transfer level (RTL) data). The secure data logger framework described herein is hardware and software independent because it can be implemented in a secure execution environment on any type of hardware, where the device runs any type of software.

[0019] According to the technology described herein, a data logger collects and stores operational data from a computing device based on stored configuration data. More specifically, the configuration data indicates one or more storage locations on the device from which operational data is collected. The configuration data also includes one or more storage locations where the data logger stores the collected operational data, which may indicate on-device storage, locally accessible storage, and / or storage accessible via a network. Therefore, by adjusting the configuration data, a user can instruct the data logger to collect and store operational data according to the specific needs of a given situation.

[0020] A secure execution environment (SEU) on a computing device is used to perform sensitive operations, such as Basic Input / Output System (BIOS) updates, subsystem driver software updates, and the execution of the computing device's initialization sequence. Therefore, applications and hardware running within the SEU of the computing device have access to all subsystems of that device, and consequently, a data logger can collect data from all subsystems of the device. Furthermore, using the target device's SEU to collect and store working data ensures the secure collection of potentially sensitive working data. Moreover, because the computing device's initiation sequence is executed within the SEU, the techniques described herein can collect working data at any point during the device's pre-boot phase.

[0021] Because the data logger is implemented in a secure execution environment, it facilitates remote troubleshooting (“active debugging”) of computing devices by allowing remote firmware updates without requiring security authorization or debugging privileges on the target computing device. Specifically, after acquiring and storing working data, the data logger allows the user to push a new firmware image to the data logger over the network, which then allows the computing device’s BIOS to update using the new firmware image. Therefore, the use of a secure data logger framework allows debugging of remote systems without recreating problems in a local test environment and without requiring any physical access to the system.

[0022] Furthermore, data loggers can be used in conjunction with Debug-as-a-Service (DaaS) to collect telemetry information from specific subsystems of a computing device, which can be used to improve the performance of those subsystems. The configuration data for DaaS functionality may be specific to the target subsystem and indicate under what conditions operational data should be collected for that subsystem. Configuration-based DaaS allows hardware providers to collect operational data over time, facilitating the operation of specific hardware and / or software configurations.

[0023] Architecture

[0024] Figure 1 This is a block diagram depicting an exemplary computing device (i.e., a system-on-a-chip (SoC) 100) implementing the techniques described herein. The implementation is described herein in the context of SoC 100. However, the techniques described herein are applicable to any type of computing device, including any type of application-specific integrated circuit (ASIC). SoC 100 is an integrated circuit including an exemplary set of subsystems, which includes: a root of trust dedicated security processor 110, a central processing unit (CPU) 120, a memory 130, an input / output (I / O) subsystem 140, a persistent storage device 150, a communication interface 170, and components such as a graphics processing unit (GPU) 160 and a camera. Figure 1Peripheral subsystems (not shown in the diagram). The CPU 120 runs one or more processes (including process 122) that utilize register 124, which is different from security register 116. According to the implementation, the CPU 120 runs an OS for SoC 100.

[0025] According to the implementation scheme, one or more subsystems of the SoC 100 include one or more corresponding microcontrollers for managing the subsystems. For example... Figure 1 As depicted, microcontrollers (MCs) 110A-170A control associated subsystems of SoC 100. These microcontrollers are implemented by drivers mounted on SoC 100, where the drivers are software or firmware that controls the associated subsystems. SoC 100 may include... Figure 1 Other subsystems of the associated microcontroller not depicted in the text.

[0026] SoC 100 includes a security processor 110, distinct from CPU 120, which implements a secure or "trusted" execution environment (SEE) 112. Figure 1 In the depicted implementation, the secure execution environment is implemented by a dedicated secure processor 110 (or "root of trust" hardware). According to another implementation, the secure execution environment (e.g., SEE 112) is implemented by a processor that also implements a non-secure execution environment, wherein the secure execution environment is secured based on one or more security measures (e.g., security perimeter, encryption, authentication of software / firmware updates, etc.). The examples described herein depict SEE 112 implemented in (and used by) the dedicated secure processor 110. However, the implementations are not limited to being implemented by a dedicated secure processor and may be implemented by a processor that maintains both the secure and non-secure execution environments.

[0027] To illustrate, the CPU maintains both secure and insecure execution environments, with the CPU running the OS in the insecure execution environment. In this example, the CPU has two operating states: a secure operating state implementing SEE and an insecure operating state implementing an insecure (or "rich") execution environment.

[0028] A secure execution environment includes any process or hardware that uses secure memory and secure registers. A register is a memory location reserved for and used by one or more specific processors. Processes and hardware that are part of a secure execution environment are referred to herein as “secure actors.” Depending on the implementation, the instructions for carrying out the operations performed by the secure actors are authenticated before execution. Operations performed by secure actors within a secure execution environment on a given computing device, and the data generated by such operations, cannot be accessed or altered by any actor (process or hardware) operating outside the secure execution environment. Exemplary specific implementations of secure execution environments include the AMD Platform Security Processor (PSP), Intel Software Protection Extensions (SGX), Apple Secure Enclosure Processor (SEP), and others.

[0029] SEE 112 includes one or more security actors that utilize security register 116 and security memory 132, which may include a portion or all of memory 130. The security register and memory are secure such that only security actors have access to the data in the security register and memory, for example, because the register and / or memory are encrypted, or because the register and / or memory can only be accessed by security actors within SEE 112, etc.

[0030] Security actors operating within SEE 112 can access any operational data on SoC 100, including hardware registers and memories managed by other subsystems, such as register 124, memory 130, and ASIC hardware registers. Security actors within SEE 112 access operational data within SoC 100 based on security policies that restrict access and ensure the security of SoC 100.

[0031] Security Data Logger

[0032] The techniques described herein provide a secure data logger framework that allows for the collection and transfer of operational data for any subsystem of SoC 100. A data logger 114 implementing the techniques described herein operates within SEE 112. Therefore, the data logger 114 can be implemented by one or more security actors running on the security processor 110 using various methods that may vary depending on the specific implementation. For example, the data logger 114 can be implemented in firmware, software, and / or hardware to provide the functionality described herein. Operational data can be collected at various levels, including software level, firmware level, and register transfer level (RTL).

[0033] Because the data logger 114 is implemented within SEE 112, operational data can be collected and transmitted when the SoC 100 is in any state that allows the secure execution environment to operate, including at any point during the pre-boot phase. More specifically, when a computing device such as the SoC 100 is shut down, the subsystems of the SoC 100 (including the CPU 120) enter a reset state. The computing device can be shut down via hardware ("hard" reset) or software ("soft" reset).

[0034] Immediately after a computing device is powered on or restarted, its subsystems remain in a reset state. The computing device's hardware first causes the security processor 110 to exit the reset state, and the security processor 110 uses a security actor to run the initialization (or "boot") sequence in the BIOS. For example, the security processor 110 first loads the BIOS into secure memory 132 and authenticates the BIOS firmware instructions. The BIOS may also include firmware drivers for the SoC 100 subsystems. After authenticating the BIOS, the security processor 110 runs the authenticated BIOS firmware, which releases the individual subsystems of the SoC 100 from the reset state.

[0035] After memory 130 and CPU 120 are released from the reset state, instructions to implement the operating system software are loaded into memory 130 and CPU 120 executes the operating system software. When the operating system software is fully operational, SoC 100 is fully booted. The pre-boot phase of the computing device is the time between (a) the release of the security processor (i.e., the processor that maintains the SEE) from the reset state and (b) the time after the CPU is released from the reset state, which typically occurs after the operating system initialization. During the pre-boot phase, the device cannot run any software (except for operations coded in the BIOS).

[0036] Sometimes, a system requiring debugging may fail to complete the entire boot sequence, preventing it from exiting the pre-boot phase. For example, this could be due to performing an operating system or firmware update on a SoC 100. After the update, the SoC 100 may fail to complete the boot sequence to fully initialize the device subsystems due to one or more issues with the update. In such cases, it is important to be able to debug problems with the computing device during the pre-boot phase.

[0037] Active debugging data acquisition

[0038] Figure 2 A flowchart 200 is depicted for securely acquiring and storing target working data for computing devices based on configuration information. Figure 2The process described addresses the technical challenge of acquiring and storing working data for a computing device at any stage of the initialization sequence and at any data level. This solution utilizes a secure execution environment to run an on-demand data logger, which is also used to initialize other subsystems on the device and has access to data from all subsystems of the device.

[0039] At step 202 of flowchart 200, an interrupt event is detected. For example, data logger 114 detects an interrupt event that is one of the following: an interrupt signal caused by a subsystem of SoC 100, or an interrupt protocol initiated by security processor 110 to resolve security processor errors. An interrupt signal caused by a subsystem of SoC 100 may be initiated based on the subsystem detecting an error (as in active debugging). Such an interrupt signal is referred to herein as an "active debugging type" interrupt signal. Furthermore, an interrupt signal caused by a subsystem of SoC 100 may be initiated based on the detection of a data acquisition condition defined in subsystem-specific configuration data (as in DaaS). Such an interrupt signal is referred to herein as a "DaaS type" interrupt signal. According to an embodiment, the detection of the data acquisition condition may be performed by processor 110. In this embodiment, in response to the detection of a data acquisition condition, processor 110 initiates an interrupt protocol to initiate a secure data acquisition operation.

[0040] According to the implementation scheme, data logger 114 distinguishes between active debug interrupt signals and DaaS interrupt signals. For example, security processor 110 implements a shared interrupt line through which interrupt signals reach processor 110. In this example, the shared interrupt line is associated with a memory address or register. Regarding the data collection interrupt signal that causes the interrupt, the subsystem that causes the interrupt writes information (such as a cookie) at the associated memory address or register to indicate whether the interrupt signal is a data collection signal and / or whether the signal is a DaaS interrupt signal or an active debug interrupt signal. As another example, security processor 110 implements one or more dedicated data collection interrupt lines through which interrupt signals reach processor 110. To further illustrate, a first dedicated data collection interrupt line transmits DaaS interrupt signals to processor 110, and a second dedicated data collection interrupt line transmits active debug interrupt signals to processor 110.

[0041] Flowchart 200 is described in the context of active debugging. However, the techniques shown in flowchart 200 are also applicable to DaaS, as described in further detail below.

[0042] For active debugging, the microcontroller of any given subsystem can detect whether the associated subsystem is entering a "bad" state or a state caused by some kind of error. For example, based on the elapsed time of the watchdog timer on communication interface 170 or the system management unit detecting an error in communication interface 170, MC 170A detects that communication interface 170 has experienced an error (or entered a "bad" state). Based on the detected error, MC 170A automatically sends an interrupt signal to the security processor 110 to notify the processor that working data needs to be logged.

[0043] To further illustrate the specific implementation scheme, Figure 3 A more detailed flowchart 300 illustrates an exemplary implementation of securely acquiring and storing target operational data for a target device based on configuration information. At step 302A of flowchart 300, the microcontroller of an exemplary subsystem of SoC 100 (MC 170A of communication interface 170) sends a data acquisition type interrupt signal to the security processor 110. Although communication interface 170 is depicted as an interrupt signal source, any subsystem of SoC 100 can be an interrupt signal source according to the techniques described herein.

[0044] Furthermore, as shown at step 302B, the execution of the data logger 114 can be initiated based on an interrupt signal including the action of the security processor 110 itself. For example, the system management unit of the security processor 110 determines that the security processor 110 has entered a "bad" state and causes a self-interrupt protocol to be initiated, which is an exemplary interrupt signal originating from the security processor 110.

[0045] Configuration data

[0046] In response to the detection of an interrupt signal, the security processor 110 uses the data logger 114 in SEE 112 to perform a data acquisition operation, which includes steps 204-206 of flowchart 200. Specifically, at step 204, data is acquired from one or more data collection locations based on configuration data. According to the implementation, one or more data collection locations are identified based on the configuration data, wherein the one or more data collection locations include one or more of hardware registers or memory locations. For example, the security processor 110 initiates the data logger 114 in response to receiving an interrupt signal from MC 170A. Upon initiation, the data logger 114 automatically initiates the data acquisition operation.

[0047] To illustrate within the context of flowchart 300, at step 304, based on the exemplary interrupt signal from MC 170A being of the "data acquisition" type, security processor 110 automatically initiates data logger 114 ("DR"), for example, by loading and executing instructions for data logger 114. Furthermore, at step 306, security processor 110 halts the execution of any thread currently being executed by security processor 110. Step 306 may be executed by security processor 110 in response to the detection of an interrupt signal, or it may be executed by data logger 114 after it has been initiated.

[0048] At step 308, data logger 114 reads configuration data 136. According to one embodiment, data logger 114 reads configuration data 136 from a known location. According to another embodiment, information at a memory location or register associated with an active debug interrupt signal (i.e., caused by the subsystem entering a "bad" state) can identify the location of the configuration data to be used for data acquisition operations. If the information associated with the interrupt signal does not identify the location of the configuration data to be used for data acquisition operations, data logger 114 reads configuration data 136 from a default location.

[0049] According to the implementation scheme, the default location of configuration data 136 is in the BIOS, which has been loaded into secure storage 132. According to the implementation scheme, configuration data 136 is encrypted data (e.g., signed binary data) and can be a configuration file originally included in the BIOS, or it can be a file included in a BIOS update from a developer debugging the system. However, the default location of configuration data 136 can be in any storage device accessible to security actors of SEE 112.

[0050] According to the implementation scheme, when the data logger 114 accesses configuration data 136, which is stored as binary data, the data logger 114 verifies the signature of the binary data and then decrypts the data. The decrypted content is copied to secure memory 132. According to the implementation scheme, the binary file format of configuration data 136 is generated by a security tool, for example, running by secure processor 110, using a script that processes input and field verification. Configuration data 136 acts as input, which is used by one or more instructions executed on secure processor 110. According to the implementation scheme, when data is loaded by data logger 114 into, for example, a serial peripheral interface (SPI)-ROM, secure processor 110 verifies configuration data 136.

[0051] Configuration data 136 instructs the data logger 114 to collect operational data from one or more locations, which may be on the SoC 100 or on a different machine accessible to the security processor 110. Configuration data 136 may be in any format, including user-readable file formats such as XML.

[0052] Based on configuration data 136, data logger 114 identifies target data locations from which it acquires operational data for a given data acquisition operation. According to embodiments, one or more target data locations include the location or identifier of one or more hardware registers and / or one or more memory locations. Memory locations may specify locations within secure or insecure memory accessible to data logger 114. Hardware registers may be registers used by the processor on SoC 100 (such as one of secure registers 116 and 124), or they may be registers that are part of an integrated circuit (such as an ASIC) and hold RTL-level data. Specifically, the hardware circuitry includes registers for sequential logic and combinational logic implemented in hardware. RTL data includes flowing signals caused by the operation of the hardware circuitry, recorded at hardware registers. RTL data is not accessible by software, meaning that this level of data cannot be obtained via software-implemented debugging techniques.

[0053] Configuration data 136 is used to pass input to data logger 114, allowing the logger to know what data needs to be captured. This input can be formatted and then parsed by data logger 114 in various ways. The working data to be acquired, identified in configuration data 136, can be generic or specific to an interrupt signal source. For example, configuration data 136 identifies the locations of working data to be recorded, regardless of the interrupt signal source. The locations of the working data can originate from one or more subsystems of SoC 100. In this example, data logger 114 acquires working data at all locations identified in configuration data 136. As another example, configuration data 136 identifies the locations of one or more subsystem-specific working datasets to be recorded. In this example, data logger 114 acquires working data at the set of data locations in configuration data 136 associated with the subsystem that generated the interrupt signal.

[0054] To illustrate, Figure 4 Exemplary configuration data 136 is depicted, indicating both data recorded regardless of the interrupt signal source and subsystem-specific data. Figure 4 The structure of configuration data 136 in the example is exemplary, and configuration data 136 can be constructed in different ways depending on the specific implementation. Figure 4In the example, configuration information 136 includes multiple sections: a main table section 400, a sub-table section 410, and target storage location information 420. According to one implementation, when a data acquisition operation is initiated, data logger 114 acquires all working data identified in the main table 400 and sub-table 410 of the configuration data 136. According to another implementation, for example, based on one or more sub-tables associated with a data collection interruption signal source, data logger 114 always acquires working information identified in the main table 400, and then acquires working information identified in one or more sub-tables (of sub-table 410).

[0055] exist Figure 4 In the exemplary configuration data 136, the main table section 400 indicates data recorded without considering the source subsystem of the interrupt signal. In this example, the main table section 400 includes the following fields, which are used as indicated according to the implementation scheme:

[0056] • The ASIC serial number, which will be used as a seed (parameter) in the key derivation function to derive a SoC 100-specific package key.

[0057] • The encapsulated encryption key, which is used to encrypt the binary content of the configuration data. The encapsulated encryption key is unpacked using the key derived from the key derivation function.

[0058] • The packaged signing key, which is used to verify the presence of a signature in the configuration data. The packaged signing key is unpacked using the key derived from the key derivation function.

[0059] A unique identifier field is included, which is updated with a random value when generating configuration data binary. This unique identifier value is included in the data collected by data logger 114. Users use this unique identifier to access working data collected by data logger 114, for example, from network storage devices.

[0060] • Table version, which is a version number associated with the format of the main table 400. Based on this number, the data logger 114 is able to interpret the main table 400.

[0061] • The number of IPs and the total size are numbers that help in resolving sub-table 410.

[0062] In this exemplary configuration data, subtable section 410 includes subsystem-specific subtables 412 and 414. The subtables in subtable section 410 include subsystem-specific details that identify the data acquisition location of a subsystem. Generally, a subtable contains details of the specific subsystem whose data needs to be acquired. Therefore, if data from multiple subsystems needs to be acquired, multiple subtables will exist. For example, the working information identified in subtable 410 (or main table 400) in configuration information 136 may reside in one or more of the following: CPU registers, general-purpose shared registers, I / O memory, DRAM / SRAM memory, or graphics / video memory, etc. Each subtable may have one or more fields indicating the different types of data to be acquired. For example, data may come from CPU registers or general-purpose shared registers, or from I / O memory, DRAM / SRAM memory, or graphics / video memory. Figure 4 In this context, SMN corresponds to the I / O memory, and the CRU register is a general-purpose register.

[0063] Data collection and storage

[0064] As indicated above, at step 204 of flowchart 200, data is acquired from one or more data collection locations based on configuration data. For example, as shown in step 310 of flowchart 300, data logger 114 reads data from data locations identified according to configuration data 136. For example, data logger 114 determines that none of the subtables in subtable section 410 of configuration data 136 are specific to communication interface 170. Therefore, data logger 114 acquires operational information from a set of locations on SoC 100 identified in main table section 400 of configuration information.

[0065] At step 206 of flowchart 200, the acquired data is stored at one or more target storage locations. For example, data logger 114 stores the acquired working data in secure storage 132 based on one or more target storage locations identified in configuration data 136. Each of the one or more target storage locations identifies one of the following: on-device storage, locally accessible storage, and / or network-accessible storage. For example, Figure 4 The exemplary configuration data 136 and the target storage location data 420 indicate one or more target storage locations for a given data acquisition operation.

[0066] To further illustrate, at step 312 of flowchart 300, data logger 114 generates a unique identifier for the collected work data, for example, based on the hash of the collected work data. At step 314, a header including the unique identifier is also generated for the collected work data.

[0067] At step 316, the collected work data is encrypted. For example, security processor 110 encrypts the collected work data and headers based on encryption information in the main table section 400 of configuration data 136. As another example, the headers are not encrypted, and the unencrypted headers are stored together with the encrypted work data.

[0068] At step 318, the encrypted data is saved to one or more of a local / external storage device, an on-chip storage device, or a network-based storage device, as indicated by the target storage location data 420. Step 320 describes, for example, a decision on the location to store the acquired working data based on configuration data 136.

[0069] Some ASICs have on-chip storage devices accessible via a root-trust hardware. For example, based on configuration data 136, data logger 114 stores the collected data in secure memory 132, which is a storage device on the SoC 100. As another example, data logger 114 stores the collected data as encrypted data in a dedicated, encrypted partition of storage device 150. Similarly, based on configuration data 136, data logger 114 can store the collected working data at storage device 186, which is, for example, a flash drive communicatively connected to the SoC 100 via a USB port.

[0070] The configuration file can indicate that the collected working data should be stored at a remote storage device 184 accessible via network 182. To store data over network 182, data logger 114 establishes a secure connection to storage device 184. According to the implementation, the target storage location information identifying storage device 184 includes data required to connect to the network location of storage device 184. This secure connection can be established during the pre-boot phase of the computing device (provided that communication interface 170 has been initialized during the boot sequence), because the firmware of security processor 110 is configured to establish a secure network connection without requiring operating system functionality. Once the connection is established, it is used to securely transfer data to storage device 184.

[0071] At step 322, the firmware state is updated. For example, the security processor 110 includes a status register that is updated to a first predetermined value indicating that data acquisition has been initiated when data logging 114 is initiated at step 304. Upon completion of storing the acquired working data based on instructions from configuration data 136, the status register of the security processor 110 is again updated to indicate that data acquisition is complete. The updated value of the status register can be any predetermined value other than the first predetermined value to indicate the completion of the data acquisition operation.

[0072] Users can retrieve desired data by providing the ASIC serial number and a unique identifier to the collected working data, which is included in configuration data 136 as described above. For network-based storage, date and time information serve as additional parameters to distinguish the data. According to the implementation scheme, post-processing can only be performed by authorized users, and only if the captured data has not been tampered with.

[0073] Active debugging

[0074] According to the implementation scheme, after collecting and storing working data for a given data acquisition operation, the data logger 114 awaits input including a new firmware image. According to the implementation scheme, the data logger 114 only accepts new firmware input that corresponds to certain types of interrupt signals associated with active debugging. Information associated with the interrupt signals can be used to distinguish such interrupt signals from DaaS-based interrupt signals, which are described in further detail below. For example, configuration data 136 includes a Boolean field indicating whether a firmware update is expected. This field is set to true by default.

[0075] The data logger 114 (which awaits input including a new firmware image) allows developers to push new firmware images to the data logger 114, which enables the security processor to apply the new firmware image to the SoC 100. Figure 5 A flowchart 500 is depicted for performing active debugging by receiving firmware update information and applying the firmware update information to update the firmware of a computing device.

[0076] At step 502, the working data is analyzed. For illustration, the SoC 100 experiences an error at communication interface 170 and acquires working data as described above in conjunction with flowcharts 200 and 300. Based on the data in configuration data 136 indicating that the acquired working data should be stored in storage device 150 (on-chip), data logger 114 uses the determined header to store the acquired working data in storage device 150. The developer identifies the data in storage device 150 based on the unique identifier recorded in configuration data 136.

[0077] Developers analyze the retrieved working data. For example, one or more post-processing tools can be used to convert the collected working data into debugger-readable data. Specifically, configuration data 136 identifies the dataset that can be used to reproduce the crash scene, and developers input the collected working data into the post-processing tool that generates the reproduction.

[0078] At step 504 of flowchart 500, the developer formulates a solution based on working data collected from the device. For example, based on the working data, the developer formulates one or more of the following: a firmware update that resolves the problem, and / or additional working datasets that will further aid in debugging the problem. To illustrate, the developer determines that (a) a specific change to the firmware of SoC 100 can fix the problem, and (b) if the fix is ​​unsuccessful, information from specific registers of SoC 100 and data from specific memory regions in memory 130 will help debug SoC 100.

[0079] At step 506, the developer constructs a new firmware image. For example, the developer encodes both specific changes to the firmware and new configuration data 136 in the new firmware image of SoC 100, which fixes the problem identified in step 504, and the new configuration data indicates the location of the registers identified in SoC 100 and the memory region identified in memory 130.

[0080] According to the implementation scheme, new firmware information can be received by the data logger 114 via a network or via a local connection. Therefore, at step 508, the developer determines which deployment method to use to push the firmware image to the data logger 114, depending on whether the developer has local access to the device. If the developer is local to the SoC 100, then at step 512, the developer deploys the new firmware image locally, for example, via a storage device 186, which is communicatively coupled to the SoC 100, for example, via a USB port.

[0081] If the developer is away from the SoC 100, then at step 510, a network packet with the new firmware image is prepared and sent via network 182. According to the implementation, the network packet is sent from the client device to the SoC 100 via a secure network connection on network 182.

[0082] According to the implementation scheme, the new firmware image sent via network 182 is stored in a temporary location within SoC 100 (e.g., secure memory 132) for authentication. For example, the security processor 110 checks the type of the new firmware image, where the type indicates what subsystem the firmware is designed to run (e.g., power management firmware, security firmware, video firmware, etc.). If the existing firmware is corrupted, or if the new firmware is smaller than or equal to the size of the existing firmware, the new firmware is installed onto SoC 100. Otherwise, the security processor 110 throws an error, and a new firmware image must be created for another attempt to update the firmware.

[0083] At step 514, data logger 114 updates the BIOS based on the new firmware image. This update places the new configuration data 136 prepared by the developer and potential fixes for the issue in place. At step 516, security processor 110 reboots SoC 100, which can be a cold boot or a warm reset. The device reboot completes the installation of the new firmware, as the newly updated firmware image is loaded when SoC 100 boots.

[0084] After the reboot, at step 518, if the new firmware does not fix all the problems, then at step 520, one or more remaining problems cause the security processor 110 to execute the data logger 114 again, as shown in flowchart 300. Figure 3 The process is illustrated in steps 302-304. Subsequent working data collected by data logger 114 will be based on the new configuration data in the firmware image. However, if all issues are resolved after installing the new firmware, the process ends at step 522.

[0085] Debug as a Service

[0086] Acquiring telemetry information from specific subsystems of a device over time can be extremely useful, as this information can be used to improve the performance of those subsystems. For example, some graphics drivers provide high-end graphics capabilities for certain systems, such as 3D graphics systems, computer-aided design systems, and gaming systems. Performance improvements to such drivers offer practical and business benefits to both clients and hardware providers.

[0087] Using the configuration-based data acquisition technology described herein, DaaS allows hardware providers to acquire data for specific configurations and / or specific software configurations. Data collected using DaaS technology can be sent to specific network-based storage devices and processed as a large data database, where analysis is performed to identify updates to be made on various device subsystems, such as graphics drivers for specific GPU versions.

[0088] For DaaS, data logger 114 is initiated in the absence of subsystem errors. Specifically, the microcontroller of the subsystem implementing DaaS is associated with subsystem-specific configuration data that defines what data the subsystem will capture and when to initiate the execution of data logger 114. Subsystem-specific configuration data allows developers to initiate data acquisition on demand at any time. According to the implementation, the subsystem-specific profile is stored in the production stack of the corresponding microcontroller controlling the subsystem. For example, a profile included in the production stack of the video driver for GPU 160 indicates that the acquired working data should include the load on GPU 160, as well as the GPU 160's voltage, FW version, frame buffer, performance counters, etc.

[0089] Subsystem-specific profiles can be specific to the device's hardware configuration and / or use cases. For example, a particular subsystem may be associated with multiple profiles, which are associated with use case identifiers. Based on the use case information for a given device, one profile is selected as the active profile.

[0090] According to the implementation scheme, the microcontroller of the DaaS-implementing subsystem causes information identifying specific types of operational data to be collected from a specific configuration file of the subsystem and appended as a subtable to configuration data 136. In this implementation scheme, when an interrupt event caused by a subsystem of SoC 100 (which may be any subsystem including security processor 110) is detected, data logger 114 will collect subsystem-specific information from the subtable.

[0091] As described above, the subsystem-specific profile also indicates under what conditions a data acquisition interrupt signal should be sent to the security processor 110. At startup, the subsystem's microcontroller determines the conditions that should trigger a data acquisition operation based on the subsystem-specific profile in the production stack. For example, the profile associated with GPU 160 indicates that the data logger 114 should acquire subsystem-specific performance data when the load on GPU 160 exceeds a predefined threshold. The microcontroller sets up a listener procedure to detect when one or more of the indicated conditions are true. When the listener detects a data acquisition condition, it sends a data acquisition interrupt signal to the security processor 110.

[0092] DaaS-type interrupt signals are distinguished from active debug interrupt signals in at least one of the aforementioned ways. For example, configuration data 136 includes a Boolean field indicating whether a firmware update is expected. This field is set to false before the DaaS-type interrupt signal is sent to security processor 110. In embodiments where the information associated with the interrupt signal includes location information of a subsystem-specific profile, data logger 114 reads a profile specific to the interrupt signal source instead of using configuration data 136. In embodiments that distinguish interrupt signals as DaaS in another way, data logger 114 uses a subsystem-specific subtable appended to configuration data 136 to collect subsystem-specific operational data.

[0093] Hardware Overview

[0094] According to one embodiment, the techniques described herein are implemented by one or more dedicated computing devices. The dedicated computing devices may be hardwired to execute these techniques, or may include digital electronic devices (such as one or more application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs) that are continuously programmed to execute these techniques, or may include one or more general-purpose hardware processors programmed to execute these techniques according to program instructions in firmware, memory, other storage devices, or combinations thereof. Such dedicated computing devices may also combine custom hardwired logic, ASICs, or FPGAs with custom programming to implement these techniques. The dedicated computing device can be any computing device, such as a SoC or other computing system, that combines hardwired logic and / or program logic to implement these techniques.

[0095] As indicated above, Figure 1 This is an exemplary block diagram illustrating a SoC 100 on which implementation schemes can be carried out. The SoC 100 includes an I / O subsystem (“bus”) 140 or other communication mechanisms for transmitting information, and a hardware processor CPU 120 coupled to the bus 140 for processing information. Figure 1 In the example, CPU 120 is a general-purpose microprocessor.

[0096] SoC 100 also includes memory 130 (such as random access memory (RAM) or other dynamic storage devices) coupled to bus 140 for storing information and instructions to be executed by processors on SoC 100 (such as CPU 120, security processor 110, GPU 160, etc.). Memory 130 can also be used to store temporary variables or other intermediate information during instruction execution by the processor on SoC 100. When stored in non-transitory storage media accessible to CPU 120, such instructions make SoC 100 a dedicated machine customized to perform the operations specified in the instructions. Storage device 150 (such as a disk, optical disk, or solid-state drive) is provided and coupled to bus 140 for storing information and instructions. SoC 100 may also include read-only memory (ROM). Figure 1 (not depicted) or other static storage devices coupled to bus 140 for storing static information and instructions for one or more processors on SoC 100.

[0097] SoC 100 can implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic. This custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic, combined with a computer system, enables SoC 100 to be a dedicated machine or to be programmed as such. According to one embodiment, SoC 100 performs the techniques described herein in response to CPU 120 executing one or more sequences of one or more instructions contained in memory 130. Such instructions may be read into memory 130 from another storage medium, such as storage device 150. Execution of the sequence of instructions contained in memory 130 causes CPU 120 to perform the process steps described herein. In an alternative embodiment, hardwired circuitry may be used in place of or in combination with software instructions. Figure 1 In addition, the SoC 100 is also coupled via bus 140 to an external, locally accessible storage device 186, which includes storage media.

[0098] As used herein, the term "storage medium" refers to any non-transitory medium that stores data and / or instructions that enable a machine to operate in a particular manner. Such storage media may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical discs, magnetic disks, or solid-state drives (such as storage device 150). Volatile media include dynamic memory (such as memory 130). Common forms of storage media include, for example, hard disks, solid-state drives, magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or cartridges.

[0099] Storage media differ from transmission media, but can be used in conjunction with transmission media. Transmission media participate in the transfer of information between storage media. For example, transmission media include coaxial cables, copper wires, and optical fibers, including the wires forming bus 140. Transmission media can also take the form of sound waves or light waves, such as those generated during radio wave and infrared data communication.

[0100] Various forms of media may be involved when carrying one or more sequences of one or more instructions to the CPU 120 for execution. For example, the instructions may initially be carried on a disk or solid-state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and send the instructions over a network. The communication interface 170 of the SoC 100 may receive data from the network, and appropriate circuitry may place the data on bus 140. Bus 140 carries the data to memory 130, from which the CPU 120 retrieves and executes the instructions. The instructions received by memory 130 may optionally be stored on storage device 150 before or after execution by the CPU 120.

[0101] The communication interface 170 of the SoC 100 is coupled to the bus 140 and provides bidirectional data communication coupling to a network link 180 connected to a local network 182. For example, the communication interface 170 may be a local area network (LAN) card to provide data communication connectivity to a compatible LAN. A wireless link may also be implemented. In any such implementation, the communication interface 170 transmits and receives electrical, electromagnetic, or optical signals carrying digital data streams representing various types of information.

[0102] Network link 180 typically provides data communication to other data devices via one or more networks. For example, network link 180 may provide a connection to storage device 184 via network 182. Network 182 uses electrical, electromagnetic, or optical signals carrying digital data streams. Signals through various networks, as well as signals on network link 180 and through communication interface 170 (which carry digital data to and from SoC 100), are exemplary forms of transmission media.

[0103] SoC 100 can send messages and receive data, including program code, via a network, network link 180, and communication interface 170. For example, an external computing device ( Figure 1 (Not depicted) Firmware updates for the security processor 110 can be transmitted to the SoC 100 via network 182 and communication interface 170. The received code can be executed by the SoC 100 upon receipt and / or stored in storage device 150 or other non-volatile memory for later execution.

Claims

1. A computer-executable method, comprising: The application firmware update information indicates: a) one or more data collection locations, including at least one data collection location in the security registers and random access memory (RAM) of the hardware processor, and b) one or more target storage locations; In response to an interrupt event, the processor of the computing device uses a secure execution environment to perform a data acquisition operation, which includes: Data is collected from one or more data collection locations, including the security register in the hardware processor and at least one data collection location in the random access memory; as well as The collected data is stored at one or more target storage locations.

2. The computer-executable method of claim 1, wherein the interrupt event is associated with information that associates the interrupt event with the data acquisition operation.

3. The computer-executable method of claim 1, further comprising detecting the interrupt event by the processor during the pre-boot phase of the computing device.

4. The computer-executable method according to claim 1, wherein Target storage location identifier in the one or more target storage locations Storage devices accessible via a network.

5. The computer-executable method according to claim 1, further comprising: The interrupt event is detected by the processor while the processor is executing one or more threads; and In response to the detection of the interruption event, the execution of the one or more threads is stopped.

6. The computer-executable method of claim 1, wherein the RAM is a video memory.

7. The computer-executable method according to claim 1, wherein: The interruption event is associated with the location of the configuration data in the production stack of a specific subsystem of the computing device; The one or more data collection locations are associated with the specific subsystem; and The method also includes retrieving the configuration data from the location.

8. The computer-executable method of claim 1 further includes generating a unique identifier for the collected data, wherein the collected data is stored in conjunction with the unique identifier.

9. The computer-executable method of claim 1, wherein the basic input / output system (BIOS) update includes the firmware update information indicating the one or more data collection locations and the one or more target storage locations.

10. The computer-executable method according to claim 1, wherein: The computing device is an integrated circuit; The processor is a dedicated security processor on the integrated circuit; and The interrupt event is associated with the microprocessor of the subsystem on the integrated circuit.

11. The computer-executable method of claim 1, wherein the data collection locations of the one or more data collection locations are encrypted.

12. A computing system, comprising: One or more processors; and A memory that stores one or more instruction sequences, which, when executed by the one or more processors, cause the execution of the method according to any one of claims 1 to 11.

13. A computer program product comprising instructions that, when executed by one or more processors, cause the execution of the method of any one of claims 1 to 11.

Images