Early platform hardening techniques for a leaner and faster boot

Abstract

To provide a computing system, a device, a method and a program that provide early platform hardening technology for a slimmer and faster boot.SOLUTION: A method comprises the steps of: initializing a processor static random access memory (SRAM) in response to reset of a processor; assigning the SRAM to one or more security implementation operations; and triggering multithreaded execution of one or more security implementation operations before completion of a basic input / output system (BIOS) phase. The multithreaded execution is triggered independently of initialization of a dynamic RAM (DRAM).SELECTED DRAWING: Figure 9A

Description

[Technical Field]

[0001] [CROSS-REFERENCE TO RELATED APPLICATIONS] This application claims the benefit of priority to Indian Provisional Patent Application No. 202041042509, filed on September 30, 2020.

[0002] [Technical field] FIELD Embodiments relate generally to security in computing platforms, and more particularly to early platform hardening techniques for leaner and faster boot. [Background technology]

[0003] In current systems, all security enforcement is handled during the "Post Memory Phase" after DRAM (Dynamic Random Access Memory) based memory is available for chipset consumption. Therefore, the BIOS (Basic Input / Output System, e.g., boot firmware) flow has to wait for the DRAM based memory to be available, which consumes more time for security enforcement. [Brief explanation of the drawings]

[0004] Various advantages of the embodiments will become apparent to those skilled in the art upon reading the following specification and appended claims, and upon reviewing the following drawings. [Figure 1] FIG. 2 is a block diagram of an example of firmware on a computing system according to one embodiment. [Figure 2] FIG. 2 is a block diagram of an example boot architecture according to one embodiment. [Figure 3] FIG. 10 is an explanatory diagram of an example of a pre-reset boot sequence according to one embodiment. [Figure 4] FIG. 2 is an illustration of an example of memory access response times of a memory hierarchy according to one embodiment. [Figure 5]FIG. 2 is an illustration of an example of a security communication flow according to one embodiment. [Figure 6] FIG. 10 is an illustration of an example of a chipset programming flow according to one embodiment. [Figure 7] 1A and 1B are comparative explanatory diagrams illustrating an example of security initialization according to a conventional method and an example of security initialization according to an embodiment. [Figure 8] FIG. 1 is an illustration of an example of security authentication offloading according to one embodiment. [Figure 9A] 1 is a flowchart of an example method for performing silicon initialization according to one embodiment. [Figure 9B] 1 is a flowchart of an example method for performing silicon initialization according to one embodiment. [Figure 9C] 1 is a flowchart of an example method for performing silicon initialization according to one embodiment. [Figure 10] FIG. 1 is a block diagram of an example of an enhanced performance computing system according to one embodiment. [Figure 11] 1 is an illustration of an example of a semiconductor package device according to an embodiment; [Figure 12] FIG. 2 is a block diagram of an example of a processor according to one embodiment. [Figure 13] FIG. 1 is a block diagram of an example of a multiprocessor-based computing system, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0005] As more and more consumer electronic devices connect to the Internet and transfer trillions of pieces of data per second, it presents a challenge for device manufacturers to design secure platforms (considering hardware, firmware, and software) to ensure platform security.

[0006] Embodiments enable a leaner and faster boot block for modern needs by hardening the platform early, thus reducing the effort on the part of the boot loader side of the product manufacturer (e.g., original device manufacturers / ODM and / or original equipment manufacturers / OEM), ensuring a secure SoC (system on chip) boot and a secure platform.

[0007] In a typical platform, the SPI (serial peripheral interface) flash is mapped onto the top of the host processor's 4GB memory, so that after a CPU (central processing unit) reset, the boot loader code begins executing from an address just 4GB below, as decoded by the SPI flash.

[0008] A platform's BIOS (basic input output system) is typically divided into four phases of execution as shown in firmware layout 20 of FIG.

[0009] - Pre-CPU Reset - This stage occurs before the CPU is released from reset by the associated firmware component.

[0010] - Initial Boot Block Loader (IBBL) - This stage runs from shared static RAM (SRAM), which is shared by the host CPU and the security controller (e.g., CS(M)E / converged security and (manageability) engine or TXE / trusted execution engine), and is mapped into the top 4GB memory region.

[0011] - Initial Boot Block (IBB) - This stage runs from a temporary memory known as Cache as RAM (CAR).

[0012] - OEM Boot Block (OBB) - This stage runs from system DRAM.

[0013] The implementation of these phases is loosely coupled into different code blocks, and the integration of functionality is optional depending on the structure and needs of the final product. Table I below shows the various phases and their respective combinations of specified requirements. [Table 1]

[0014] In one embodiment, the FSP contains executable silicon initialization instructions. Furthermore, in existing ecosystems, due to memory limitations or unavailability of pre-initialized memory such as SRAM at boot time, fundamental infrastructure blocks for security enforcement may need to wait until DRAM is available (e.g., until the end of IBB / FSP-M, which means approximately 400 ms from reset). This in turn causes an increase in the minimum firmware code boundary, resulting in a larger SPI footprint and an over-reliance on the OBB stage / FSP-S to ensure security enforcement. Such an approach could result in a potentially compromised platform that can skip the OBB stage without significant platform boot or functionality impact. Therefore, a risk may exist in the form of SoC security.

[0015] Further components shown in firmware layout 20 include CPU microcode, p-UNIT firmware, PMC (power management controller) firmware, IPU (image processing unit) firmware, ISH (integrated sensor hub) firmware, CSME (converged security and manageability engine) firmware, EC (embedded controller), authenticated code module (ACM), trusted execution technology (TXT), and SPINOR (serial peripheral interface NOR) memory.

[0016] Furthermore, the evolution of newer, scalable platforms is making significant changes to the boot flow by reducing the role of firmware (e.g., U-boot SPL / secondary program loader) since most of the role of the OBB module can be fulfilled using an open operating system such as LINUX (e.g., replacing the OBB stage) as shown in boot architecture 22 of Figure 2. Such an architecture may improve boot reliability and boot time, among other things, by removing unnecessary code.

[0017] Because platform hardening requirements are relied upon at the OBB stage and are not integrated with silicon vendor libraries, the platform is left in a state where it may not affect the functionality of the platform or device, but the underlying security layers are disabled. Therefore, the platform may be considered an "attacker's paradise," which extends to the following scenarios:

[0018] - BIOS LOCK(BLE) is not enabled

[0019] --Case number from the National Vulnerability Database (NVD)

[0020] --- CVE-2017-3197

[0021] --- CLVA-2016-12-001

[0022] -- Attackers can modify the BIOSWE bit

[0023] -- An attacker can arbitrarily write to the SPI flash from the OS (operating system).

[0024] - Multiple vulnerabilities in the SmiFlash handler

[0025] --Case number from the National Vulnerability Database (NVD)

[0026] --- CLVA-2016-12-002

[0027] --- CVE-2017-3198

[0028] -- An attacker can escalate privileges to SMM

[0029] - FLOCKDN is not enabled

