Confidential computing architecture for silicon initialization to achieve IP protection and assurance

Abstract

Embodiments relate to a confidential computing architecture for silicon initialization to achieve IP protection and assurance. An embodiment of a processing system includes a memory device communicatively coupled to a hardware component and to a memory module, the memory device to store platform initialization firmware that causes the processing system to execute a firmware hypervisor to initiate a trust domain (TD) of a confidential computing architecture, the TD is used for providing confidentiality and integrity protection for data loaded in the TD; loading an IP firmware and an initial program loader (IPL) for the IP firmware in the TD, where the IP firmware corresponds to the IP component and is encrypted; obtaining an IP firmware key by the IPL so as to decrypt the IP firmware in the TD; and performing an initialization process for the IP component using the decrypted IP firmware.

Description

Technical Field

[0001] The present disclosure relates generally to confidential computing, and more particularly to a confidential computing architecture for performing silicon initialization to achieve IP protection and assurance. Background Art

[0002] A processing system may include hardware components and software components. The software components may include one or more applications, an operating system (OS), and firmware. An application may include control logic for performing work that is valuable to a user of the processing system. In a processing system, applications run on top of the OS, which runs at a lower logical level (i.e., closer to the hardware) than the applications to provide an underlying environment or abstraction layer that makes it easier to create and execute applications. Firmware runs at an even lower logical level to provide an underlying environment or abstraction layer that makes it easier to create and execute OS. For example, firmware may establish a basic input / output system (BIOS), and the OS may use the BIOS to communicate with different hardware components within the processing system. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The embodiments described herein are illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references refer to similar elements.

[0004] Figure 1 A system on a chip (SoC) implementing a confidential computing architecture for performing silicon initialization to achieve IP protection and assurance according to an implementation of the present disclosure is illustrated.

[0005] Figure 2 The diagram depicts a block diagram of a computing system providing a confidential computing architecture for performing silicon initialization to achieve IP protection and assurance, according to implementations of the present disclosure.

[0006] Figure 3 The diagram depicts a block diagram of an IP initialization environment implementing a confidential computing architecture for performing silicon initialization to achieve IP protection and assurance, according to implementations of the present disclosure.

[0007] Figure 4 The diagram depicts a block diagram of an IP initialization environment implementing multiple TDs for silicon initialization to achieve IP protection and assurance, according to implementations of the present disclosure.

[0008] Figure 5 A flow diagram illustrating operations of implementing a confidential computing architecture for silicon initialization to achieve IP protection and assurance, in accordance with implementations of the present disclosure.

[0009] Figure 6 is a schematic diagram of an illustrative electronic computing device enabling a confidential computing architecture for silicon initialization for IP protection and assurance, according to some implementations. DETAILED DESCRIPTION

[0010] Embodiments described herein relate to a confidential computing architecture for silicon initialization to achieve IP protection and assurance.

[0011] When a processing system is turned on or reset, the processing system may perform a boot process before the processing system can be used for work. As discussed herein, the operations for preparing the processing system to execute the OS may be referred to as a "boot process." Similarly, the time elapsed during the boot process may be referred to as "boot time." The control logic or firmware that performs or controls the boot process may be referred to as "system firmware," "system boot code," "platform boot code," or simply "boot code."

[0012] In conventional computing systems such as system on chip (SoC), various platform components (also referred to herein as platform devices) are enabled during the boot process. Platform components may refer to components that implement hardware functions in a computing system, and may include, but are not limited to, Universal Asynchronous Receiver / Transmitter (UART), Ethernet controller, Media Access Controller (MAC), Peripheral Component Interconnect (PCI), PCI Express (PCI-express, PCI-E), Processor Unit, Power Module, USB Module, Memory Module, etc. Hardware circuits that are the basic building blocks of platform component design and integrated into the core logic of the system processing chip are referred to herein as semiconductor intellectual property (IP), or simply referred to herein as "IP" or "IP block".

[0013] In conventional computing systems, IP for a computing system (e.g., SoC) is enabled during boot. This is because in conventional systems, these IPs cannot be dynamically enabled / disabled in a verified environment based on functional usage by the runtime operating system (OS). IP can be enabled during the boot process itself by hardware initialization code (e.g., basic input / output system (BIOS) code). In some cases, system firmware may support binary silicon IP distribution, such as Scalable Firmware Supported Package (sFSP) module binaries.

[0014] Technologies such as sFSP use plaintext binary files to deliver initialization code. However, since plaintext binary files can be disassembled by any third party and the internal flow of IP initialization can be identified, security issues arise. Many SoC platforms are turning to IP-based initialization, where IP modules may come from third parties. The current approach does not allow third-party SoC IP providers to avoid disclosing IP. Instead, such third-party SoC IP providers must trust BIOS vendors, who obtain IP initialization code in the form of source code. This results in a potentially unsafe initialization environment for SoC IP providers.

[0015] There are several different conventional approaches to address the insecure initialization environment of the SoC IP provider. The first conventional approach is to provide a BIOS protection module, which is an encryption module that supports secure BIOS updates. The BIOS protection module is decrypted by the CPU in a cache inside the system management memory (SMM). In this way, the BIOS protection module uses SMM to prepare the environment and load the binary file in a dedicated RAM, while in SMM, all CPUs are in a converged state. After the BIOS module runs, the system restores the previous execution environment. This can be used for one-time initialization, but it is difficult to use this approach to provide runtime services.

[0016] The second conventional way is to use encrypted firmware. A special root of trust module should be used to decrypt the firmware and load it into the internal memory for execution. The third conventional way is to migrate the IP firmware to a microcontroller. The microcontroller can have its own root of trust and key storage device to decrypt the IP firmware. For the second and third ways, the IP firmware should be loaded into a special microcontroller or device memory after decryption. The IP firmware plaintext should not be loaded into the host memory or should not be directly accessed by the host CPU, which may lead to increased architecture complexity and cost.

[0017] The implementations herein address the technical deficiencies of the conventional approaches described above by providing a confidential computing architecture for performing silicon initialization to implement IP protection and assurance. In embodiments herein, the confidential computing environment may include a Trust Domain Extensions (TDX) confidential computing environment. In some embodiments, the confidential computing environment may include other confidential computing architectures, such as secure encrypted virtualization (SEV).

[0018] TDX includes instructions in the CPU instruction set architecture (ISA) for removing a virtual machine monitor (VMM) from a trusted computing base (TCB) of a cloud computing virtual machine (VM) workload (referred to as a trust domain or TD). In general, a TCB includes a collection of hardware, firmware, and software components implemented on a platform to provide a secure environment, including portions of the platform's memory address space used by the TCB.

[0019] In the implementation described herein, in order to protect the IP firmware execution flow, the sFSP binary file (such as FSP-Memory (FSP-M) or FSP-silicon (FSPS)) is placed in a dedicated domain of the confidential computing architecture (such as the Trust Domain (TD) of the TDX architecture). TDX is used to create a dedicated TD for SoC IP initialization and runtime services. TD provides confidentiality and integrity protection for SoC IP code. sFSP is allowed to perform initialization using a security arbitration module, such as a TDX module in Security Arbitration Mode (SEAM). The TDX module has a dedicated initiator security attribute (SAI) granted by hardware. The TDX module can directly access the silicon IP.

