Secure collection and communication of computing device work data.

Abstract

The technology described herein provides a secure data recorder that enables targeted collection and storage of both high-level and low-level operational data from any subsystem of a computing device. The data recorder collects and stores device operational data based on stored configuration data. The configuration data indicates one or more memory and / or storage locations on the device from which the operational data is collected, as well as one or more storage locations to which the data recorder stores the collected operational data. The data recorder is implemented in a secure execution environment and functions during all pre-boot stages of the device. The data recorder allows a user to update the BIOS of a computing device, for example, based on a firmware image provided over a network. The data recorder facilitates operational data collection over time and lends itself to the functioning of a particular hardware and / or software configuration.

Description

Background Art

[0001] During operation of a computing device, the device generates and stores many types of work data, including data stored in persistent storage, memory, hardware registers, and the like. For example, collecting work data of a computing device for the purpose of device troubleshooting can be a difficult problem. This is particularly true when low-level work data is required, such as work data at the firmware level or hardware level (e.g., register transfer level). Accessing a device's work data using physical access to the device itself is the most effective approach. However, traveling to the site of a target computing device can be expensive and / or difficult, especially when the device's work data is required by an unrelated third party, such as a manufacturer / vendor of a part of the system or a third party hired to troubleshoot the system.

[0002] Debugging tools used to collect low-level work data during device development (such as the Joint Test Access Group (JTAG) interface) are generally disabled or removed in the device production stack, and thus are not available in deployed systems. A developer may remotely access low-level work data of a device in a remote computing system based on knowledge of the remote system's "signing key" infrastructure or if the system has an unlocked debug port. However, enabling this type of access to a computing system introduces significant security vulnerabilities, and therefore not all clients will provide the necessary rights to remotely access device work data.

[0003] For the purpose of remote troubleshooting, developers may attempt to reproduce problems experienced on a remote computing device on their local system. However, setting up such a test system environment requires a considerable amount of time and engineering effort to faithfully reproduce the specific problem of the target device, especially if the problem is unique to the original equipment manufacturer (OEM) board.

[0004] Furthermore, several telemetry / debugging solutions exist that depend on the deployed system running a specific operating system (OS) or application. These software-based solutions can collect working data specific to the required OS or application from a remote system, but generally cannot collect low-level data. Moreover, software-based solutions can only collect working data once the software is running on the device, i.e., after the OS has started via the device's reboot-after startup sequence. Therefore, software-based solutions cannot collect data during the pre-boot phase of the computing device. Additionally, software-based solutions do not facilitate firmware updates required for firmware-based troubleshooting. Such limitations significantly reduce the usefulness of software-based telemetry / debugging solutions for many applications involving working data, including device firmware.

[0005] There are several remote debugging solutions implemented at a lower level than software-based solutions, namely in firmware or hardware. However, these solutions generally collect a predefined set of working data, and the user cannot specify a particular desired point in the working data to be collected from the target device. Therefore, if the required working data is not part of the predefined dataset collected by such a debugging solution, the developer may need to use a different technique to collect the required working data. Also, these solutions generally cannot facilitate firmware updates to help troubleshoot firmware issues.

[0006] Furthermore, debugging solutions implemented at the firmware level generally assume that one or more subsystems of the target computing device are fully functional (e.g., a fully functional central processing unit), or require the computing device to complete at least part of its initialization sequence before it can collect working data for the device. Therefore, these solutions cannot function during at least part of the pre-boot stage of the computing device. This can be a significant drawback when the purpose of the required working data is to troubleshoot errors that occur early in the initialization sequence. Also, some such solutions do not allow for the storage of working data for later review.

[0007] One technique for collecting working data during the pre-boot phase of a computing device is to collect information via external hardware that has access to the working data of the target device. However, the working data is collected passively by the external hardware and is not controllable by remote parties. Furthermore, this system cannot target specific working data. Instead, the external hardware collects a predefined set of working data from the attached target device. Also, this technique does not enable the remote application of firmware updates required to troubleshoot the firmware of the target system.

[0008] Therefore, there is a need for a better method for remote work data collection that is hardware-independent, enables targeted collection and storage of work data, facilitates the application of firmware updates, and functions throughout the entire pre-boot phase of the target device.

[0009] The approaches described in this section are feasible approaches, but not necessarily approaches that have been previously conceived or performed. Therefore, unless otherwise indicated, none of the approaches described in this section should be assumed to qualify as prior art simply by their inclusion in this section. Furthermore, none of the approaches described in this section should be assumed to be well understood, commonplace, or conventional simply by their inclusion in this section.

[0010] Embodiments are shown in the accompanying drawings as examples, not as limitations, and similar reference numerals refer to similar elements. [Brief explanation of the drawing]

[0011] [Figure 1] This is a block diagram illustrating an exemplary computing device. [Figure 2]This is a flowchart for securely collecting and storing targeted work data for computing devices based on configuration information. [Figure 3] This is a more detailed flowchart for an exemplary implementation of securely collecting and storing targeted work data for a target device based on configuration information. [Figure 4] This figure shows exemplary configuration data for targeting specific work data. [Figure 5] This is a flowchart for performing active debugging by accepting firmware update information and applying it to update the firmware of a computing device. [Modes for carrying out the invention]