[0030] --Case number from the National Vulnerability Database (NVD)

[0031] --- CVE-2015-3692

[0032] --- A privileged attacker with console access can reflash the BIOS of an affected system to an image of their choice.

[0033] - Skip sending EOP HECI (host embedded controller interface) commands

[0034] --Case number from the National Vulnerability Database (NVD)

[0035] --- CVE-2018-4251

[0036] -- If the platform BIOS continues to operate in manufacturing mode or fails to send an EOP (End of Post) message result to the ME (Manageability Engine) and still accepts POST MEI (ME interface) messages, an attacker can send a HMR FPO (Host ME Region Flash Protection Override) MKHI (ME kernel Host Interface) command, which opens ME access and allows the attacker to modify the ME firmware by reflashing. The compromised ME firmware may even prevent a CPU reset from the next boot onwards.

[0037] [Technical issue]

[0038] Security features that are not tied to framework initialization libraries provided by silicon vendors and are made available as configurable features through any framework result in system vulnerabilities as described above. Furthermore, newer boot architectures require reduced firmware involvement, which further increases the need for early platform hardening methods provided by silicon providers that do not leave significant platform hardening needs in the hands of external or third-party vendors. Therefore, a problem in the existing ecosystem is the lack of techniques in silicon vendor libraries to harden the platform early in the boot phase and reduce platform vulnerabilities. Furthermore, there is also a lack of techniques to remove redundant code, which increases boot time, resulting in a poor user experience and inefficient system resources.

[0039] As previously mentioned, all security enforcement is currently handled during the "post-memory phase," after DRAM-based memory is available for chipset consumption. Thus, the BIOS flow must wait for DRAM-based memory to become available, which consumes more time for security enforcement. Indeed, it can be difficult for platforms to compete in meeting growing customer needs for fast response times, reduced SPI footprints, and secured platforms (e.g., free of the security breaches discussed above with respect to the OBB phase) through existing hardware and firmware initialization sequences.

[0040] Embodiments enable early hardening of the platform by security enforcement code by enabling security enforcement operations (e.g., ME operations) early in the boot process and by reconfiguring more memory at reset for a secured pre-boot environment.

[0041] First, embodiments modify the hardware to configure the package cache as SRAM, providing more pre-initialized memory at reset for the boot firmware. Second, the technique configures the ME UMA (Uniform Memory Access) area from the FSP by sending an SRAM INIT Done (SID) message, which indicates to the ME firmware that SRAM is available and the ME UMA is ready for use. Such an approach ensures that all necessary SoC security features are enabled before terminating the boot context. Furthermore, embodiments achieve faster system boot using a multi-threaded environment in the pre-boot phase, where security enforcement can run on a parallel thread along with other independent IO initialization.

[0042] Table II below shows how these technical problems are solved by the enhanced techniques described herein. [Table 2]

[0043] A break in the process evolution is the lack of visibility of this large chunk of L4 (Level 4) or LLC (Last Level Cache) memory to the boot process, which leads to inefficient use of system resources. Embodiments address this break in the memory hierarchy during the boot stage of a system by using security-enforced and verified FSP boot code to ensure a secured platform boot.

[0044] In one example, this enhancement technique allows ME UMA memory to be allocated more quickly. The equivalent of a DID (DRAM Init Done) message can be sent much earlier using SRAM memory (e.g., "SRAM Init Done (SID)"). For example, the SID can be sent to ME firmware within 100 ms of CPU reset upon power button press and within 600 ms from G3 state (e.g., Advance Configuration and Power Interface / ACPI mechanical off state). Such an approach provides more space in the IBB using FSP-M to complete all recommended SoC implementations without leaving the OBB to deal with. Finally, the OBB can be later removed for better response time and reduced SPI flash size, which enhances the user experience.

[0045] Taking advantage of the capabilities of pre-initialized memory (SRAM), which helps to scientifically reduce the attack surface, it may be possible to design early security enforcement in the "sec" stage in the UEFI BIOS or even in the "bootblock" in coreboot.

[0046] Next-generation client SoC architectures may introduce large on-package caches, enabling new uses. Access times to L4 (e.g., "Adamantine" or "ADM") caches may be even shorter than DRAM access times, which may be used to improve communication between the host CPU and the security controller. Embodiments help protect innovations in boot optimization. Having larger pre-initialized memory at reset adds value for high-end silicon, potentially increasing revenue. Making memory available at reset also helps eliminate legacy BIOS assumptions and create faster, more efficient BIOS solutions with reduced firmware stages (e.g., pre-CPU reset stage, IBBL stage, and IBB stage) for modern device use cases such as automotive IVI (in-vehicle infotainment, e.g., turning on a rearview camera in under two seconds), home and industrial robotics, etc. Thus, new market segments may become available.

[0047] Embodiments may tightly couple critical security recommendations of the SoC with firmware-required phases (e.g., IBBL and / or IBB) specially wrapped in the SoC that are provided in a silicon initialization binary (e.g., FSP-M) to ensure that the platform always adheres to the SoC recommendations. Failure to do so by skipping FSP-M will prevent the platform from booting the OS. Such an approach ultimately reduces the attack surface and provides a passive way to protect sensitive functional blocks (e.g., intellectual property blocks / IP).

[0048] Furthermore, the OBB reduction ultimately saves approximately 41% in code size, which translates to approximately 10% fewer bugs for any program. Additionally, embodiments help reduce SPI flash size for ODM / OEM designs, which reduces BOM costs. This enhanced technique also significantly improves boot performance; reducing unnecessary OBB stages makes boot 20x faster.

[0049] [Platform Changes]

[0050] Implementation may result in hardware, firmware, and visual changes.

[0051] Hardware changes:

[0052] Making the L4 cache available as part of the SRAM can be a new feature listed as an additional CPU capability in product documentation. For example, a CPUID (CPU identifier) ​​instruction or a dedicated MSR (model-specific register) read may determine whether an L4 cache accessible from the CPU function is available.

[0053] Additionally, cache sizes may vary, with product segments being smaller in the "M segment" and larger in the "P segment" (eg, a product literature document lists a set of hypotheses with new features).

[0054] Firmware changes:

[0055] Silicon manufacturers can use open source BIOS / bootloader solutions to implement embodiments.

[0056] While the assumptions of legacy initialization flow may not be applicable in embodiments, the present technique can reduce the number of underlying firmware boot stages. In fact, decompressing the final BIOS image may represent a reduction in boot stages.

[0057] Visual changes:

[0058] Avoiding platform security vulnerabilities when the BIOS / boot loader is not intended to invoke the OBB stage may have a visual signature. For example, if visual inspection and / or reverse engineering methods, such as skipping any critical security programming from the BIOS / boot loader, still do not indicate a platform vulnerability to security threats, it may be indicated that the platform already incorporates an embodiment in which the SoC integrated firmware using IBB ensures platform security.

[0059] [Implementation details]