[0020] In the implementation of this article, when the lightweight firmware hypervisor (LFH) initializes the TD environment, the sFSP binary file is encrypted. During runtime, the sFSP loader obtains encryption keys from key services. Key services can be embedded in SoC IP, such as in register transfer layer (RTL), or in a secure microcontroller (such as, server startup secure service module (S3M) or enhanced security engine (ESE)). In some implementations, key services can be in a remote server accessible via the cloud from a service baseboard management controller (BMC). In order to ensure that the key request is initiated from a known good TD, mutual authentication is achieved between the TD IP firmware loader and the key service.

[0021] The technical advantages provided by the implementation of the present disclosure include improving the security of SoC by protecting the IP initialization process in SoC of all IP vendors and protecting the runtime logic of these initialized IPs. This prevents unauthorized and untrusted access to the IP initialization firmware on the SoC.

[0022] Figure 1 A system on chip (SoC) 100 implementing a confidential computing architecture for performing silicon initialization to implement IP protection and assurance in accordance with an implementation of the present disclosure is illustrated. The SoC 100 includes a boot controller 146. The boot controller 146 may be located within a processor 102. The depicted SoC 100 illustrates a hardware processor 102 coupled to a memory 106 via a memory controller 108. In one embodiment, the memory 106 of the SoC 100 is a system memory (e.g., a dynamic random-access memory (DRAM)). The memory controller 108 may be included to, for example, manage memory requests between the processor 102 and the memory 106. In one embodiment, the memory controller 108 is used to provide (e.g., fill) data (e.g., cache lines) for misses in cache(s) (e.g., misses in an L3, L4, or other last level cache (LLC) of the processor 102).

[0023] Processor 102 may include one or more processor cores 112, e.g., processor cores 0 to N, where N is a positive integer. In one embodiment, each processor core of the plurality of processor cores has an instance of the circuitry described herein. Depicted core 0 112(0) includes a first level (L1) data cache 118(0), a first level (L1) instruction cache 120(0), and a second level (L2) cache 122(0). Depicted core 1 112(1) includes a first level (L1) data cache 118(1), a first level (L1) instruction cache 120(1), and a second level (L2) cache 122(1).

[0024] In some embodiments, Figure 1 As shown in , the processor 102 includes one or more next level caches 124 coupled to and shared by one or more of the cores (e.g., all the cores), e.g., a third level (L3) cache and a fourth level (L4) cache, e.g., L4 being a last level cache (LLC) (e.g., the last cache searched before a data item is fetched from the memory 106). In some embodiments, each of the L1 data cache 118, the L1 instruction cache 120, the L2 cache 122, the LLC cache 124 (e.g., the L3 cache and / or the L4 cache) is managed by a cache coherence controller 142 (e.g., a circuit system) to cache data (e.g., and / or instructions), e.g., according to a specified cache coherence.

[0025] In some embodiments, data (e.g., and / or instructions) stored within each processor cache is managed at the granularity of a cache line, which may be of a fixed size (e.g., 64 bytes, 128 bytes, 512 bytes, etc. in length). Each core 112 may include other components, such as instruction fetch circuitry for fetching instructions from memory 106 (e.g., main memory and / or from a cache), such as via a memory controller; decode circuitry for decoding instructions (e.g., decoding program instructions into micro-operations (i.e., "μops")); and an execution unit (e.g., execution circuitry) for executing the decoded instructions. The core may include write-back / retirement circuitry for retiring instructions and writing back results. The depicted core 0 112 (0) further includes a set of one or more registers 114 (0), such as having one or more model-specific registers 116 (0), such as, for example, as control register(s).

[0026] The SoC 100 may include one or more other devices 144 (e.g., any devices to be initialized prior to DRAM initialization and cache attachment, such as CSME, GSPI, ESPI, etc.) that are also coupled to the cache coherence controller 142. The SoC 100 may include a graphics circuit system 136 (e.g., a graphics core). In some embodiments, the graphics circuit system 136 includes one or more caches 138 coupled to one or more caches shared with the processor (e.g., L3 cache and / or L4 cache 124). The SoC 100 may include an embedded dynamic random-access memory 140 (eDRAM), which is embedded in the SoC 100, for example, with the processor 102. In some embodiments, the eDRAM 140 is used as an L4 (e.g., LLC) cache 124 (e.g., instead of using embedded static RAM (eSRAM) for the L4 cache). In some embodiments, the eDRAM 140 is located between the L3 cache 124 and the memory 106 (e.g., DRAM (e.g., Double Data Rate Synchronous DRAM, DDR)), such as on a memory bus. The SoC 100 may include a power management integrated circuit (PMIC) 154, which is used to provide power to components of the SoC 100, such as in response to a power-on indication (e.g., a press of a mechanical on / off switch).

[0027] In some embodiments, SoC 100 (e.g., internal or external to processor 102) includes hardware initialization code storage 148. The hardware initialization code may be hardware initialization firmware. In some embodiments, the hardware initialization code from storage 148, when executed by processor 102, is used to cause booting of SoC 100 (e.g., booting of at least its hardware processor 102).

[0028] In certain embodiments, the hardware initialization code is responsible for transferring control of a computer (eg, SoC 100) to a program (eg, OS) stored in a memory coupled to the computer.

[0029] In some embodiments, hardware initialization code storage device 148 includes BIOS and / or UEFI code from storage device 150 and boot loader code from storage device 152. In some of those embodiments, BIOS and / or UEFI (e.g., boot ROM) code is executed as a first stage, and then boot loader code is executed as a second stage. As an example, BIOS code is in accordance with the BIOS standard. As another example, UEFI code is in accordance with the UEFI standard. Other embodiments of BIOS include Universal Scalable Firmware (USF), Slim Bootloader, Coreboot, Tianocore, and U-Boot, to name a few. In some embodiments, such as to achieve silicon abstraction, the implementation may include binary file packaging, such as Firmware Support Package (FSP), in addition to other binary file embodiments, such as other Boot ROM for x86, RISC-V, or ARM.

[0030] In some embodiments, the BIOS and / or UEFI code brings the SoC 100 (e.g., its processor 102) out of a (e.g., cold) reset, puts the processor in a known and stable state, and finds the second stage boot loader code (e.g., from storage 152) and passes control to the next stage. In one embodiment, the BIOS and / or UEFI (e.g., boot ROM) code is aware of the second stage boot loader code 152 and is unaware of any potential subsequent software stages. In some embodiments, during this time, the BIOS and / or UEFI (e.g., boot ROM) code handles any error conditions.

[0031] In some embodiments, the boot loader code (e.g., to which control of the SoC (e.g., processor) is passed when the BIOS and / or UEFI code stage is completed) then locates and loads (e.g., for execution by the processor) the next stage(s) of software (e.g., OS), etc. In one embodiment, if secure boot is enabled, control is decrypted and / or authenticated before being passed to the boot loader code.