[0012] In the following description, many specific details are included for the purpose of explanation and to provide a full understanding of the technology described. However, it will be apparent to those skilled in the art that the technology described herein can be carried out without these specific details. In other examples, well-known structures and devices are shown in block diagrams to avoid unnecessarily obscuring the technology described herein.

[0013] (overview) The technology described herein provides a secure data recorder that enables targeted collection and storage of work data from any subsystem of a computing device. More specifically, a protocol is provided for a data recorder operating within a secure execution environment to configurably collect and store both high-level and low-level work data (including software-level, firmware-level, and Register-Transfer Level (RTL) data). The secure data recorder framework described herein is hardware-independent and software-independent in that the framework can be implemented within a secure execution environment on any type of hardware on which the device runs any type of software.

[0014] A data recorder according to the technology described herein collects and stores work data from a computing device based on stored configuration data. More specifically, the configuration data indicates one or more memories and / or storage locations on the device from which the work data is collected. The configuration data further includes one or more storage locations where the data recorder stores the collected work data, and the storage locations may indicate on-device storage, locally accessible storage, and / or network-accessible storage. Thus, by adjusting the configuration data, a user can instruct the data recorder to collect and store work data according to the specific needs of a given situation.

[0015] A secure execution environment on a computing device is used to perform sensitive operations such as updating the Basic Input / Output System (BIOS), updating subsystem driver software, and executing the computing device's initialization sequence. Therefore, applications and hardware running within the computing device's secure execution environment have access to all subsystems of the device, and thus, a data recorder can collect data from all subsystems of the device. Furthermore, by collecting and storing work data using the target device's secure execution environment, the secure collection of potentially sensitive work data is ensured. Also, since the computing device's startup sequence is performed within the secure execution environment, the techniques described herein can collect work data at any point during the pre-boot phase of the device.

[0016] Because the data recorder is implemented in a secure execution environment, it can facilitate remote troubleshooting (active debugging) of computing devices by enabling the remote application of firmware updates without requiring security authorization or debugging privileges on the target computing device. Specifically, after collecting and storing working data, the data recorder can allow users to push a new firmware image to the data recorder over a network, thereby updating the computing device's BIOS with the new firmware image. Therefore, the use of a secure data recorder framework enables debugging of remote systems without requiring the reproduction of problems in a local test environment and without any physical access to the system.

[0017] Furthermore, the data recorder may be used in connection with Debug as a Service (DaaS) to collect telemetry information from specific subsystems of a computing device, and the telemetry information may be used to improve the performance of the subsystem. Configuration data for DaaS functionality may be specific to the target subsystem and indicate the circumstances under which work data is collected for the target subsystem. Configuration data-based DaaS enables hardware providers to collect work data over time and is useful for functionality of specific hardware and / or software configurations.

[0018] (architecture) Figure 1 is a block diagram showing an exemplary computing device implementing the technology described herein, namely a System on a Chip (SoC) 100. Embodiments are described herein in the context of SoC 100. Nevertheless, the technology described herein is applicable to any type of computing device, including any type of application-specific integrated circuit (ASIC). SoC 100 is an integrated circuit comprising an exemplary set of subsystems including a root-of-trust dedicated security processor 110, a central processing unit (CPU) 120, memory 130, an input / output (I / O) subsystem 140, a persistent storage device 150, a communication interface 170, and peripheral subsystems such as a graphics processing unit (GPU) 160 and a camera (not shown in Figure 1). The CPU 120 executes one or more processes, including a process 122 that utilizes a register 124 different from the secure register 116. According to one embodiment, the CPU 120 runs an OS for SoC 100.

[0019] According to one embodiment, one or more subsystems of the SoC100 include one or more microcontrollers, each managing the subsystem. As shown in Figure 1, microcontrollers (MC) 110A to 170A each control the relevant subsystems of the SoC100. These microcontrollers are implemented by drivers installed on the SoC100, and the drivers are software or firmware that controls the relevant subsystems. The SoC100 may also include other subsystems having relevant microcontrollers not shown in Figure 1.

[0020] The SoC100 includes a security processor 110 separate from the CPU 120 that implements a secure or "trusted" execution environment (SEE) 112. In the embodiment shown in Figure 1, the secure execution environment is implemented by a dedicated security processor 110 (or "root of trust" hardware). According to another embodiment, the secure execution environment (e.g., SEE 112) is implemented by a processor that also implements an insecure execution environment, and the secure execution environment is ensured to be secure based on one or more security measures such as a security perimeter, encryption, and authentication of software / firmware updates. The examples herein illustrate that SEE 112 is implemented in (and used by) a dedicated security processor 110. However, embodiments are not limited to implementation by a dedicated security processor and may be implemented by a processor that maintains both secure and insecure execution environments.

[0021] For example, the CPU maintains both a secure and an insecure execution environment, and the CPU runs the OS within the insecure execution environment. In this example, the CPU has two execution states: a secure execution state in which SEE is implemented, and an insecure execution state in which an insecure (or "rich") execution environment is implemented.