[0060] In general, system memory requirements during the firmware / BIOS phase can be quite limited. The Security Controller / HECI1 is a PCI device that requires approximately 64MB of memory to establish the foundation for host-based communication with the Security Controller in the pre-boot environment.

[0061] The auxiliary processor core / microcontroller initializes a portion of the L4 (e.g., on an SoC base die) cache as SRAM for platform firmware use (per the requirements given above). See "Modified Pre-Reset Initialization Flow" below.

[0062] Product literature documents can capture the physical beginnings and limitations of the SRAM for firmware design.

[0063] The firmware flow can be modified so that the FSP can allocate the necessary memory for the ME UMA from SRAM-mapped memory itself without relying on DRAM-based memory and invoke a security module within the FSP to ensure a verified boot. Security enforcement can also operate in parallel because multi-core capabilities are available at process reset due to memory availability.

[0064] For security reasons, it may be necessary to build an additional security lockdown solution on top of the SRAM range. In such cases, the L4 SRAM range is disabled / locked down before booting into the OS. This disablement / lockdown cannot be overridden without a platform reset. In one embodiment, the FSP (e.g., a closed-source binary blob) handles the lockdown at the "End of Firmware" boot event.

[0065] Figure 3 shows a modified pre-reset boot sequence 24 for SRAM initialized before core reset. More specifically, Figure 3 shows a modified firmware boot flow for a system in which the L4 cache is configured as SRAM at pre-reset to optimize the firmware to adhere to SoC security recommendations.

[0066] Phase #1 relies on the following principles:

[0067] - Hardware changes to configure package cache as SRAM for firmware access

[0068] - Additional pre-initialized memory at reset for firmware to use to allocate ME UMA memory for early Security Controller communication

[0069] - The firmware flow can be independent of DRAM memory training, which takes longer to initialize (e.g., accessing an L4 cache memory range is much faster compared to a DRAM memory access).

[0070] FIG. 4 illustrates response times for various system memory accesses for memory hierarchy 26. Early firmware stages (e.g., before DRAM initialization) may be avoided to reduce the firmware footprint. For example, embodiments do not need to use cache-as-ram (CAR, e.g., “tempRAM init”) in the BIOS flow. Such an approach reduces complex assembly programming in boot loader space. FSP-T can determine to allocate the requested ME UMA memory from SRAM resources and then write the ME UMA base address to the MSEG_BASE register within approximately 100 ms of CPU reset, allowing the security module in FSP-M to further transmit the MEI (e.g., earlier in the boot flow compared to after DRAM training in the current flow). Furthermore, CAR teardown logic may be avoided. Embodiments may avoid switching between temporary memory (CAR) and persistent memory (DRAM-based) in boot loader space and drive the entire boot loader execution from SRAM-based fixed memory. In one example, DRAM initialization is performed at the end of the boot loader boot sequence to ensure that the payload or OS can use DRAM-based resources for higher memory requirements. In this process, the entire SoC security enforcement from the BIOS is decoupled from the available and used DRAM resources. Therefore, the MRC (memory reference code) does not face a bottleneck while initializing DRAM resources in the current flow.

[0071] The FSP then sends an SRAM INIT Done (SID) message indicating to the ME firmware that SRAM is available and the ME UMA is ready for use. The SRAM INIT Done message may be sent by the FSP on all boot flows.

[0072] After the FSP sends the SID message, the BIOS waits for a SID ACK (acknowledgement) message, which contains the requested "ME BIOS Action" and the BIOS acts on it as soon as possible.

[0073] Because the setup of the SID and ME UMA occurs much earlier (e.g., within about 100 ms) in the CPU reset boot flow compared to the MRC initialization that occurs in the existing flow (e.g., about 20-40 seconds on the first boot, or about 400 ms on subsequent boots), it may also help save system boot time by avoiding further MRC initialization when the "ME BIOS Action" requests a platform reset.

[0074] For example, consider an existing flow where "ME BIOS Action" is handled after MRC initialization, but the MRC cache has not yet been saved by the boot loader. Issuing a platform reset results in the FSP not finding the MRC cache on the next boot because the boot loader was used to save the MRC cache during the OBB stage. This results in a repeat of the MRC initialization, which adds approximately 20 to 40 seconds to the firmware boot time. Because the ME UMA region is configured based on DRAM resource dependencies, this waste of platform boot time results in a poor user experience. Independently configuring the ME UMA region from DRAM resources and using L4 memory as an SRAM or LLC cache avoids this additional MRC training caused by the "ME BIOS Action" reset. To meet security policies, the SRAM memory range may be locked down before booting into the operating system.

[0075] Phase #2 involves an performed verified FSP boot using the L4 cache as SRAM at reset.

[0076] An embodiment uses the design considerations described in Figures 3 and 4, which makes larger and faster memory available at reset, and modifies the firmware flow to use that pre-initialized memory, rather defining the FSP flow to ensure a secure SoC boot without relying on DRAM resources.

[0077] Additionally, embodiments use a multi-threaded environment in the pre-boot phase to achieve faster system boot where security enforcement can be performed on a parallel thread along with separate independent IO initialization.

[0078] Hardware & Firmware Design Details:

[0079] The L4 cache is accessible to the CPU as part of the SRAM.

[0080] Embodiments can use Phase #1 to overcome the limited memory available in the reset constraint, so that it is feasible to bring all cores (e.g., bootstrap processor / BSP and application processor / AP) out of reset early and allocate resources to the AP as well as the BSP to execute parallel tasks.

[0081] An embodiment disables / locks down the L4 range before booting into the OS.

[0082] Figure 3 shows a modified firmware boot flow for a system in which the L4 cache is configured as SRAM at pre-reset, the CPU is enabled at reset without memory constraints, and ensures a verified firmware boot. More pre-initialized memory is available for firmware use at reset. The firmware flow can be independent of DRAM memory training, which takes longer to initialize. Early firmware stages (e.g., before DRAM initialization) can be avoided to reduce the firmware footprint.

[0083] a) During Phase #1, an auxiliary processor core / microcontroller within the SoC initializes the L4 cache as SRAM, without requiring any core involvement.

[0084] b) More memory is available before the core is released from reset.

[0085] c) The BIOS image is loaded into SRAM even before the core comes out of reset.

[0086] d) It is not necessary to use cache-as-ram (CAR) (e.g., "tempRAM init") in the BIOS flow. Such an approach reduces complex assembly programming in the boot loader space.

[0087] e) CPU, chipset, and PCI (Peripheral Component Interconnect) enumeration can be performed early without relying on DRAM initialization; rather, SRAM is used to perform all CPU / chipset programming.

[0088] Fixes for IBBL / FSP-T:

[0089] f) Read the ME UMA SIZE (MUSZ) field in Bus0:Device22:Function0:Register0x44 [bit0:5], which indicates the memory size required for the ME. Normally, 128 MB or less of memory is allocated to the ME UMA area.

[0090] g) Partitioning significantly larger chunks of memory from the L4-SRAM buckets for ME UMA use.