[0032] In some embodiments, the BIOS and / or UEFI (e.g., boot ROM) code, when executed, initializes certain hardware of the SoC, checks integrity, and initializes the (e.g., first-level) boot loader code. In some embodiments, the boot loader code is executed, for example, after being called when the BIOS and / or UEFI (e.g., boot ROM) code execution is completed, to cause a handover of control of the SoC (e.g., processor) to an operating system executing the SoC. In one embodiment, for example, the boot loader code knows where the OS kernel image is stored in memory (e.g., the memory location of the OS kernel image) and loads the OS kernel image for execution.

[0033] Although the BIOS and / or UEFI (e.g., boot ROM) code storage device 150 and the boot loader code storage device 152 are shown as being together, in another embodiment, the BIOS and / or UEFI (e.g., boot ROM) code storage device 150 is within the processor 102 and the boot loader code storage device 152 is separate from the processor 102 (e.g., in the storage device 148 of the SoC 100).

[0034] In an implementation of the present disclosure, BIOS and / or UEFI (e.g., boot ROM) code 150 includes IP firmware binary code, such as an encrypted Scalable Firmware Support Package (sFSP) module binary code, for initializing one or more IP blocks of SoC 100. During the initialization (boot) sequence of the SoC, TD code 165 can enable a lightweight firmware manager (LFH) to initialize a confidential computing environment, such as a TD of a TDX architecture. Although the implementations herein are discussed with respect to utilizing TD and TDX architectures, other types of confidential computing architectures may also be utilized in the implementations herein, such as confidential computing architectures such as Software Guard Extensions (SGX), Secure Encrypted Virtualization (SEV), Realm and so on.

[0035] The LFH loads the IP firmware binary code (including the encrypted IP initialization firmware) and the initial program loader (IPL) into the TD. The IPL can provide an interface to the TDX module of the TDX architecture so that the IPL can decrypt the IP firmware binary code and allow the IP firmware binary code to perform the initialization of the IP blocks of the SoC in a secure and verified manner. Now turn to Figure 2 , depicts an example computing environment for a SoCIP block initialization process according to an implementation of the present disclosure.

[0036] Figure 2 The diagram depicts a block diagram of a computing system 200 that provides a confidential computing architecture for performing silicon initialization to implement IP protection and assurance according to an implementation of the present disclosure. In one implementation, the computing system 200 is configured to perform a confidential computing architecture for performing silicon initialization to implement IP protection and assurance. Figure 1 The same as described in the SoC 100. Figure 2 As shown in FIG. 1 , computing system 200 includes OS 210, firmware 220, and hardware 250. In one implementation, computing system 200 is shown as implementing a confidential computing architecture, such as a TDX architecture. Figure 2 As illustrated in FIG. 1 , computing system 200 is powered on and host firmware (e.g., BIOS) 220 begins running on a processor (e.g., CPU 252, GPU, XPU, data processing unit (IPU), infrastructure processing unit (IPU), etc.) of hardware 250. Although the discussion herein may specifically refer to the utilization of a CPU, embodiments herein may also utilize any other type of processing unit, such as a GPU, XPU, DPU, IPU, hardware accelerator, etc.

[0037] In one implementation, the firmware 220 includes a BIOS / UEFI 222 and a boot loader 224 to implement a platform initialization 226 of the computing system 200. In one implementation, the BIOS / UEFI 222 and the boot loader 224 Figure 1 The BIOS / UEFI code 150 is the same as that of Figure 1 BIOS / UEFI 222 may bring computing system 200 out of reset (e.g., power on), place computing system 200 in a known and stable state, and locate bootloader 224 code to continue platform initialization 226. As part of the initialization process, IP initialization firmware binary 234 may be executed to initialize one or more IP blocks of the computing system (such as silicon IP 254 of hardware 250).

[0038] Implementations of the present disclosure provide an IP block initialization process for computing system 200 by implementing a confidential computing architecture for secure and authenticated initialization of IP firmware binary code 234. Implementations herein focus on confidentiality and integrity protection of such IP firmware binary code 234.

[0039] In one implementation, the BIOS and / or UEFI (e.g., boot ROM) 222 code includes an encrypted version of the IP firmware binary code (such as an encrypted sFSP binary code) that can be used to initialize one or more IP blocks 254 of the computing system 200. During the platform initialization 226 (boot) sequence of the computing system 200, the platform initialization 226 causes the LFH 230 to be initiated, which provides a confidential computing environment, such as the TD 232 of the TDX architecture. As previously mentioned, although the implementations herein are discussed in terms of utilizing TD and TDX architectures, other types of confidential computing architectures, such as the TD 232 of the TDX architecture, may also be utilized in the implementations herein. Software Guard Extensions (SGX), Secure Encrypted Virtualization (SEV), Realm, etc. Extensible

[0040] The LFH 230 loads the IP firmware binary code 234 (including the encrypted IP initialization firmware) into the TD 232, and loads the IPL 236 into the TD 232. The IPL 236 may then provide an interface to the TDX module 238 (of the TDX architecture) hosted by the LFH 230 so that the IP firmware binary code 234 is decrypted. In one implementation, the IPL 236 provides an interface to the key service 245 of the secure microcontroller 240 (or to an external key server 260) via the TDX module 238 to obtain an encryption key for decrypting the IP firmware binary file 234. Once decrypted by the IPL 236, the IP firmware binary file 234 may continue the initialization process of the IP block 254 of the computing system 200 in a secure and authenticated manner.

[0041] In the implementation of the present disclosure, the IP firmware binary file 234 can be considered as data to be protected at various stages of the data cycle, including static data, data in transition, and data in use. For static data, it refers to the IP firmware binary file 234 itself. The IP firmware binary file 234 is encrypted when it is initially provided (e.g., from the manufacturer). As described above, the encryption key should be obtained from a trusted key service in order to decrypt the IP firmware binary file 234.

[0042] For data in transit, it refers to the encryption key provided from the key service 245. When the key is transferred from the key service 245 to the TD 232, mutual authentication and session encryption can be utilized. The authorized IPL 236 can obtain the key for decrypting the IP firmware binary file 234.

[0043] By data in use, it refers to the IP firmware execution code or data structure that is decrypted in the TD 232. The memory is protected by the TDX architecture. The TD memory cannot be read or written outside the TD 232.

[0044] Figure 3 The diagram depicts a block diagram of an IP initialization environment 300 implementing a confidential computing architecture for performing silicon initialization to implement IP protection and assurance according to an implementation of the present disclosure. In one implementation, the IP initialization environment 300 is a reference to Figure 1 The SoC 100 described and / or referenced Figure 2 Portions of the computing system 200 are described. Figure 3 As shown in FIG. 1 , the IP initialization environment 300 includes a TD 310, a LFH 320, hardware 330, and a secure microcontroller 340. In some implementations, the components of the IP initialization environment 300 may be the same as those in FIG. Figure 1 and Figure 2 The corresponding components described and named identically are identical.

[0045] In one implementation, the IP initialization environment 300 is shown as implementing a confidential computing architecture, such as a TDX architecture. Figure 3As shown in , the confidential computing architecture implements a secure IP initialization process to initialize the silicon IP 335 of the hardware 330. At the first step 301, the LFH 320 loads the sFSP (a collection of IP firmware binaries) 312 (including the encrypted IP firmware inside the sFSP) and the IPL 314 into the TD 310. The IPL 314 can be a silicon-agnostic component in plain text, while the sFSP / IP firmware 312 is encrypted using a silicon-specific symmetric key. At step 301, the TDX module 325 in the SEAM extends the IPL 314 into the TD measurement register (TD measurement register, MRTD). Subsequently, the IPL 314 can extend the sFSP / IP firmware 312 into the runtime measurement register (RTMR). Both MRTD and RTMR are proofs of TD.