[0022] A secure execution environment includes any process or hardware that uses secure memory and secure registers. Registers are memory locations 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.” According to one embodiment, instructions that perform actions performed by secure actors are authenticated before the actions are performed. No actor (process or hardware) operating outside the secure execution environment can access or modify actions performed by secure actors within a secure execution environment on a given computing device, or data generated by such actions. Exemplary embodiments of a secure execution environment include the AMD Platform Security Processor (PSP), Intel Software Guard Extensions (SGX), Apple Secure Enclave Processor (SEP), and the like.

[0023] SEE112 includes one or more secure actors that utilize secure registers 116 and secure memory 132, the secure memory 132 may include part or all of memory 130. The secure registers and memory are protected so that only secure actors can access the data in the secure registers and memory, for example, by encrypting the registers and / or memory, or by making the registers and / or memory accessible only by secure actors from within SEE112.

[0024] A secure actor operating within SEE 112 can access any work data on SoC 100, including hardware registers and memory managed by other subsystems, such as register 124, memory 130, and ASIC hardware registers. The secure actor within SEE 112 accesses work data in SoC 100 based on a security policy that restricts access within SoC 100 and guarantees security.

[0025] (Secure Data Recorder) The technology described in this specification provides a secure data recorder framework that enables collection and transmission of work data for any subsystem of SoC 100. A data recorder 114 implementing the technology described in this specification operates within SEE 112. Accordingly, data recorder 114 may be implemented by one or more secure actors running on security processor 110 using various approaches that may differ depending on the implementation. For example, data recorder 114 may be implemented in firmware, software, and / or hardware to provide the functionality described herein. Work data may be collected at various levels including software level, firmware level, and register transfer level (RTL).

[0026] Since data recorder 114 is implemented within SEE 112, work data may be collected and transmitted while SoC 100 is in any state that enables functionality of a secure execution environment, including any point in the pre-boot stage. More specifically, when a computing device such as SoC 100 shuts down, subsystems of SoC 100 including CPU 120 enter a reset state. The computing device may be shut down via hardware (a "hard" reset) or via software (a "soft" reset).

[0027] Immediately after the computing device is booted or rebooted, the subsystems of the computing device are still in a reset state. The computing device hardware first removes the security processor 110 from the reset state, and the security processor 110 uses a secure actor to execute the initialization (or "boot") sequence in the BIOS. For example, the security processor 110 first ensures that the BIOS is loaded into secure memory 132 and authenticates the BIOS firmware instructions. The BIOS may also contain firmware drivers for the SoC100 subsystems. After authenticating the BIOS, the security processor 110 executes the authenticated BIOS firmware, which frees the various subsystems of the SoC100 from the reset state.

[0028] After memory 130 and CPU 120 are released from the reset state, instructions for implementing the operating system software are loaded into memory 130, and CPU 120 executes the operating system software. SoC 100 is fully booted up when the operating system software is fully functional. The pre-boot phase of a computing device is the time between (a) when the security processor (i.e., the processor that maintains SEE) is released from the reset state and (b) when the CPU reaches an idle state after being released from the reset state, which usually occurs after the initialization of the operating system. During the pre-boot phase, no software (other than the operations encoded in the BIOS) can be executed by the device.

[0029] Sometimes, systems requiring debugging cannot be executed throughout the entire boot sequence, preventing the system from exiting the pre-boot phase. For example, an operating system or firmware update is performed on the SoC100. After the update, one or more issues related to the update prevent the SoC100 from completing the boot sequence to fully initialize the device subsystem. In such cases, it is crucial to be able to debug the computing device issues during the pre-boot phase.

[0030] (Data collection for active debugging) Figure 2 shows a flowchart 200 for securely collecting and storing targeted work data for a computing device based on configuration information. The process shown in Figure 2 addresses the technical problem of how to collect and store work data for a computing device at any stage of the initialization sequence and at any data level. The technical solution utilizes a secure execution environment, which is also used to initialize other subsystems on the device and has access to data for all subsystems of the device in order to run an on-demand started data recorder.

[0031] In step 202 of flowchart 200, an interrupt event is detected. For example, the data recorder 114 detects an interrupt event which is either an interrupt signal triggered by a subsystem of the SoC 100, or one of the interrupt protocols initiated by the security processor 110 to address a security processor error. An interrupt signal triggered by a subsystem of the SoC 100 may be triggered based on the subsystem detecting an error (similar to active debugging). Such an interrupt signal is referred to herein as an “active debug type” interrupt signal. Furthermore, an interrupt signal triggered by a subsystem of the SoC 100 may be triggered based on the detection of a data collection condition defined in subsystem-specific configuration data (similar to DaaS). Such an interrupt signal is referred to herein as a “DaaS type” interrupt signal. According to one embodiment, the detection of the data collection condition may be performed by the processor 110. In this embodiment, in response to the detection of the data collection condition, the processor 110 initiates an interrupt protocol to start a secure data collection operation.