[0091] h) Enter the SRAM Init Done procedure by sending an SRAM INIT Done HECI command to the ME firmware.

[0092] i) HECI SRAM Init Done completes successfully and responds with SRAM Init Done ACK to the HOST CPU.

[0093] j) Upon receiving the SID ACK, the FSP reads "ME BIOS Action."

[0094] k) If the action is to reset the platform, start again from a) above. Otherwise, the BIOS continues to POST.

[0095] l) Assign the Security Controller IMR base and limits.

[0096] Corrections for IBB / FSP-M:

[0097] Host CPU and Security Controller Communication: The BIOS continues to use SRAM-based memory resources to send security-related HECI commands and for ME device register access.

[0098] m) ChipsetInit: After the ME UMA is ready at the end of the IBBL stage, the FSP-M in the IBB stage sends the chipset initialization table to the ME firmware for PCIE related device HSIO (high speed input output) lanes and FIA (Flexible I / O Adapter) programming based on the FSP-M related policy configuration for PCIE based devices.

[0099] n) End of POST (EOP): The IBB / FSP-M sends an EOP message to the ME firmware and proceeds further after receiving a successful response to the EOP message. If the IBB / FSP-M call is skipped, the IBB does not allow the system to boot into the OS because the platform cannot boot further and no ACK is received from the ME controller for sending the EOP. If the EOP is successful, this message causes the ME firmware to exit pre-boot mode and transition to OS mode. Once the ME is in OS mode, the ME does not accept any MEI messages used in the pre-boot environment. Otherwise, the FSP-M disables the ME using a PMC (power management controller)-based IPC command to ensure that the HECI controller is not exposed after booting into the OS (e.g., the HECI controller PCI device Bus0:Device22:Function0 is visible on the PCI tree). Therefore, any MEI messages that would make the system vulnerable to attacks are not accepted. Ensuring that the EOP is transmitted within the IBB qualifies as the final action in the normal BIOS security initialization flow to ensure a verified system boot.

[0100] o) Configure ME devices: Place unused devices into D0i3 state (e.g. ACPI device state) using better platform power numbers since all HECI communication occurs before this stage.

[0101] Typically, there are three HECI devices on the PCH (Platform Controller Hub, e.g., Input / Output module). Only HECI1 is enabled, the others depend on the enabled features. When HECI1 is not operating in a healthy state (e.g., normal path), FSP-S disables HECI (e.g., via the Private CR disable register), and the BIOS first puts HECI in the D0i3 state, then in the D3 state, and then disables HECI. If the BIOS does not disable HECI, the BIOS puts the device in the D0i3 state before loading the OS.

[0102] There are SOL (Serial over Local Area Network / LAN) and USBr (Universal Serial Bus Redirection) devices presented on the PCH. Enable SOL and USBr devices only when working with the corresponding ME SKU (Stock Keeping Unit, e.g., Corporate SKU).

[0103] FIG. 5 shows the modified ME communication flow 28 within the IBB.

[0104] p) SPI Lockdown: Components in the IBB, such as the boot loader and FSP-M, work together to store the MRC cache immediately after DRAM becomes available. Such an approach helps FSP-M set the Flash Configuration Lock-Down (FLOCKDN) flash programming register before booting into the OS. Additionally, this technique allows the Flash Protected Range n (BIOS_FPRx) to prevent unauthorized SPI writes (event log, MRC cache, etc.).

[0105] q) BIOS Control Registers: The FSP-M can set BIOS control register bits such as BiosInterfaceLockDown (BILD), BIOS Lock Enable (BLE), BIOS Write Enable (BWE), and SMM BIOS Write Protection (SMM BWP).

[0106] FIG. 6 shows a modified chipset programming flow 30 within the IBB.

[0107] r) At this stage, at the end of IBB, the FSP-M has performed all possible SoC chipset programming and security communications to ensure a verified firmware boot.

[0108] s) If an OBB stage is present, the OBB stage may continue to perform further programming as follows:

[0109] - GPIO (general purpose input-output) initialization - GPIO for SoC recommended functional blocks and board related components

[0110] - Multiprocessor initialization

[0111] - Initialize the graphics device with GOP services

[0112] - Initialize block devices for booting into the OS

[0113] - PCI device enumeration

[0114] - Exposes ACPI tables

[0115] If not, firmware boot control passes to a payload, such as Linuxboot, to perform these operations after replacing the OBB stage with the payloader (e.g., phase "v" below).

[0116] t) The CAR teardown logic can also be bypassed.

[0117] u) It avoids switching between temporary (CAR) and permanent (DRAM-based) memory in bootloader space and allows the entire bootloader execution to be driven from fixed SRAM-based memory.

[0118] v) Performing DRAM initialization at the end of the boot loader boot sequence to ensure that the payload or OS can use DRAM-based resources for higher memory requirements.

[0119] w) At the end of POST service, the BIOS locks down the SRAM range to prevent any access to decode this range.

[0120] FIG. 7 shows the early implementation security initialization (eg, coreboot) flow of the legacy 32 versus the enhanced 34 with pre-initialized SRAM memory at reset.

[0121] Impact on firmware:

[0122] - Secured firmware boot even if OBB / FSP-S stage is not included in the production BIOS IFWI (Integrated Firmware / FW Image).

[0123] - Reducing OBB ultimately saves about 41% in code size, which translates to about 10% fewer bugs.

[0124] - This effort can help OEMs / ODMs reduce SPI Flash size.

[0125] - Significant boot performance improvement - On the latest Chrome platforms, boot times can be reduced by an additional 300-350ms.

[0126] - Helps design lightweight firmware that uses L4 cache as SRAM, performing minimal and essential functional blocks using FSP (e.g. SoC silicon initialization blob) and bootloader methodology to boot into the OS.

[0127] Interaction with new security technologies:

[0128] For future client CPUs, there may be an embedded security engine (ESE) that provides centralized security services. This approach of loading and authenticating the FSP into the extended L4 cache allows the authentication of the associated FSP image to be delegated to the ESE. As a result, potential flaws in the BIOS implementation of security logic can be avoided.

[0129] 8 illustrates a hardware and firmware 40 design in which security authentication is offloaded to the ESE 42. In one embodiment, the ESE 42 may be invoked for upcoming FSP state validation. If valid, the ESE 42 may pass control to the respective FSP entry point.

[0130] 9A illustrates a method 50 for performing silicon initialization. Method 50 may be implemented in one or more modules as a set of logic instructions stored in a machine or computer-readable storage medium, such as random access memory (RAM), read-only memory (ROM), programmable ROM (PROM), firmware, flash memory, etc.; in configurable logic, such as a programmable logic array (PLA), field programmable gate array (FPGA), complex programmable logic device (CPLD), etc.; in fixed-function logic hardware, using circuit technology, such as an application-specific integrated circuit (ASIC), complementary metal-oxide semiconductor (CMOS), or transistor-transistor logic (TTL) technology, etc.; or any combination thereof.