[0046] At the second step 302, the IPL 314 is used to communicate with the key service 345 of the secure microcontroller 340 to retrieve the key for decrypting the FSP / IP firmware 312. The key service 345 is implementation specific as long as it is provided by the same sFSP / IP firmware provider. For example, the key service 345 can be embedded in the secure microcontroller 340 (e.g., a server Secure Startup Service module (S3M) or a client Enhanced Security Engine (ESE)).

[0047] In one example implementation, the IPL 314 can set up a secure protocol and data model (SPDM) connection with the secure microcontroller 340 to utilize when transmitting a key for decrypting the FSP / IP firmware 312. The IPL 314 can be an SPDM requester, and the secure microcontroller 340 can be an SPDM responder. The IPL 314 can be supplied with a secure microcontroller certificate. In this case, the IPL 314 can verify the secure microcontroller 340 during the SPDM session setup. The messages in the SPDM session are encrypted and authenticated using a message authentication code (MAC). As a result, other entities cannot read or modify the SPDM messages in the session in a manner similar to a network transport layer security (TLS) session.

[0048] Once the SPDM session is set up between the IPL 314 and the secure microcontroller 340, the secure microcontroller 340 should verify the IPL 314. The IPL can pass a TD report (including MRTD, RTMR, and a MAC with a CPU key) to the secure microcontroller 340. The secure microcontroller 340 can verify the integrity of the TD report by checking the MAC of the TD report. Subsequently, the secure microcontroller 340 can verify the MRTD to see if the IPL 314 is authorized. After the secure microcontroller 340 verifies the IPL 314, the secure microcontroller 340 can pass the encryption key to the IPL 314 within the SPDM session.

[0049] In another example implementation, the secure microcontroller 340 may be implemented as a baseboard management controller (BMC), and the IPL 314 may communicate with a key service broker (key service 245) in the BMC. The BMC key service broker (e.g., key service 245) may use a TLS session to communicate with a remote key server 350 in a cloud environment. In one implementation, the key server 350 may authenticate the TD report / citation using a standard TDX citation verification. After the remote key server 350 verifies the TD report / citation, the remote key server 350 passes the key to the IPL 314. A network TLS session is used between the remote key server 350 and the IPL 314 via a BMC key service broker (e.g., key service 345 of the secure microcontroller 340).

[0050] At the third step 303, once the IPL 314 obtains the key, the IPL 314 can decrypt the sFSP / IP firmware 312. Subsequently, the IPL 314 can erase the key and jump to the entry point of the sFSP / IP firmware 312.

[0051] At the fourth step 304, after the sFSP / IP firmware 312 is decrypted, it can perform silicon IP 335 initialization and / or provide runtime services. In this case, the sFSP / IP firmware 312 can use SEAM calls to the TDX module 325 for register programming. In order to reduce the programming workload of capturing each MMIO / IO access, the sFSP / IP firmware 312 can pass a register programming script table to the TDX module 325 to support batch programming. Table 1 below illustrates an example of such a register script table. Table 1: Register script table

[0052] In some implementations, to support obfuscation, the IP provider (IP vendor) can add one or more "dummy entries" to the register script table. These dummy entries do not have any real impact on IP initialization or runtime workload, but they can bring some confusion to thwart any potential malicious attackers who attempt to monitor system behavior.

[0053] At the fifth step 305, the TDX module 325 may provide policy settings to prevent register programming SEAM calls from originating from any arbitrary TD. In this case, SEAM may check the RTMR and allow register programming SEAM calls from TD 310 supporting sFSP / IP firmware 312 initialization code.

[0054] Figure 4 The diagram depicts a block diagram of an IP initialization environment 400 that implements multiple TDs for silicon initialization to achieve IP protection and assurance according to an implementation of the present disclosure. In one implementation, the IP initialization environment 400 is similar to the reference Figure 3 The IP initialization environment 300 is the same as depicted. Figure 4 As shown in FIG. 4 , the IP initialization environment 400 includes an sFSP TD 410, a vendor TD 420, a LFH 430, and hardware 440. In some implementations, the components of the IP initialization environment 400 may be the same as those of the reference Figure 3 The corresponding components described and named identically are identical.