[0032] In one embodiment, the data recorder 114 distinguishes active debug interrupt signals from DaaS interrupt signals. For example, the security processor 110 implements a shared interrupt line through which interrupt signals arrive at the processor 110. In this example, the shared interrupt line is associated with a memory address or register. In connection with triggering an acquisition interrupt signal, the subsystem triggering the data acquisition interrupt signal writes information (such as a cookie) to the associated memory address or register to indicate whether the interrupt signal is a data acquisition signal and / or whether the signal is a DaaS interrupt signal or an active debug interrupt signal. In another example, the security processor 110 implements one or more dedicated data acquisition interrupt lines through which interrupt signals arrive at the processor 110. Further, the first dedicated data acquisition interrupt line sends a DaaS interrupt signal to the processor 110, and the second dedicated data acquisition interrupt line sends an active debug interrupt signal to the processor 110.

[0033] Flowchart 200 is described in the context of active debugging. However, the techniques shown in Flowchart 200 are also applicable to DaaS, as will be explained in more detail below.

[0034] In active debugging, the microcontroller of any given subsystem can detect whether the subsystem in question has entered a “bad” state or a state caused by some kind of error. For example, the MC170A can detect that the communication interface 170 has experienced an error (or entered a “bad” state) based, for example, on the elapsed watchdog timer for the communication interface 170 or on the system management unit detecting an error in the communication interface 170. Based on the detection of the error, the MC170A automatically sends an interrupt signal to the security processor 110 to inform the processor that it needs to record work data.

[0035] To further illustrate a specific embodiment, Figure 3 shows a more detailed flowchart 300 for an exemplary implementation of securely collecting and storing targeted work data for a target device based on configuration information. In step 300A of flowchart 302, the microcontroller of an exemplary subsystem of the SoC 100 (MC170A of the communication interface 170) sends a data-collecting interrupt signal to the security processor 110. Although the communication interface 170 is shown as the source of the interrupt signal, any subsystem of the SoC 100 can be the source of the interrupt signal according to the techniques described herein.

[0036] Furthermore, as shown in step 302B, the execution of the data recorder 114 may be initiated based on an interrupt signal that includes an action by 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 initiates a self-interrupt protocol, which is an exemplary interrupt signal originating from the security processor 110.

[0037] (Configuration data) In response to detecting an interrupt signal, the security processor 110, in SEE 112, uses the data recorder 114 to perform a data collection operation including steps 204 to 206 of the flowchart 200. Specifically, in step 204, data is collected from one or more data collection locations based on configuration data. According to one embodiment, one or more data collection locations are identified based on configuration data, and one or more data collection locations include one or more hardware registers or memory locations. For example, the security processor 110 starts the data recorder 114 in response to receiving an interrupt signal from MC 170A. Once started, the data recorder 114 automatically begins the data collection operation.

[0038] As illustrated in the context of flowchart 300, in step 304, based on an exemplary interrupt signal from the MC170A, which is of the "data collection" type, the security processor 110 automatically starts the data recorder 114 ("DR") by, for example, loading and executing instructions for the data recorder 114. Furthermore, in step 306, the security processor 110 stops the execution of any thread currently being run by the security processor 110. Step 306 may be performed by the security processor 110 in response to the detection of an interrupt signal, or by the data recorder 114 after it has been started.

[0039] In step 308, the data recorder 114 reads the configuration data 136. According to one embodiment, the data recorder 114 reads the configuration data 136 from a known location. According to another embodiment, information in a memory location or register associated with an active debug interrupt signal (i.e., resulting from the subsystem entering a “bad” state) may identify the location of the configuration data used for the data acquisition operation. If the information associated with the interrupt signal does not identify the location of the configuration data used for the data acquisition operation, the data recorder 114 reads the configuration data 136 from a default location.

[0040] According to one embodiment, the default location of the configuration data 136 is within the BIOS loaded into secure memory 132. According to one embodiment, the configuration data 136 is encrypted data (e.g., signed binary data) and may be a configuration file originally included in the BIOS or a file included in a BIOS update from a developer debugging the system. Nevertheless, the default location of the configuration data 136 may be in any memory accessible to the secure actor of SEE 112.

[0041] According to one embodiment, when the data recorder 114 accesses configuration data 136 stored as binary data, the data recorder 114 verifies the signature of the binary data and then decrypts the data. The decrypted content is copied to secure memory 132. According to one embodiment, the binary file format of the configuration data 136 is generated by a security tool executed, for example, by the security processor 110, using a script that handles input and field verification. The configuration data 136 acts as input used by one or more instructions executed on the security processor 110. According to one embodiment, the configuration data 136 is verified by the security processor 110 when the data is loaded by the data recorder 114, for example, into a Serial Peripheral Interface (SPI)-ROM.

[0042] The configuration data 136 indicates one or more locations where the data recorder 114 collects work data, which may be on the SoC 100 or on different machines that have access to the security processor 110. The configuration data 136 may be in any format, including a user-readable file format such as XML.

[0043] Based on the configuration data 136, the data recorder 114 identifies a target data location from which working data is collected for a predetermined data collection operation. According to one embodiment, one or more target data locations include the location or identification of one or more hardware registers and / or one or more memory locations. The memory locations may specify locations in secure or non-secure memory accessible by the data recorder 114. The hardware registers may be registers used by the processor on the SoC 100 (e.g., one of the secure registers 116 and register 124), or they may be registers that are part of an integrated circuit (ASIC, etc.) that holds data at the RTL level. Specifically, the hardware circuit comprises registers for sequential logic and combinational logic implemented in hardware. The RTL data includes flow signals recorded in the hardware registers, triggered by the functionality of the hardware circuit. The RTL data is not accessible by software, meaning that data at this level is not available through software implementation debugging techniques.