[0131] For example, computer program code for carrying out the operations shown in the present methods may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as JAVA®, SMALLTALK®, C++, etc., and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages. Furthermore, logic instructions may include assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, state setting data, configuration data for integrated circuits, state information that personalizes electronic circuits and / or other structural components native to the hardware (e.g., host processor, central processing unit / CPU, microcontroller, etc.).

[0132] An example processing block 52 provides for initializing a processor's SRAM in response to a processor reset. In one embodiment, the SRAM is located in the processor's last level cache. Further, block 52 may include reading size information from a register, and the SRAM is initialized based on the size information. In one example, block 54 allocates the SRAM for one or more security enforcement operations. Further, block 56 can trigger multi-threaded execution of one or more security enforcement operations prior to completion of the BIOS phase. In the illustrated example, multi-threaded execution is triggered independently of DRAM initialization. In one embodiment, the term "independently" refers to the ability to trigger multi-threaded execution regardless of whether DRAM initialization has occurred.

[0133] 9B shows a method 60 of operating an IBB. Method 60 may be implemented in one or more modules as a set of logical instructions stored in a machine or computer readable storage medium such as RAM, ROM, PROM, firmware, flash memory, etc., in configurable logic such as a PLA, FPGA, CPLD, etc., in fixed function logic hardware using circuit technologies such as ASIC, CMOS, or TTL technology, or any combination thereof.

[0134] An example block 62 provides for sending a notification to the security controller when SRAM initialization is complete. In one embodiment, block 64 identifies BIOS action information in an acknowledgment of the notification from the security controller. Furthermore, block 66 performs one or more actions (e.g., a reset action) according to the BIOS action information.

[0135] 9C illustrates a method 70 for operating the IBBL. Method 70 may be implemented in one or more modules as a set of logical instructions stored in a machine or computer-readable storage medium such as RAM, ROM, PROM, firmware, flash memory, etc.; in configurable logic such as a PLA, FPGA, CPLD, etc.; in fixed-function logic hardware using circuit technologies such as ASIC, CMOS, or TTL technology, or any combination thereof.

[0136] Exemplary block 72 provides for disabling SRAM before booting to the OS. In one embodiment, block 74 sends an EOP message to the security controller. Furthermore, block 76 transitions the security controller from pre-boot mode to OS mode in response to an acknowledgment of the EOP message from the security controller.

[0137] 10, there is shown a performance-enhancing computing system 110. System 110 may generally be part of an electronic device / platform having computing capabilities (e.g., personal digital assistant / PDA, notebook computer, tablet computer, convertible tablet, server), communication capabilities (e.g., smartphone), imaging capabilities (e.g., camera, camcorder), media playback capabilities (e.g., smart television / TV), wearable capabilities (e.g., watch, eyewear, headwear, footwear, jewelry), vehicle capabilities (e.g., car, truck, motorcycle), robotic capabilities (e.g., autonomous robot), Internet of Things (IoT) capabilities, etc., or any combination thereof.

[0138] In the depicted example, system 110 includes a host processor 112 (e.g., a CPU) having an integrated memory controller (IMC, which may be distributed across multiple dies) 114 coupled to system memory 116 (e.g., DRAM). In one embodiment, an IO module 118 is coupled to host processor 112. The illustrated IO module 118 communicates with, for example, a display 124 (e.g., a touchscreen, a liquid crystal display / LCD, a light emitting diode / LED display), a network controller 126 (e.g., wired and / or wireless), and a mass storage device 128 (e.g., a hard disk drive / HDD, an optical disk, a solid state drive / SSD, flash memory, etc.). System 110 may further include a graphics processor 120 (e.g., a graphics processing unit / GPU). In one embodiment, host processor 112, IO module 118, and graphics processor 120, along with auxiliary processor 130, are integrated into an SoC 132. Additionally, host processor 112 may include an LLC 134 having an SRAM 136.

[0139] In one example, SRAM 136 includes a set of executable silicon initialization instructions (e.g., FSP) that, when executed by auxiliary processor 130, cause computing system 110 and / or auxiliary processor 130 to perform one or more aspects of method 50 ( FIG. 9A ), method 60 ( FIG. 9B ), and / or method 70 ( FIG. 9C ) previously discussed. Accordingly, auxiliary processor 130 can initialize SRAM 136 in response to a reset of SoC 132, allocate SRAM 136 to one or more security enforcement operations, and trigger multi-threaded execution of one or more security enforcement operations prior to completion of the BIOS phase. Furthermore, multi-threaded execution may be triggered independently of initialization of system memory 116 (e.g., DRAM).

[0140] FIG. 11 illustrates a semiconductor device 140 (e.g., a chip and / or package including an auxiliary processor). The illustrated device 140 includes one or more substrates 142 (e.g., silicon, sapphire, gallium arsenide) and logic 144 (e.g., transistor arrays and other integrated circuit / IC components) coupled to the substrate 142. In one embodiment, the logic 144 implements one or more aspects of the previously discussed method 50 ( FIG. 9A ), method 60 ( FIG. 9B ), and / or method 70 ( FIG. 9C ). Accordingly, the logic 144 initializes SRAM of a processor (e.g., a host processor) in response to a processor reset, allocates the SRAM to one or more security enforcement operations, and triggers multi-threaded execution of the security enforcement operations prior to completion of the BIOS phase. Furthermore, the multi-threaded execution may be triggered independently of the initialization of DRAM initialization.

[0141] Logic 144 may be implemented at least in part in configurable logic or fixed-function hardware logic. In one example, logic 144 includes transistor channel regions disposed (e.g., buried) within substrate 142. Thus, the interface between logic 144 and substrate 142 need not be an abrupt junction. Logic 144 may also be considered to include an epitaxial layer grown on an initial wafer of substrate 142.

[0142] Figure 12 illustrates a processor core 200 according to one embodiment. Processor core 200 may be the core of any type of processor, such as a microprocessor, embedded processor, digital signal processor (DSP), network processor, or other device that executes code. Although only one processor core 200 is shown in Figure 12, a processing element may instead include two or more processor cores 200 as shown in Figure 12. Processor core 200 may be a single-threaded core, or, in at least one embodiment, processor core 200 may be multithreaded in that it may include two or more hardware thread contexts (or "logical processors") per core.

[0143] FIG. 12 also shows memory 270 coupled to processor core 200. Memory 270 may be any of a wide variety of memories (including various layers of a memory hierarchy) known or otherwise available to those skilled in the art. Memory 270 may include one or more code 213 instructions executed by processor core 200, where code 213 may implement method 50 (FIG. 9A), method 60 (FIG. 9B), and / or method 70 (FIG. 9C) discussed above. Processor core 200 follows the program sequence of instructions represented by code 213. Each instruction enters front-end section 210 and may be processed by one or more decoders 220. Decoder 220 may generate as its output micro-operations, such as fixed-width micro-operations in a predetermined format, or other instructions, micro-instructions, or control signals that reflect the original code instructions. The example front-end portion 210 further includes register renaming logic 225 and scheduling logic 230, which generally allocate resources and queue operations corresponding to the translation instructions for execution.