[0055] The IP initialization environment 400 illustrates an extension of a confidential computing architecture for establishing multiple TDs for secure initialization of IP firmware. For example, hardware 440 may include multiple IP blocks, including original silicon IP 442 (e.g., OEM's IP blocks) and third-party vendor IP blocks (such as vendor silicon IP 444). If a vendor seeks to protect its own IP blocks (such as vendor silicon IP 444), a separate vendor IPL 424 may be set for vendor IP firmware 422, which is different from sFSP / IP firmware 412. Multiple TDs 410, 420 may be initiated for each IP firmware 412, 422 and corresponding IPLs 414, 424. IPLs 414, 424 may each communicate with a SEAM 435 module of a LFH 430 to obtain a key for decrypting IP firmware 412, 422. The establishment of separate TDs 410, 420 may be protected from situations where there is a vulnerability in any one of the IP firmware 412, 422. In this case, this vulnerability does not affect other TD 410, 420.

[0056] Figure 5A flowchart illustrating operation 500 for performing silicon initialization to implement a confidential computing architecture for IP protection and assurance according to an implementation of the present disclosure is shown. Operation 500 (or other processes or variations and / or combinations thereof described herein) is performed under the control of one or more computer components (e.g., executable instructions, one or more computer programs, or one or more applications) configured to execute code and implemented as code. The code is stored on a computer-readable storage medium, for example, in the form of a computer program including instructions executable by one or more processors. The computer-readable storage medium is non-transitory. In some embodiments, one or more (or all) of operations 500 are performed by a boot service.

[0057] Operation 500 includes: at block 510, a processor device may execute a firmware management program to initiate a trust domain (TD) of a confidential computing architecture. In one implementation, the TD is used to provide confidentiality and integrity protection for data loaded in the TD. At block 520, the processing device may load IP firmware and an initial program loader (IPL) for the IP firmware in the TD. In one implementation, the IP firmware may correspond to an IP component and be encrypted.

[0058] Subsequently, at block 530, the processing device may obtain an IP firmware key for decrypting the IP firmware in the TD via the security arbitration module of the confidential computing architecture through the IPL. Finally, at block 540, the processing device may perform an initialization process for the IP component using the firmware in response to decrypting the IP firmware in the TD.

[0059] Where appropriate, Figure 5 Some of the illustrated operations may be repeated, combined, modified or deleted, and additional steps may also be added to the processes in various embodiments. Additionally, the steps may be performed in any suitable order without departing from the scope of the particular embodiments.

[0060] Figure 6 6 is a schematic diagram of an illustrative electronic computing device that enables a confidential computing architecture for performing silicon initialization to implement IP protection and assurance, according to some implementations. In some implementations, computing device 600 includes one or more processors 610, the one or more processors 610 including one or more processor dies (e.g., cores) 618, each processor die 618 including a hardware initialization component 664, such as for executing TD code to provide a component for performing silicon initialization to implement a confidential computing architecture for IP protection and assurance, as described with reference to Figure 1-Figure 6In some embodiments, the computing device is used to use the TD code 665 of the hardware initialization component 664 to provide a confidential computing architecture for performing silicon initialization to implement IP protection and assurance, such as Figure 1-Figure 6 provided in.

[0061] The computing device 600 may additionally include one or more of a cache 662, a graphical processing unit (GPU) 612 (which may be a hardware accelerator in some implementations), a wireless input / output (I / O) interface 620, a wired I / O interface 630, a system memory 640 (e.g., memory circuitry), a power management circuitry 650, a non-transitory storage device 660, and a network interface 670 for connecting to a network 672. The following discussion provides a brief, general description of the components that form the illustrative computing device 600. For example, the non-limiting computing device 600 may include a desktop computing device, a blade server device, a workstation, or a similar device or system.

[0062] In an embodiment, the processor core 618 is capable of executing the machine-readable instruction set 614, reading data and / or the instruction set 614 from one or more storage devices 660, and writing data to one or more storage devices 660. Those skilled in the relevant art will appreciate that the illustrated embodiments and other embodiments may be implemented using other processor-based device configurations, including portable or handheld electronic devices (e.g., smart phones), portable computers, wearable computers, consumer electronics, personal computers (“PCs”), network PCs, minicomputers, server blades, mainframe computers, and the like.

[0063] Processor core 618 may include any number of hardwired or configurable circuits, some or all of which may include a programmable and / or configurable combination of electronic components, semiconductor devices and / or logic elements that are partially or completely disposed in a PC, server or other computing system capable of executing processor-readable instructions.

[0064] The computing device 600 includes a bus or similar communications link 616 that communicatively couples and facilitates the exchange of information and / or data between various system components, including a processor core 618, a cache 662, graphics processor circuitry 612, one or more wireless I / O interfaces 620, one or more wired I / O interfaces 630, one or more storage devices 660, and / or one or more network interfaces 670. The computing device 600 may be referenced herein in the singular, but this is not intended to limit the embodiments to a single computing device 600, as in some embodiments there may be more than one computing device 600 incorporating, including, or comprising any number of communicatively coupled, collocated, or remotely networked circuits or devices.

[0065] Processor core 618 may include any number, type, or combination of currently available or future developed devices capable of executing a set of machine-readable instructions.

[0066] Processor core 618 may include (or be coupled to) but is not limited to any current or future developed single-core or multi-core processor or microprocessor, such as: one or more system on a chip (system on a chip, SOC); central processing unit (central processing unit, CPU); digital signal processor (digital signal processor, DSP); graphics processing unit (graphics processing unit, GPU); application-specific integrated circuit (application-specific integrated circuit, ASIC); programmable logic unit; field programmable gate array (field programmablegate array, FPGA); etc. Unless otherwise specified, Figure 6 The construction and operation of the various blocks shown in are of conventional design. Therefore, such blocks are not described in further detail herein, as they should be understood by those skilled in the relevant art. The bus 616 that interconnects at least some of the components of the computing device 600 may employ any currently available or future developed serial or parallel bus structure or architecture.

[0067] The system memory 640 may include a read-only memory ("ROM") 642 and a random access memory ("RAM") 646. Portions of the ROM 642 may be used to store or otherwise retain a basic input / output system ("BIOS") 644. The BIOS 644 provides basic functionality to the computing device 600 by, for example, causing the processor core 618 to load and / or execute one or more machine-readable instruction sets 614. In an embodiment, at least some of the one or more machine-readable instruction sets 614 cause at least a portion of the processor core 618 to provide, create, generate, transform, and / or function as a dedicated, specified, and particular machine, such as a word processor, a digital image acquisition machine, a media player, a gaming system, a communication device, a smart phone, and the like.

[0068] The computing device 600 may include at least one wireless input / output (I / O) interface 620. The at least one wireless I / O interface 620 may be communicatively coupled to one or more physical output devices 622 (tactile device, video display, audio output device, hard copy output device, etc.). The at least one wireless I / O interface 620 may be communicatively coupled to one or more physical input devices 624 (pointing device, touch screen, keyboard, tactile device, etc.). The at least one wireless I / O interface 620 may include any currently available or future developed wireless I / O interface. Example wireless I / O interfaces include, but are not limited to: Near field communication (NFC) and so on.

[0069] The computing device 600 may include one or more wired input / output (I / O) interfaces 630. At least one wired I / O interface 630 may be communicatively coupled to one or more physical output devices 622 (tactile device, video display, audio output device, hard copy output device, etc.). At least one wired I / O interface 630 may be communicatively coupled to one or more physical input devices 624 (pointing device, touch screen, keyboard, tactile device, etc.). The wired I / O interface 630 may include any currently available or future developed I / O interface. Example wired I / O interfaces include, but are not limited to, universal serial bus (USB), IEEE 1394 ("Firewire"), and the like.

[0070] The computing device 600 may include one or more communicatively coupled non-transitory data storage devices 660. The data storage device 660 may include one or more hard disk drives (HDD) and / or one or more solid-state storage devices (SSD). The one or more data storage devices 660 may include any current or future developed storage device, network storage device, and / or system. Non-limiting examples of such data storage devices 660 may include, but are not limited to, any current or future developed non-transitory storage device or device, such as one or more magnetic storage devices, one or more optical storage devices, one or more resistive storage devices, one or more molecular storage devices, one or more quantum storage devices, or various combinations thereof. In some implementations, the one or more data storage devices 660 may include one or more removable storage devices, such as one or more flash drives, flash memories, flash storage units, or similar devices or devices that can be communicatively coupled to and decoupled from the computing device 600.

[0071] The one or more data storage devices 660 may include an interface or controller (not shown) that communicatively couples a corresponding storage device or system to the bus 616. The one or more data storage devices 660 may store, retain, or otherwise contain machine-readable instruction sets, data structures, program modules, data stores, databases, logic structures, and / or other data useful to the processor core 618 and / or graphics processor circuitry 612 and / or one or more applications executed on or by the processor core 618 and / or graphics processor circuitry 612. In some examples, the one or more data storage devices 660 may be stored, for example, via the bus 616 or via one or more wired communication interfaces 630 (e.g., a universal serial bus (i.e., USB)), one or more wireless communication interfaces 620 (e.g., a USB), or a plurality of wireless communication interfaces 620 (e.g., a USB). Near Field Communication (ie, NFC)), and / or one or more network interfaces 670 (IEEE 802.3 or Ethernet, IEEE 802.11 or etc.) and are communicatively coupled to processor core 618.

[0072] Processor readable instruction sets 614 and other programs, applications, logical collections, and / or modules may be stored in whole or in part in system memory 640. Such instruction sets 614 may be transferred in whole or in part from one or more data storage devices 660. Instruction sets 614 may be loaded, stored, or otherwise retained in whole or in part in system memory 640 during execution by processor core 618 and / or graphics processor circuitry 612.