[0044] Configuration data 136 is used to pass the input to the data recorder 114 so that the recorder knows which data needs to be captured. This input can be formatted by the data recorder 114 in various ways and then parsed. The work data to be collected, identified in configuration data 136, may be general or specific to the source of the interrupt signal. For example, configuration data 136 identifies the location of work data to be recorded regardless of the source of the interrupt signal. The location of the work data may be from one or more subsystems of the SoC 100. In this example, the data recorder 114 collects work data at all locations identified in configuration data 136. In another example, configuration data 136 identifies the location of one or more subsystem-specific sets of work data to be recorded. In this example, the data recorder 114 collects work data at the set of data locations in configuration data 136 associated with the subsystem that issued the interrupt signal.

[0045] For example, Figure 4 shows exemplary configuration data 136, which includes both data recorded regardless of the interrupt signal source and subsystem-specific data. The structure of the configuration data 136 in Figure 4 is exemplary, and the configuration data 136 may be structured differently depending on the implementation. In the example in Figure 4, the configuration data 136 includes multiple sections, namely a master table section 400, a subtable section 410, and target storage location data 420. According to one embodiment, when the data acquisition operation is initiated, all the work data identified in the master table 400 and subtable 410 of the configuration data 136 is acquired by the data recorder 114. According to another embodiment, the data recorder 114 always acquires the work data identified in the master table 400, and then acquires the work data identified in one or more subtables (of subtable 410) based, for example, on the fact that one or more subtables are associated with the source of the data acquisition interrupt signal.

[0046] In the exemplary configuration data 136 of Figure 4, the master table section 400 shows data that is recorded regardless of the source subsystem of the interrupt signal. In this example, the master table section 400 includes the following fields, which are used as shown according to one embodiment. The ASIC serial number used as a seed (parameter) in the key derivation function for deriving a wrapping key specific to the SoC100. • The wrapped encryption key is the key used to encrypt the configuration data binary content. The wrapped encryption key is unwrapped using the key derived from the key derivation function. • A wrapped signing key is the key used to verify signatures present in the configuration data. The wrapped signing key is unwrapped using a key derived from a key derivation function. A unique identifier field that is updated with a random value when the configuration data binary is generated. This unique identifier value is included in the data collected by the data recorder 114. This unique identifier is used by the user to access the working data collected by the data recorder 114 from, for example, a network storage device. • The table version, which is the version number associated with the format of master table 400. Based on this number, data recorder 114 can interpret master table 400. • Num IP and total size are numbers that assist in parsing subtable 410.

[0047] In this exemplary configuration data, subtable section 410 includes subsystem-specific subtables 412 and 414. The subtables within subtable section 410 contain subsystem-specific details for identifying where the subsystem's data collection locations are. Generally, subtables contain details for the specific subsystem from which data needs to be collected. Therefore, if data needs to be collected from multiple subsystems, multiple subtables will exist. For example, the working data identified in subtable 410 (or master table 400) within configuration data 136 may reside in one or more of the following locations: CPU registers, general-purpose shared registers, I / O memory, DRAM / SRAM memory, or graphics / video memory. Each subtable may have one or more fields indicating different types of data that need to be collected. For example, the data may come from CPU registers or general-purpose shared registers, or from I / O memory, DRAM / SRAM memory, or graphics / video memory. In Figure 4, SMN corresponds to I / O memory, and CRU registers are general-purpose registers.

[0048] (Data collection and storage) As shown above, in step 204 of flowchart 200, data is collected from one or more data collection locations based on the configuration data. For example, as shown in step 310 of flowchart 300, the data recorder 114 reads data from data locations identified from the configuration data 136. For example, the data recorder 114 determines that none of the subtables in the subtable section 410 of the configuration data 136 are specific to the communication interface 170. Therefore, the data recorder 114 collects working data from the set of locations on the SoC 100 identified in the master table section 400 of the configuration data.

[0049] In step 206 of flowchart 200, the collected data is stored in one or more target storage locations. For example, the data recorder 114 stores the collected working data in secure memory 132 based on one or more target storage locations identified in the configuration data 136. Each of the one or more target storage locations identifies one of the following: an on-device storage device, a locally accessible storage device, and / or a network-accessible storage device. For example, the target storage location data 420 in the exemplary configuration data 136 of Figure 4 indicates one or more target storage locations for a given data collection operation.

[0050] To further explain, in step 312 of flowchart 300, the data recorder 114 generates a unique identifier for the collected work data, for example, based on the hash of the collected work data. In step 314, a header containing the unique identifier is also generated for the collected work data.

[0051] In step 316, the collected working data is encrypted. For example, the collected working data and header are encrypted by the security processor 110 based on the encryption information in the master table section 400 of the configuration data 136. In another example, the header is not encrypted and is stored unencrypted along with the encrypted working data.