[0144] Processor core 200 is shown to include execution logic 250 having a set of execution units 255-1 through 255-N. Some embodiments may include multiple execution units dedicated to a particular function or set of functions. Other embodiments may include only one execution unit or one execution unit capable of performing a particular function. The example execution logic 250 performs operations specified by code instructions.

[0145] After completing execution of the operation specified by the code instruction, back-end logic 260 retires the instruction of code 213. In one embodiment, processor core 200 enables out-of-order execution but requires in-order retirement of instructions. Retirement logic 265 can take various forms known to those skilled in the art (e.g., a reorder buffer, etc.). In this manner, processor core 200 is transformed during execution of code 213 in terms of at least the outputs generated by the decoder, the hardware registers and tables utilized by register renaming logic 225, and any registers (not shown) modified by execution logic 250.

[0146] 12, a processing element may include other elements on a chip with processor core 200. For example, a processing element may include memory control logic along with processor core 200. A processing element may include I / O control logic and / or may include I / O control logic integrated with memory control logic. A processing element may also include one or more caches.

[0147] 13, a block diagram of an embodiment of a computing system 1000 is shown, according to one embodiment. Shown in FIG. 13 is a multiprocessor system 1000 including a first processing element 1070 and a second processing element 1080. While two processing elements 1070 and 1080 are shown, it should be understood that an embodiment of system 1000 may include only one such processing element.

[0148] System 1000 is shown as a point-to-point interconnect system, with a first processing element 1070 and a second processing element 1080 coupled via a point-to-point interconnect 1050. It should be understood that any or all of the interconnects shown in Figure 13 may be implemented as multi-drop buses rather than point-to-point interconnects.

[0149] 13, each of the processing elements 1070 and 1080 may be a multi-core processor including first and second processor cores (i.e., processor cores 1074a and 1074b, and processor cores 1084a and 1084b). Such cores 1074a, 1074b, 1084a, and 1084b may be configured to execute instruction code in a manner similar to that discussed above in connection with FIG.

[0150] Each processing element 1070, 1080 may include at least one shared cache 1896a, 1896b. The shared cache 1896a, 1896b may store data (e.g., instructions) used by one or more components of the processor, such as cores 1074a, 1074b and 1084a, 1084b, respectively. For example, the shared cache 1896a, 1896b may locally cache data stored in memory 1032, 1034 for faster access by the components of the processor. In one or more embodiments, the shared cache 1896a, 1896b may include one or more intermediate level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other level caches, a last level cache (LLC), and / or a combination thereof.

[0151] While only two processing elements 1070, 1080 are shown, it should be understood that the scope of the embodiments is not so limited. In other embodiments, one or more additional processing elements may be present within a given processor. Alternatively, one or more of the processing elements 1070, 1080 may be elements other than processors, such as accelerators or field-programmable gate arrays. For example, the additional processing elements may include an additional processor that is the same as the first processor 1070, an additional processor that is heterogeneous or asymmetric with respect to the first processor 1070, an accelerator (e.g., a graphics accelerator or digital signal processing (DSP) unit), a field-programmable gate array, or any other processing element. There may be various differences between the processing elements 1070, 1080 in terms of a spectrum of metrics of merit, including architecture, microarchitecture, thermal, power consumption characteristics, etc. These differences may effectively manifest as asymmetries and heterogeneities between the processing elements 1070, 1080. In at least one embodiment, the various processing elements 1070, 1080 may reside within the same die package.

[0152] The first processing element 1070 may further include memory controller logic (MC) 1072 and point-to-point (PP) interfaces 1076 and 1078. Similarly, the second processing element 1080 may include MC 1082 and PP interfaces 1086 and 1088. As shown in FIG. 13 , MCs 1072 and 1082 couple the processors to their respective memories, i.e., memories 1032 and 1034, which may be part of main memory locally attached to the respective processors. While MCs 1072 and 1082 are shown as integrated into the processing elements 1070, 1080, in alternative embodiments, the MC logic may be separate logic external to the processing elements 1070, 1080 rather than integrated therein.

[0153] First processing element 1070 and second processing element 1080 may be coupled to I / O subsystem 1090 via PP interconnects 1076 and 1086, respectively. As shown in FIG. 13 , I / O subsystem 1090 includes PP interfaces 1094 and 1098. Additionally, I / O subsystem 1090 includes interface 1092 that couples I / O subsystem 1090 to high-performance graphics engine 1038. In one embodiment, bus 1049 may be used to couple graphics engine 1038 to I / O subsystem 1090. Alternatively, a point-to-point interconnect may couple these components.

[0154] I / O subsystem 1090 may in turn be coupled to a first bus 1016 via an interface 1096. In one embodiment, first bus 1016 may be a bus such as a Peripheral Component Interconnect (PCI) bus, or a PCI Express bus or other third generation I / O interconnect bus, although the scope of the embodiment is not so limited.

[0155] As shown in FIG. 13, various I / O devices 1014 (e.g., biometric scanner, speaker, camera, sensors) may be coupled to a first bus 1016, along with a bus bridge 1018 that may couple the first bus 1016 to a second bus 1020. In one embodiment, the second bus 1020 may be a low pin count (LPC) bus. Various devices may be coupled to the second bus 1020, including, for example, in one embodiment, a keyboard / mouse 1012, a communication device 1026, and a data storage unit 1019, such as a disk drive or other mass storage device, that may include code 1030. The example code 1030 may implement method 50 (FIG. 9A), method 60 (FIG. 9B), and / or method 70 (FIG. 9C), previously discussed, and may be similar to code 213 (FIG. 12), previously discussed. Additionally, an audio I / O 1024 may be coupled to a second bus 1020 and a battery 1010 may provide power to the computing system 1000 .

[0156] It should be noted that other embodiments are possible. For example, instead of the point-to-point architecture of Figure 13, the system may implement a multi-drop bus or other such communication topology. Furthermore, the elements of Figure 13 may instead be partitioned using more or fewer integrated chips than shown in Figure 13.

[0157] [Further notes and examples]

[0158] Example 1 includes a computing system including a network controller, a system memory including dynamic random access memory (DRAM), and a system-on-chip (SoC) coupled to the network controller and the DRAM, the SoC including an auxiliary processor and a host processor, the host processor including static random access memory (SRAM), the SRAM including a set of executable silicon initialization instructions that, when executed by the auxiliary processor, cause the computing system to initialize the SRAM in response to a reset of the SoC, allocate the SRAM to one or more security enforcement operations, and trigger multi-threaded execution of the one or more security enforcement operations before completion of a basic input / output system (BIOS) phase, the multi-threaded execution being triggered independently of the initialization of the DRAM.

[0159] Example 2 includes the computing system of example 1, wherein the SRAM is located in a last level cache of the host processor.