[0073] The computing device 600 may include a power management circuit system 650 that controls one or more operational aspects of an energy storage device 652. In an embodiment, the energy storage device 652 may include one or more primary batteries (i.e., non-rechargeable batteries) or secondary batteries (i.e., rechargeable batteries) or similar energy storage devices. In an embodiment, the energy storage device 652 may include one or more supercapacitors or ultra-supercapacitors. In an embodiment, the power management circuit system 650 may change, adjust, or control the flow of energy from an external power source 654 to the energy storage device 652 and / or to the computing device 600. The power source 654 may include, but is not limited to, a solar power system, a commercial power grid, a portable generator, an external energy storage device, or any combination thereof.

[0074] For convenience, processor core 618, graphics processor circuit system 612, wireless I / O interface 620, wired I / O interface 630, storage device 660, and network interface 670 are illustrated as being communicatively coupled to each other via bus 616, thereby providing connectivity between the components described above. In alternative embodiments, the components described above may be coupled to a bus 616 in a manner similar to that described above. Figure 6 616. For example, one or more of the components described above may be directly coupled to other components, or may be coupled to each other via one or more intermediate components (not shown). In another example, one or more of the components described above may be integrated into the processor core 618 and / or the graphics processor circuitry 612. In some embodiments, all or part of the bus 616 may be omitted, and the components may be directly coupled to each other using suitable wired or wireless connections.

[0075] The following examples relate to further embodiments. Example 1 is a processing system that facilitates a confidential computing architecture for performing silicon initialization to implement IP protection and assurance. The processing system of Example 1 includes: multiple hardware components, the multiple hardware components including intellectual property (IP) components; one or more memory modules; and a memory device that is communicatively coupled to the multiple hardware components and the one or more memory modules, the memory device being used to store platform initialization firmware, the platform initialization firmware being used to enable the processing system to: execute a firmware hypervisor to initiate a trust domain (TD) of a confidential computing architecture, wherein the TD is used to provide confidentiality and integrity protection for data loaded in the TD; load the IP firmware and an initial program loader (IPL) for the IP firmware in the TD, wherein the IP firmware corresponds to the IP component and is encrypted; obtain an IP firmware key from the IPL to decrypt the IP firmware in the TD; and in response to decrypting the IP firmware in the TD, use the IP firmware to perform an initialization process for the IP component.

[0076] In Example 2, the subject matter as described in Example 1 may optionally include: wherein the hardware initialization firmware is in accordance with the Basic Input / Output System standard. In Example 3, the subject matter as described in any of Examples 1-2 may optionally include: wherein the hardware initialization firmware is in accordance with the Unified Extensible Firmware Interface standard. In Example 4, the subject matter as described in any of Examples 1-3 may optionally include: wherein the confidential computing architecture includes at least one of the following: a Trust Domain Extension (TDX) confidential computing architecture, a Software Guard Extension (SGX) confidential computing architecture, a Secure Encrypted Virtualization Architecture (SEV) confidential computing architecture, or a Realm confidential computing architecture.

[0077] In Example 5, the subject matter as described in any of Examples 1-4 may optionally include: wherein the IP firmware key is obtained from a security arbitration module of a confidential computing architecture, wherein the security arbitration module is used to extend the IPL into a TD measurement register (MRTD), and wherein the IPL extends the IP firmware into a runtime measurement register (RTMR), and the MRTD and RTMR provide proof of the TD in a TD report. In Example 6, the subject matter as described in any of Examples 1-5 may optionally include: wherein the TD report enables a secure microcontroller of a processing system to verify the IPL in the TD. In Example 7, the subject matter as described in any of Examples 1-6 may optionally include: as part of an initialization process, the IP firmware transmits a register programming script table to the security arbitration module of the confidential computing architecture, and the register programming script table enables the security arbitration module to perform an initialization process for the IP component.

[0078] In Example 8, the subject matter of any one of Examples 1-7 may optionally include: wherein the register programming script table includes at least one pseudo register access to support obfuscation. In Example 9, the subject matter of any one of Examples 1-8 may optionally include: wherein the key is stored in a secure microcontroller of the processing system.

[0079] In Example 10, the subject matter of any of Examples 1-9 may optionally include: wherein the key is stored in a remote key service accessible by a secure microcontroller of the processing system. In Example 11, the subject matter of any of Examples 1-10 may optionally include: wherein a TD is established for each vendor of each IP component of the processing system. In Example 12, the subject matter of any of Examples 1-11 may optionally include: wherein the security arbitration module includes a policy control for enabling specialized services for the TD.

[0080] Example 13 is a method for facilitating a confidential computing architecture for performing silicon initialization to implement IP protection and assurance. The method of Example 13 may include: executing a firmware hypervisor by a processing device of a processing system to initiate a trust domain (TD) of a confidential computing architecture, wherein the TD is used to provide confidentiality and integrity protection for data loaded in the TD; loading intellectual property (IP) firmware and an initial program loader (IPL) for the IP firmware in the TD, wherein the IP firmware corresponds to an IP component of the processing system and is encrypted; obtaining an IP firmware key by the IPL to decrypt the IP firmware in the TD; and in response to decrypting the IP firmware in the TD, using the IP firmware to perform an initialization process for the IP component.

[0081] In Example 14, the subject matter as described in Example 13 may optionally include: wherein the confidential computing architecture includes at least one of the following: a Trust Domain Extension (TDX) confidential computing architecture, a Software Guard Extension (SGX) confidential computing architecture, a Secure Encrypted Virtualization Architecture (SEV) confidential computing architecture, or a Realm confidential computing architecture. In Example 15, the subject matter as described in Examples 13-14 may optionally include: wherein the IP firmware key is obtained from a security arbitration module of the confidential computing architecture, wherein the security arbitration module is used to extend the IPL into a TD measurement register (MRTD), wherein the IPL extends the IP firmware into a runtime measurement register (RTMR), the MRTD and the RTMR provide proof of the TD in a TD report, and wherein the TD report enables a secure microcontroller of the processing system to verify the IPL in the TD.

[0082] In Example 16, the subject matter as described in any of Examples 13-15 may optionally include: as part of the initialization process, the IP firmware is used to transmit a register programming script table to a security arbitration module of the confidential computing architecture, wherein the register programming script table enables the security arbitration module to perform an initialization process for the IP component.

[0083] Example 17 is a non-transitory computer-readable storage medium for facilitating a confidential computing architecture for performing silicon initialization to implement IP protection and assurance. The non-transitory computer-readable storage medium of Example 17 has executable computer program instructions stored thereon, which, when executed by one or more processors, cause the one or more processors to perform operations including: executing a firmware hypervisor by a processing device of one or more processors of a processing system to initiate a trust domain (TD) of a confidential computing architecture, wherein the TD is used to provide confidentiality and integrity protection for data loaded in the TD; loading IP firmware and an initial program loader (IPL) for the IP firmware in the TD, wherein the IP firmware corresponds to an IP component of the processing system and is encrypted; obtaining an IP firmware key by the IPL to decrypt the IP firmware in the TD; and in response to decrypting the IP firmware in the TD, using the IP firmware to perform an initialization process for the IP component.