[0052] In step 318, the encrypted data is stored in one or more of the following: local / external storage, on-chip storage, or network-based storage devices, as indicated by the target storage location data 420. Step 320 indicates a decision on where to store the collected working data, for example, based on the configuration data 136.

[0053] Some ASICs have on-chip storage that can be accessed by root-of-trust hardware. For example, based on configuration data 136, the data recorder 114 stores the collected data in secure memory 132, which is a storage device on the SoC 100. In another example, the data recorder 114 stores the collected data as encrypted data in a dedicated encrypted partition of storage device 150. Similarly, based on configuration data 136, the data recorder 114 may store the collected working data in storage device 186, which is a flash drive communicably connected to the SoC 100, for example, via a USB port.

[0054] The configuration file may indicate that the collected work data is stored in a remote storage device 184 accessible via network 182. To store the data via network 182, the data recorder 114 establishes a secure connection to the storage device 184. According to one embodiment, target storage location information identifying the storage device 184 includes the data necessary to connect to the network location of the storage device 184. The firmware of the security processor 110 is configured to establish a secure network connection without requiring operating system functionality, so this secure connection can be established during the pre-boot phase of the computing device (as long as the communication interface 170 is initialized during the boot sequence). Once the connection is established, it is used to securely transmit data to the storage device 184.

[0055] In step 322, the firmware status is updated. For example, the security processor 110 includes a status register, which is updated to a first predetermined value indicating that data collection has started when the data recorder 114 is started in step 304. Once the storage of the work data collected based on the instructions from the configuration data 136 is complete, the status register of the security processor 110 is updated again to indicate the completion of data collection. The updated value of the status register may be any predetermined value different from the first predetermined value to indicate the completion of the data collection operation.

[0056] The user can retrieve the desired data by providing the ASIC serial number and a unique identifier for the collected work data included in the configuration data 136 as described above. In network-based storage devices, date and time information acts as additional parameters for distinguishing the data. According to one embodiment, post-processing can be performed only by an authorized user and only if the captured data has not been tampered with.

[0057] (Active debugging) According to one embodiment, after collecting and storing work data for a predetermined data acquisition operation, the data recorder 114 awaits an input containing a new firmware image. According to one embodiment, the data recorder 114 accepts only new firmware inputs for specific types of interrupt signals associated with active debugging. Information associated with the interrupt signal may be used to distinguish such interrupt signals from DaaS-based interrupt signals, which are described in more 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.

[0058] The data recorder 114, which is waiting for input containing a new firmware image, allows the developer to push the new firmware image to the data recorder 114, thereby causing the security processor to apply the new firmware image to the SoC 100. Figure 5 shows a flowchart 500 for performing active debugging by accepting firmware update information and applying the firmware update information to update the firmware of the computing device.

[0059] In step 502, the work data is analyzed. For example, the SoC 100 experiences an error using the communication interface 170 and collects work data as described above in relation to flowcharts 200 and 300. Based on the data in the configuration data 136 indicating that the collected work data is to be stored in the storage device 150 (on-chip), the data recorder 114 stores the collected work data in the storage device 150 using the determined header. The developer identifies the data in the storage device 150 based on the unique identifier recorded in the configuration data 136.

[0060] The developer analyzes the extracted 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 a set of data that can be used to reproduce the crash scenario, and the developer inputs the collected working data into a post-processing tool that generates the reproduction.

[0061] In 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 both of the following: a firmware update to address the problem, and / or an additional set of working data to further assist in debugging the problem. For example, the developer determines that (a) a specific change to the firmware of SoC100 may resolve the problem, and (b) information from a specific register of SoC100 and data from a specific memory area in memory 130 may be useful for debugging SoC100 if the solution fails.

[0062] In step 506, the developer constructs a new firmware image. For example, in the new firmware image for SoC100, the developer encodes both specific changes to the firmware that can resolve the issues identified in relation to step 504, and new configuration data 136 that indicates the location of identified registers in SoC100 and identified memory regions within memory 130.

[0063] According to one embodiment, new firmware information can be received by the data recorder 114 via a network or via a local connection. Therefore, in step 508, the developer determines which deployment method to use to push the firmware image to the data recorder 114, depending on whether the developer has local access to the device. If the developer is local to the SoC 100, in step 512, the developer deploys the new firmware image locally, for example, via a USB port, or via a storage device 186 that is communicably connected to the SoC 100.

[0064] If the developer is remote from the SoC100, in step 510, a network packet containing the new firmware image is prepared and sent over network 182. According to one embodiment, the network packet is sent from the client device to the SoC100 via a secure network connection over network 182.

[0065] According to one embodiment, a new firmware image sent via network 182 is stored in a temporary location within the SoC 100 (e.g., secure memory 132) to authenticate the firmware image. For example, the security processor 110 checks the type of the new firmware image, and the type indicates which subsystem the firmware is designed to run for (e.g., power management firmware, security firmware, video firmware, etc.). If the existing firmware is corrupted, or if the size of the new firmware is less than or equal to the size of the existing firmware, the new firmware is installed in the SoC 100. Otherwise, the security processor 110 throws an error, and a new firmware image must be generated for another attempt at firmware updating.