[0160] Example 3 includes the computing system of Example 1, further including a register, wherein the silicon initialization instruction, when executed, further causes the computing system to read size information from the register, and the SRAM is initialized based on the size information.

[0161] Example 4 includes the computing system of Example 1, wherein the SoC further includes a security controller, and the silicon initialization instructions, when executed, further cause the computing system to: send a notification to the security controller when initialization of the SRAM is complete; identify BIOS action information in an acknowledgment of the notification from the security controller; and perform one or more operations according to the BIOS action information.

[0162] Example 5 includes the computing system of Example 1, further including a security controller, wherein the silicon initialization instructions, when executed, further cause the computing system to send an end-of-POST (EOP) message to the security controller and, in response to an acknowledgment of the EOP message from the security controller, transition the security controller from a pre-boot mode to an operating system mode.

[0163] Example 6 includes the computing system of any one of Examples 1-5, wherein the silicon initialization instructions, when executed, further cause the computing system to disable the SRAM prior to booting to an operating system.

[0164] Example 7 includes a semiconductor device including one or more substrates and logic coupled to the one or more substrates, the logic being at least partially implemented in one or more of configurable logic or fixed-function hardware logic, the logic coupled to the one or more substrates initializing static random access memory (SRAM) of a processor in response to a reset of the processor, allocating the SRAM to one or more security enforcement operations, and triggering multi-threaded execution of the one or more security enforcement operations prior to completion of a basic input / output system (BIOS) phase, the multi-threaded execution being triggered independently of dynamic RAM (DRAM) initialization.

[0165] Example 8 includes the apparatus of example 7, wherein the SRAM is located in a last level cache of the processor.

[0166] Example 9 includes the apparatus of example 7, wherein the logic coupled to the one or more substrates reads size information from a register, and the SRAM is initialized based on the size information.

[0167] Example 10 includes the apparatus of Example 7, wherein the logic coupled to the one or more boards sends a notification to a security controller when initialization of the SRAM is complete, identifies BIOS action information in an acknowledgment of the notification from the security controller, and takes one or more actions according to the BIOS action information.

[0168] Example 11 includes the apparatus of Example 7, wherein the logic coupled to the one or more boards sends an end-of-POST (EOP) message to a security controller and, in response to an acknowledgment of the EOP message from the security controller, transitions the security controller from a pre-boot mode to an operating system mode.

[0169] Example 12 includes the apparatus of any one of Examples 7-11, wherein the logic coupled to the one or more boards disables the SRAM prior to booting to an operating system.

[0170] Example 13 includes the device of any one of Examples 7-12, wherein the logic coupled to the one or more substrates includes a transistor channel region disposed within the one or more substrates.

[0171] Example 14 includes at least one computer-readable storage medium including a set of executable silicon initialization instructions that, when executed by a computing system, cause the computing system to initialize static random access memory (SRAM) of a processor in response to a reset of the processor, allocate the SRAM to one or more security enforcement operations, and trigger multi-threaded execution of the one or more security enforcement operations prior to completion of a basic input / output system (BIOS) phase, the multi-threaded execution being triggered independently of dynamic RAM (DRAM) initialization.

[0172] Example 15 includes at least one computer-readable storage medium as described in Example 14, wherein the SRAM is located in a last level cache of the processor.

[0173] Example 16 includes at least one computer-readable storage medium as described in Example 14, wherein the silicon initialization instructions, when executed, further cause the computing system to read size information from a register, and the SRAM is initialized based on the size information.

[0174] Example 17 includes at least one computer-readable storage medium of Example 14, wherein the silicon initialization instructions, when executed, further cause the computing system to: send a notification to a security controller when initialization of the SRAM is complete; identify BIOS action information in an acknowledgment of the notification from the security controller; and perform one or more operations according to the BIOS action information.

[0175] Example 18 includes at least one computer-readable storage medium of any one of Examples 14 to 18, wherein the silicon initialization instructions, when executed, further cause the computing system to send an end-of-POST (EOP) message to a security controller and, in response to an acknowledgment of the EOP message from the security controller, transition the security controller from a pre-boot mode to an operating system mode.

[0176] Example 19 includes at least one computer-readable storage medium as described in Example 14, wherein the silicon initialization instructions, when executed, further cause the computing system to disable the SRAM prior to booting to an operating system.

[0177] Example 20 includes a method including initializing static random access memory (SRAM) of a processor in response to a reset of the processor; allocating the SRAM to one or more security enforcement operations; and triggering multi-threaded execution of the one or more security enforcement operations prior to completion of a basic input / output system (BIOS) phase, the multi-threaded execution being triggered independently of dynamic RAM (DRAM) initialization.

[0178] Example 21 includes the method of example 20, wherein the SRAM is located in a last level cache of the processor.

[0179] Example 22 includes the method of example 20, further including reading size information from a register, wherein the SRAM is initialized based on the size information.

[0180] Example 23 includes the method of Example 20, further including sending a notification to a security controller when initialization of the SRAM is complete; identifying BIOS action information in an acknowledgment of the notification from the security controller; and performing one or more operations according to the BIOS action information.

[0181] Example 24 includes the method of Example 20, further including sending an end-of-POST (EOP) message to a security controller, and transitioning the security controller from a pre-boot mode to an operating system mode in response to an acknowledgment of the EOP message from the security controller.

[0182] Example 25 includes the method of any one of Examples 20-24, further including disabling the SRAM before booting to an operating system.

[0183] Example 26 includes a means for carrying out the method of any one of Examples 20 to 25.

[0184] Embodiments are applicable for use with all types of semiconductor integrated circuit (“IC”) chips. Examples of these IC chips include, but are not limited to, processors, controllers, chipset components, programmable logic arrays (PLAs), memory chips, network chips, systems-on-chips (SoCs), SSD / NAND controller ASICs, etc. Additionally, in some of the drawings, signal conductor lines are represented as lines. Some may differ to indicate more component signal paths, have numerical labels to indicate multiple component signal paths, and / or have arrows at one or more ends to indicate the primary information flow direction. However, this should not be construed as limiting. Rather, such additional detail may be used in connection with one or more exemplary embodiments to facilitate easier understanding of the circuit. Any represented signal line, whether or not carrying further information, may actually include one or more signals that may travel in multiple directions and may be implemented with any suitable type of signaling, e.g., digital or analog lines implemented in differential pairs, fiber optic lines, and / or single-ended lines.

[0185] Although example sizes / models / values / ranges may be given, embodiments are not limited to the same. As manufacturing technologies (e.g., photolithography) mature over time, it is expected that devices of smaller sizes will be manufacturable. Furthermore, well-known power / ground connections to IC chips and other components may or may not be shown in the figures for ease of illustration and discussion and so as not to obscure certain aspects of the embodiments. Furthermore, configurations may be shown in block diagram form to avoid obscuring the embodiments, and in consideration of the fact that details regarding the implementation of such block diagram configurations will vary greatly depending on the computing system on which the embodiments are implemented; i.e., such details should be within the purview of one skilled in the art. Where specific details (e.g., circuits) are described to explain example embodiments, it should be apparent to one skilled in the art that the embodiments can be practiced without these specific details or with variations thereof. Therefore, this description should be considered illustrative and not limiting.