[0084] In Example 18, the subject matter as described in Example 17 may optionally include: wherein the confidential computing architecture includes at least one of the following: a Trust Domain Extension (TDX) confidential computing architecture, a Software Guard Extension (SGX) confidential computing architecture, a Secure Encrypted Virtualization Architecture (SEV) confidential computing architecture, or a Realm confidential computing architecture. In Example 19, the subject matter as described in Examples 17-18 may optionally include: wherein the IP firmware key is obtained from a security arbitration module of the confidential computing architecture, wherein the security arbitration module is used to extend the IPL into a TD measurement register (MRTD), wherein the IPL extends the IP firmware into a runtime measurement register (RTMR), the MRTD and the RTMR provide proof of the TD in a TD report, and wherein the TD report enables a secure microcontroller to verify the IPL in the TD.

[0085] In Example 20, the subject matter as described in any of Examples 17-19 may optionally include: as part of the initialization process, the IP firmware is used to transmit a register programming script table to a security arbitration module of the confidential computing architecture, wherein the register programming script table enables the security arbitration module to perform an initialization process for the IP component.

[0086] Example 21 is a system for facilitating a confidential computing architecture for performing silicon initialization to implement IP protection and assurance. The system of Example 21 may optionally include: a memory for storing a data block; and a processor communicatively coupled to the memory, the processor for: executing a firmware manager to initiate a trust domain (TD) of the confidential computing architecture, wherein the TD is used to provide confidentiality and integrity protection for data loaded in the TD; loading intellectual property (IP) firmware and an initial program loader (IPL) for the IP firmware in the TD, wherein the IP firmware corresponds to an IP component of the system and is encrypted; obtaining an IP firmware key from the IPL to decrypt the IP firmware in the TD; and in response to decrypting the IP firmware in the TD, using the IP firmware to perform an initialization process for the IP component.

[0087] In Example 22, the subject matter as described in Example 21 may optionally include: wherein the hardware initialization firmware is in accordance with the Basic Input / Output System standard. In Example 23, the subject matter as described in any of Examples 21-22 may optionally include: wherein the hardware initialization firmware is in accordance with the Unified Extensible Firmware Interface standard. In Example 24, the subject matter as described in any of Examples 21-23 may optionally include: wherein the confidential computing architecture includes at least one of the following: a Trust Domain Extension (TDX) confidential computing architecture, a Software Guard Extension (SGX) confidential computing architecture, a Secure Encrypted Virtualization Architecture (SEV) confidential computing architecture, or a Realm confidential computing architecture.

[0088] In Example 25, the subject matter as described in any of Examples 21-24 may optionally include: wherein the IP firmware key is obtained from a security arbitration module of a confidential computing architecture, wherein the security arbitration module is used to extend the IPL into a TD measurement register (MRTD), and wherein the IPL extends the IP firmware into a runtime measurement register (RTMR), and the MRTD and RTMR provide proof of the TD in a TD report. In Example 26, the subject matter as described in any of Examples 21-25 may optionally include: wherein the TD report enables a secure microcontroller of a processing system to verify the IPL in the TD. In Example 27, the subject matter as described in any of Examples 21-26 may optionally include: as part of an initialization process, the IP firmware is used to transmit a register programming script table to the security arbitration module of the confidential computing architecture, the register programming script table enabling the security arbitration module to perform an initialization process for the IP component.

[0089] In Example 28, the subject matter of any one of Examples 21-27 can optionally include: wherein the register programming script table includes at least one pseudo register access to support obfuscation. In Example 29, the subject matter of any one of Examples 21-28 can optionally include: wherein the key is stored in a secure microcontroller of the processing system.

[0090] In Example 30, the subject matter of any of Examples 21-29 may optionally include: wherein the key is stored in a remote key service accessible by a secure microcontroller of the processing system. In Example 31, the subject matter of any of Examples 21-30 may optionally include: wherein a TD is established for each vendor of each IP component of the processing system. In Example 32, the subject matter of any of Examples 21-31 may optionally include: wherein the security arbitration module includes a policy control for enabling specialized services for the TD.

[0091] Example 33 is a device for facilitating a confidential computing architecture for performing silicon initialization to implement IP protection and assurance, the device comprising: a device for executing a firmware manager to initiate a trust domain (TD) of the confidential computing architecture, wherein the TD is used to provide confidentiality and integrity protection for data loaded in the TD; a device for loading intellectual property (IP) firmware and an initial program loader (IPL) for the IP firmware in the TD, wherein the IP firmware corresponds to an IP component and is encrypted; a device for using the IPL to obtain an IP firmware key to decrypt the IP firmware in the TD; and a device for using the IP firmware to perform an initialization process for the IP component in response to decrypting the IP firmware in the TD. In Example 34, the subject matter of Example 33 may optionally include a device further configured to perform a method as described in any one of Examples 14 to 16.

[0092] Example 35 is at least one machine-readable medium, the at least one machine-readable medium comprising a plurality of instructions that, in response to being executed on a computing device, cause the computing device to perform a method as described in any of Examples 13-16. Example 36 is a device for facilitating a confidential computing architecture for performing silicon initialization to implement IP protection and assurance, the device being configured to perform a method as described in any of Examples 13-16. Example 37 is a device for facilitating a confidential computing architecture for performing silicon initialization to implement IP protection and assurance, the device comprising means for performing a method as described in any of Examples 13-16. The details in the examples may be used anywhere in one or more embodiments.

[0093] In the above description, for the purpose of explanation, numerous specific details are set forth to provide a comprehensive understanding of the described embodiments. However, it will be apparent to those skilled in the art that embodiments may be implemented without some of these specific details. In other cases, well-known structures and devices are shown in block diagram form. Intermediate structures may exist between the illustrated components. The components described or illustrated herein may have additional inputs or outputs that are not illustrated or described.

[0094] Various embodiments may include various processes. These processes may be performed by hardware components, or may be embodied in computer programs or machine executable instructions, which may be used to cause a general or special purpose processor or logic circuit programmed with the instructions to perform these processes. Alternatively, these processes may be performed by a combination of hardware and software.