[0066] In step 514, the data recorder 114 updates the BIOS based on the new firmware image. This update introduces new configuration data 136 prepared by the developer, as well as possible solutions to problems. In step 516, the security processor 110 reboots the SoC100, which may be a cold boot or a warm reset. Rebooting the device completes the installation of the new firmware, in which case the newly updated firmware image is loaded while the SoC100 is booting.

[0067] After rebooting, if in step 518 all issues have not been resolved by the new firmware, in step 520 the security processor 110 runs the data recorder 114 again due to one or more remaining issues, as shown in steps 302-304 of flowchart 300 (Figure 3). The subsequent working data collected by the data recorder 114 is based on the new configuration data in the firmware image. However, if all issues are resolved after installing the new firmware, the process terminates in step 522.

[0068] (Debugging as a service) Collecting telemetry information over time from specific subsystems of a device can be extremely useful for improving the performance of those subsystems. For example, some graphics drivers provide high-end graphics capabilities for specific systems such as 3D graphics systems, computer-aided design systems, and gaming systems. Improving the performance of such drivers offers practical and business benefits to both clients and hardware providers.

[0069] Using the configuration-based data collection techniques described herein, DaaS enables hardware providers to target data collection to specific configurations and / or specific software configurations. Data collected using DaaS techniques can be sent to specific network-based storage devices and treated as a big data database, where analysis can be performed to identify updates occurring on various device subsystems, such as graphics drivers for specific GPU versions.

[0070] In DaaS, the data recorder 114 is started without subsystem errors. Specifically, the microcontroller of the subsystem implementing DaaS is associated with subsystem-specific configuration data that defines which data should be captured and when the execution of the data recorder 114 for the subsystem should be started. This subsystem-specific configuration data allows developers to start data collection at any time on demand. According to one embodiment, the subsystem-specific configuration file is stored in the production stack of each microcontroller that controls the subsystem. For example, a configuration file included in the production stack of the video driver for GPU160 indicates that the collected work data should include the load on GPU160 and the voltage, FW version, frame buffer, performance counters, etc. for GPU160.

[0071] Subsystem-specific configuration files may be specific to the hardware configuration and / or the device's use case. For example, a particular subsystem may be associated with multiple configuration files linked to a use case identifier. Based on the use case information for a given device, one of the configuration files is selected to be the active configuration file.

[0072] In one embodiment, the microcontroller of a subsystem implementing DaaS adds information identifying a specific type of work data collected from subsystem-specific configuration files to the configuration data 136 as a subtable. In this embodiment, when an interrupt event caused by a subsystem of the SoC 100 (which may be any subsystem including the security processor 110) is detected, the subsystem-specific information in the subtable is collected by the data recorder 114.

[0073] Furthermore, subsystem-specific configuration files indicate the conditions under which a data-gathering interrupt signal is sent to the security processor 110, as described above. At startup, the subsystem's microcontroller determines which conditions trigger data-gathering operation based on the subsystem-specific configuration files in the production stack. For example, the configuration file associated with the GPU 160 indicates that the data recorder 114 will gather subsystem-specific performance data when the load on the GPU 160 exceeds a predetermined threshold. The microcontroller sets up a listener process to detect if one or more of the indicated conditions are true. When the listener detects a data-gathering condition, it sends a data-gathering interrupt signal to the security processor 110.

[0074] DaaS-type interrupt signals are distinguished from active debug-type interrupt signals by at least one of the methods described above. 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 the security processor 110. In embodiments where the information associated with the interrupt signal includes subsystem-specific configuration file location information, the data recorder 114 reads a configuration file specific to the source of the interrupt signal instead of using configuration data 136. In embodiments where the interrupt signal is distinguished with respect to DaaS in a different way, the data recorder 114 collects subsystem-specific work data using a subsystem-specific subtable appended to the configuration data 136.

[0075] (Hardware overview) According to one embodiment, the technology described herein is implemented by one or more dedicated computing devices. The dedicated computing device may be hardwired to implement the technology, or may include one or more digital electronic devices such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs) permanently programmed to implement the technology, or may include one or more general-purpose hardware processors programmed to implement the technology according to program instructions within firmware, memory, other storage devices, or a combination thereof. Furthermore, such a dedicated computing device may combine custom hardwired logic, ASICs, or FPGAs with custom programming to implement the technology. The dedicated computing device may be any computing device, such as a SoC or other computing system, that incorporates hardwired logic and / or programmed logic to implement the technology.

[0076] As shown above, Figure 1 is an exemplary block diagram showing an SoC 100 in which one embodiment may be implemented. The SoC 100 includes an I / O subsystem (bus) 140 or other communication mechanism for communicating information, and a hardware processor, CPU 120, coupled to the bus 140 for processing information. In the example in Figure 1, the CPU 120 is a general-purpose microprocessor.