[0186] The term "coupled" may be used herein to refer to any type of direct or indirect relationship between the components in question and may apply to electrical, mechanical, fluid, optical, electromagnetic, electromechanical, or other connections. Additionally, the terms "first," "second," etc. may be used herein merely for ease of discussion and do not have a particular temporal or chronological meaning unless otherwise indicated.

[0187] As used in this application and in the claims, a list of items joined by the term "one or more of" may mean any combination of the listed terms. For example, the phrase "one or more of A, B, or C" may mean A, B, C, A and B, A and C, B and C, or A, B, and C.

[0188] Those skilled in the art will appreciate from the foregoing description that the broad approach of the embodiments can be implemented in a variety of forms. Thus, while the embodiments have been described with reference to specific examples thereof, the true scope of the embodiments should not be so limited, as other modifications will become apparent to those skilled in the art upon study of the drawings, the specification, and the following claims.

Claims

1. 1. A computing system comprising: A network controller; a system memory including dynamic random access memory (DRAM); a system on chip (SoC) coupled to the network controller and the DRAM, the SoC including an auxiliary processor and a host processor; The host processor includes a static random access memory (SRAM), the SRAM including a set of executable silicon initialization instructions that, when executed by the auxiliary processor, provide the computing system with: initializing the SRAM in response to a reset of the SoC; allocating the SRAM to one or more security enforcement operations; triggering multi-threaded execution of the one or more security enforcement operations prior to completion of a basic input / output system (BIOS) phase, the multi-threaded execution being triggered independently of the initialization of the DRAM; The computing system, wherein the SRAM is located in a last level cache of the host processor.

2. 10. The computing system of claim 1, further comprising a register, wherein the silicon initialization instruction, when executed, further causes the computing system to read size information from the register, and wherein the SRAM is initialized based on the size information.

3. The SoC further includes a security controller, and the silicon initialization instructions, when executed, further instruct the computing system to: sending a notification to the security controller when the initialization of the SRAM is complete; Identifying BIOS action information in an acknowledgement of the notification from the security controller; Perform one or more actions according to the BIOS action information.

3. The computing system of claim 1 or 2, which causes the following:

4. a security controller, wherein the silicon initialization instructions, when executed, further instruct the computing system to: Sending an End of POST (EOP) message to the security controller; transitioning the security controller from a pre-boot mode to an operating system mode in response to an acknowledgement of the EOP message from the security controller; 3. The computing system of claim 1 or 2, which causes the following:

5. 5. The computing system of claim 1, wherein the silicon initialization instructions, when executed, further cause the computing system to disable the SRAM before booting into an operating system.

6. A semiconductor device, one or more substrates; logic coupled to the one or more substrates; The logic is at least partially implemented in one or more of configurable logic or fixed function hardware logic, and the logic coupled to the one or more substrates comprises: initializing a static random access memory (SRAM) of a processor in response to a reset of said processor; allocating the SRAM to one or more security enforcement operations; triggering multi-threaded execution of the one or more security enforcement operations prior to completion of a basic input / output system (BIOS) phase, the multi-threaded execution being triggered independently of dynamic RAM (DRAM) initialization; The apparatus, wherein the SRAM is located in a last level cache of the processor.

7. 7. The apparatus of claim 6, wherein the logic coupled to the one or more substrates reads size information from a register, and the SRAM is initialized based on the size information.

8. The logic coupled to the one or more substrates includes: sending a notification to a security controller when the initialization of the SRAM is complete; Identifying BIOS action information in an acknowledgement of the notification from the security controller; performing one or more actions according to the BIOS action information; 8. Apparatus according to claim 6 or 7.

9. The logic coupled to the one or more substrates includes: Sending an End of POST (EOP) message to the security controller; transitioning the security controller from a pre-boot mode to an operating system mode in response to an acknowledgment of the EOP message from the security controller; 8. Apparatus according to claim 6 or 7.

10. 10. The apparatus of claim 6, wherein the logic coupled to the one or more boards disables the SRAM before booting to an operating system.

11. 10. The apparatus of claim 6, wherein the logic coupled to the one or more substrates comprises a transistor channel region disposed within the one or more substrates.

12. 1. A computer program comprising a set of executable silicon initialization instructions, the silicon initialization instructions, when executed by a computing system, causing the computing system to: initializing a static random access memory (SRAM) of a processor in response to a reset of said processor; allocating the SRAM to one or more security enforcement operations; triggering multi-threaded execution of the one or more security enforcement operations prior to completion of a basic input / output system (BIOS) phase, the multi-threaded execution being triggered independently of dynamic RAM (DRAM) initialization; The SRAM is located in a last level cache of the processor.

13. 13. The computer program product of claim 12, wherein the silicon initialization instruction, when executed, further causes the computing system to read size information from a register, and wherein the SRAM is initialized based on the size information.

14. The silicon initialization instructions, when executed, further cause the computing system to: sending a notification to a security controller when the initialization of the SRAM is complete; Identifying BIOS action information in an acknowledgement of the notification from the security controller; Perform one or more actions according to the BIOS action information.

14. A computer program product according to claim 12 or 13, which causes the computer to:

15. The silicon initialization instructions, when executed, further cause the computing system to: Sending an End of POST (EOP) message to the security controller; transitioning the security controller from a pre-boot mode to an operating system mode in response to an acknowledgement of the EOP message from the security controller; 14. A computer program product according to claim 12 or 13, which causes the computer to:

16. 16. The computer program product of claim 12, wherein the silicon initialization instructions, when executed, further cause the computing system to disable the SRAM prior to booting into an operating system.

17. initializing a static random access memory (SRAM) of a processor in response to a reset of said processor; allocating the SRAM to one or more security enforcement operations; triggering multi-threaded execution of the one or more security enforcement operations prior to completion of a basic input / output system (BIOS) phase, the multi-threaded execution being triggered independently of dynamic RAM (DRAM) initialization; The method, wherein the SRAM is located in a last level cache of the processor.

18. 18. The method of claim 17, further comprising the step of: reading size information from a register, wherein the SRAM is initialized based on the size information.

19. sending a notification to a security controller when the initialization of the SRAM is complete; identifying BIOS action information in an acknowledgement of the notification from the security controller; performing one or more actions according to the BIOS action information; 19. The method of claim 17 or 18, further comprising:

20. sending an end-of-POST (EOP) message to the security controller; transitioning the security controller from a pre-boot mode to an operating system mode in response to an acknowledgment of the EOP message from the security controller; 19. The method of claim 17 or 18, further comprising:

21. 21. The method of any one of claims 17 to 20, further comprising disabling the SRAM before booting into an operating system.

22. A computer-readable storage medium storing a computer program according to any one of claims 12 to 16.

Images