[0095] Portions of the various embodiments may be provided as a computer program product, which may include a computer-readable medium (e.g., a non-transitory computer-readable storage medium) having computer program instructions stored thereon, which may be used to program a computer (or other electronic device) for execution by one or more processors to perform processes according to certain embodiments. Computer-readable media may include, but are not limited to, a disk, an optical disk, a read-only memory (ROM), a random access memory (RAM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic or optical card, a flash memory, or other types of computer-readable media suitable for storing electronic instructions. In addition, the embodiments may also be downloaded as a computer program product, wherein the program may be transmitted from a remote computer to a requesting computer.

[0096] Many of the methods are described in their basic form, but processes may be added to or deleted from any of the methods, and information may be added to or subtracted from any of the described messages without departing from the basic scope of the present embodiment. It will be apparent to those skilled in the art that many further modifications and adaptations may be made. The specific embodiments are not provided to limit the concepts but to illustrate the concepts. The scope of the embodiments is not to be determined by the specific examples provided above, but only by the claims below.

[0097] If element "A" is said to be coupled to or coupled to element "B", element A may be directly coupled to element B or indirectly coupled, for example, through element C. When the specification or claims state that component, feature, structure, process or characteristic A "causes" component, feature, structure, process or characteristic B, this means that "A" is at least partially the cause of "B", but there may also be at least one other component, feature, structure, process or characteristic that assists in causing "B". If the specification indicates that a component, feature, structure, process or characteristic "may", "could" or "might" be included, it is not necessary that the particular component, feature, structure, process or characteristic be included. If the specification or claims mention "a or an" element, this does not mean that there is only one described element.

[0098] An embodiment is an implementation or example. References to "an embodiment," "an embodiment," "some embodiments," or "other embodiments" in the specification mean that a particular feature, structure, or characteristic described in conjunction with the embodiment is included in at least some embodiments. The various appearances of "an embodiment," "an embodiment," or "some embodiments" do not all refer to the same embodiment. It should be appreciated that in the foregoing description of the example embodiments, for the purpose of making the disclosure fluent and assisting in understanding one or more aspects of the various novel aspects, the various features are sometimes grouped together in a single embodiment, a drawing, or a description thereof. However, this method of disclosure should not be interpreted as reflecting the intention that the claimed embodiments utilize more features than those explicitly stated in each claim. On the contrary, as reflected in the appended claims, the novel aspects exist in fewer features than all the features of a single aforementioned disclosed embodiment. Thus, the claims are expressly incorporated into the specification, with each claim itself as a separate embodiment.

Claims

1. A processing system comprising: a plurality of hardware components, the plurality of hardware components comprising intellectual property (IP) components; one or more memory modules; as well as a memory device, the memory device being communicatively coupled to the plurality of hardware components and the one or more memory modules, the memory device being configured to store platform initialization firmware, the platform initialization firmware being configured to cause the processing system to: executing a firmware hypervisor to initiate a trust domain (TD) of a confidential computing architecture, wherein the TD is used to provide confidentiality and integrity protection for data loaded in the TD; Loading IP firmware and an initial program loader (IPL) for the IP firmware into the TD, wherein the IP firmware corresponds to the IP component and is encrypted; Obtaining an IP firmware key from the IPL to decrypt the IP firmware in the TD; as well as In response to decrypting the IP firmware in the TD, an initialization process for the IP component is performed using the IP firmware.

2. The processing system of claim 1, wherein: The hardware initialization firmware complies with at least one of the Basic Input / Output System standard and the Universal Extensible Firmware Interface standard.

3. The processing system of claim 1, wherein: After the IP firmware is decrypted, the IP firmware is used to provide runtime services.

4. The processing system of claim 1, wherein: The confidential computing architecture includes at least one of the following: a Trust Domain Extension (TDX) confidential computing architecture, a Software Guard Extension (SGX) confidential computing architecture, a Secure Encrypted Virtualization Architecture (SEV) confidential computing architecture, or a Realm confidential computing architecture.

5. The processing system of claim 1, wherein: The IP firmware key is obtained from a security arbitration module of the confidential computing architecture, wherein the security arbitration module is used to extend the IPL into a TD measurement register (MRTD), and wherein the IPL extends the IP firmware into a runtime measurement register (RTMR), the MRTD and the RTMR providing proof of the TD in a TD report.

6. The processing system of claim 5, wherein: The TD report enables a secure microcontroller of the processing system to verify the IPL in the TD.

7. The processing system of claim 1, wherein: As part of the initialization process, the IP firmware is used to transmit a register programming script table to a security arbitration module of the confidential computing architecture, and the register programming script table enables the security arbitration module to perform the initialization process for the IP component.

8. The processing system of claim 7, wherein: The register programming script table includes at least one pseudo register access to support obfuscation.

9. The processing system of claim 1, wherein: The key is stored in a secure microcontroller of the processing system.

10. The processing system of claim 1, wherein: The key is stored in a remote key service accessible by a secure microcontroller of the processing system.

11. The processing system of claim 1, wherein: For each vendor of each IP component of the processing system, a TD is established.

12. The processing system of claim 5, wherein: The security arbitration module includes policy controls for enabling specialized services for the TD.

13. A method comprising: Executing a firmware hypervisor by a processing device of a processing system to initiate a trust domain (TD) of a confidential computing architecture, wherein the TD is used to provide confidentiality and integrity protection for data loaded in the TD; loading intellectual property (IP) firmware and an initial program loader (IPL) for the IP firmware into the TD, wherein the IP firmware corresponds to an IP component of the processing system and is encrypted; Obtaining an IP firmware key from the IPL to decrypt the IP firmware in the TD; as well as In response to decrypting the IP firmware in the TD, an initialization process for the IP component is performed using the IP firmware.

14. The method of claim 13, wherein: The confidential computing architecture includes at least one of the following: a Trust Domain Extension (TDX) confidential computing architecture, a Software Guard Extension (SGX) confidential computing architecture, a Secure Encrypted Virtualization Architecture (SEV) confidential computing architecture, or a Realm confidential computing architecture.

15. The method of claim 13, wherein: The IP firmware key is obtained from a security arbitration module of the confidential computing architecture, wherein the security arbitration module is used to extend the IPL into a TD measurement register (MRTD), wherein the IPL extends the IP firmware into a runtime measurement register (RTMR), the MRTD and the RTMR provide proof of the TD in a TD report, and wherein the TD report enables a secure microcontroller of the processing system to verify the IPL in the TD.

16. The method of claim 13, wherein: As part of the initialization process, the IP firmware is used to transmit a register programming script table to a security arbitration module of the confidential computing architecture, and the register programming script table enables the security arbitration module to perform the initialization process for the IP component.

17. A non-transitory computer readable storage medium having executable computer program instructions stored thereon, the executable computer program instructions, when executed by one or more processors, causing the one or more processors to perform operations comprising: executing a firmware hypervisor by a processing device of one or more processors of a processing system to initiate a trust domain (TD) of a confidential computing architecture, wherein the TD is used to provide confidentiality and integrity protection for data loaded in the TD; loading IP firmware and an initial program loader (IPL) for the IP firmware into the TD, wherein the IP firmware corresponds to an IP component of the processing system and is encrypted; Obtaining an IP firmware key from the IPL to decrypt the IP firmware in the TD; as well as In response to decrypting the IP firmware in the TD, an initialization process for the IP component is performed using the IP firmware.

18. The non-transitory computer readable storage medium of claim 17, wherein: The confidential computing architecture includes at least one of the following: a Trust Domain Extension (TDX) confidential computing architecture, a Software Guard Extension (SGX) confidential computing architecture, a Secure Encrypted Virtualization Architecture (SEV) confidential computing architecture, or a Realm confidential computing architecture.

19. The non-transitory computer-readable storage medium of claim 17, wherein: The IP firmware key is obtained from a security arbitration module of the confidential computing architecture, wherein the security arbitration module is used to extend the IPL into a TD measurement register (MRTD), wherein the IPL extends the IP firmware into a runtime measurement register (RTMR), the MRTD and the RTMR provide proof of the TD in a TD report, and wherein the TD report enables a secure microcontroller to verify the IPL in the TD.

20. The non-transitory computer readable storage medium of claim 17, wherein: As part of the initialization process, the IP firmware is used to transmit a register programming script table to a security arbitration module of the confidential computing architecture, and the register programming script table enables the security arbitration module to perform the initialization process for the IP component.

Images