[0077] Furthermore, the SoC100 includes memory 130, such as random access memory (RAM) or other dynamic storage devices, connected to bus 140, for storing information and instructions executed by processors on the SoC100, such as the CPU120, security processor 110, and GPU160. Memory 130 may also be used to store temporary variables or other intermediate information while processors on the SoC100 are executing instructions. When such instructions are stored in a non-temporary storage medium accessible to the CPU120, the SoC100 becomes a dedicated machine customized to perform the operations specified in the instructions. A storage device 150, such as a magnetic disk, optical disk, or solid-state drive, is provided and connected to bus 140 for storing information and instructions. The SoC100 may also include read-only memory (ROM) (not shown in Figure 1) or other static storage devices connected to bus 140 for storing static information and instructions for one or more processors on the SoC100.

[0078] The SoC100 can implement the techniques described herein using customized hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic, which, in combination with a computer system, make the SoC100 a dedicated machine or programmable. According to one embodiment, the techniques described herein are implemented by the SoC100 in response to the CPU120 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. The execution of the sequence of instructions contained in memory 130 causes the CPU120 to carry out the process steps described herein. In alternative embodiments, hardwired circuits can be used instead of, or in combination with, software instructions. In Figure 1, the SoC100 is connected via bus 140 to an external locally accessible storage device 186 having a storage medium.

[0079] As used herein, the term “storage medium” refers to any non-temporary medium that stores data and / or instructions that cause a machine to operate in a particular manner. Such storage mediums may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical disks, 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 having a pattern of holes, RAM, PROMs, EPROMs, FLASH-EPROMs, NVRAMs, and any other memory chips or cartridges.

[0080] A storage medium is separate from a transmission medium, but can be used together with one. The transmission medium is involved in the transfer of information between storage mediums. For example, the transmission medium includes coaxial cables, copper wires, and optical fibers, including the wires that make up the bus 140. The transmission medium can also take the form of sound waves or light waves, such as those generated during radio and infrared data communications.

[0081] Various forms of media may be involved in transporting one or more sequences of one or more instructions to the CPU 120 for execution. For example, instructions may first be transported on a magnetic disk or solid-state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send them over a network. The communication interface 170 of the SoC 100 can receive data from the network, and appropriate circuitry can place the data on the bus 140. The bus 140 transports the data to the memory 130, from which the CPU 120 retrieves and executes the instructions. Instructions received by the memory 130 may optionally be stored in a storage device 150 either before or after execution by the CPU 120.

[0082] The communication interface 170 of the SoC100 is connected to the bus 140 and provides bidirectional data communication to a network link 180 connected to the local network 182. For example, the communication interface 170 may be a local area network (LAN) card that provides 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 that carry digital data streams representing various types of information.

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

[0084] The SoC100 can send messages and receive data, including program code, via the network, network link 180, and communication interface 170. For example, an external computing device (not shown in Figure 1) may send firmware updates for the security processor 110 to the SoC100 via network 182 and communication interface 170. The received code may be executed by the SoC100 upon receipt and / or stored in the storage device 150 or other non-volatile storage device for later execution.

Claims

1. A computer executable method, a) Applying configuration data that indicates one or more data acquisition locations, including at least one data acquisition location in the secure registers and random access memory (RAM) of the hardware processor, and b) one or more target storage locations. Detecting interrupt events and This includes the following: In response to the aforementioned interrupt event, the processor of the computing device uses a secure execution environment to perform data collection operations; The aforementioned data collection operation is, Collecting data from one or more data collection locations, including the secure register of the hardware processor and at least one data collection location of the RAM, Identifying one or more target storage locations based on the configuration data, This includes storing the collected data in one or more target storage locations. Each of the one or more target memory locations is A memory device which is a component of the aforementioned computing device, A storage device that is communicatively connected to the computing device, or A storage device accessible via a network. Identify one of the following: Computer executable methods.

2. The interrupt event is associated with information that links the interrupt event to the data collection operation. A computer-executable method according to claim 1.

3. The detection of the interrupt event is performed by the processor during the pre-boot phase of the computing device. A computer-executable method according to claim 1.

4. Detecting the aforementioned interrupt event is performed by the processor while one or more threads are being executed by the processor. The method further includes stopping the execution of one or more threads in response to detecting the interrupt event. A computer-executable method according to claim 1.

5. The aforementioned RAM is video memory. A computer-executable method according to claim 1.

6. The interrupt event is associated with the location of the configuration data within the production stack of a specific subsystem of the computing device. The one or more data collection locations are associated with the specific subsystem, The method further includes retrieving the configuration data from the location. A computer-executable method according to claim 1.

7. The method further includes generating a unique identifier for the collected data, wherein the collected data is stored in association with the unique identifier. A computer-executable method according to claim 1.

8. The aforementioned data collection operation, after storing the collected data, Receiving firmware update information, Upon receiving the aforementioned firmware update information, To verify the aforementioned firmware update information, The further includes updating the firmware of the computing device by applying the aforementioned firmware update information, A computer-executable method according to claim 1.

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

10. Identifying one or more data collection locations based on the configuration data, further comprising the fact that the one or more data collection locations include one or more hardware registers or memory locations. A computer-executable method according to claim 1.

11. A computing system, One or more processors, The device comprises a memory that stores one or more instruction sequences that, when executed by one or more processors, cause to perform any of the methods of claims 1 to 10, Computing system.

12. A computer-readable storage medium comprising instructions that, when executed by one or more processors, cause to perform any of the methods of claims 1 to 10.

Images