Firmware rollback prevention

Abstract

A platform security processor is activated and reads a set of write-once storage bits to obtain a minimum security patch level (SPL). The security processor then verifies that a table SPL of a firmware security table is greater than or equal to the minimum SPL. The firmware security table includes a plurality of firmware identifiers for firmware code modules, and a plurality of check SPL values ​​are each associated with a corresponding one of the firmware identifiers. The security processor verifies the SPL values ​​in the plurality of firmware code modules by, for each firmware code module, accessing the module to obtain its firmware SPL value and checking whether the corresponding firmware SPL value is equal to or greater than the corresponding check SPL value in the firmware security table.

Description

Background Art

[0001] When firmware is released for new computing products, vulnerabilities may be discovered after the product is available. When vulnerabilities are discovered, they can be mitigated, where possible, through hardware, firmware, and / or software updates. In such cases, if the vulnerability is severe and addressable through software or firmware, it is desirable to implement a revocation mechanism so that the software or firmware version deemed vulnerable is not allowed to execute on the system. In such cases, an in-field upgrade of the software or firmware is necessary to maintain functionality.

[0002] Firmware anti-rollback features have been developed to manage the security of firmware upgrades. Some anti-rollback features use write-once memory bits, such as one-time programmable fuses, to track authorized firmware version numbers. However, these solutions typically have a limited number of one-time programmable fuses available. Furthermore, due to the number of firmware updates that occur in complex computing platforms, these solutions require a large number of write-once memory bits. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Figure 1 An accelerated processing unit (APU) including an anti-rollback safety feature according to some embodiments is shown in block diagram form.

[0004] Figure 2 A more detailed view of a PSP according to some embodiments is shown in block diagram form.

[0005] Figure 3 A process for verifying and loading firmware according to some embodiments is shown in flowchart form.

[0006] Figure 4 Another process for verifying and loading firmware and software according to some embodiments is shown in flowchart form.

[0007] Figure 5 A firmware security table (FST) according to some embodiments is shown in table form.

[0008] Figure 6 A diagram of firmware modules according to some embodiments is shown.

[0009] In the following description, the same reference numerals are used in different drawings to indicate similar or identical items. Unless otherwise specified, the term "coupled" and its associated verb forms include direct and indirect electrical connections by methods known in the art, and unless otherwise specified, any description of a direct connection implies an alternative embodiment using an appropriate indirect electrical connection form. Specific implementation plan

[0010] A method is provided for verifying firmware of a computing platform. The method includes booting a security processor and, at the security processor, reading a set of write-once storage bits to obtain a minimum security patch level (SPL). The method verifies that a table SPL of a firmware security table is greater than or equal to the minimum SPL, the firmware security table including a plurality of firmware identifiers for firmware code modules, and a plurality of check SPL values ​​each associated with a corresponding one of the firmware identifiers. The method further verifies the plurality of firmware code modules by, for each firmware code module, (a) accessing each corresponding firmware module and obtaining a corresponding firmware SPL value, (b) accessing the firmware security table to obtain a corresponding one of the check SPL values, and (c) checking whether the corresponding firmware SPL value is equal to or greater than the corresponding check SPL value.

[0011] A data processing platform includes a non-volatile memory and a system-on-chip coupled to the non-volatile memory. The system-on-chip includes: a processor having one or more processing cores; and a security processor including a microcontroller core, a set of write-once memory bits coupled to the microcontroller core, a random access memory (RAM) coupled to the microcontroller core, and a secure boot read-only memory (ROM) coupled to the microcontroller core. The security processor is operable to boot the security processor and read the set of write-once memory bits to obtain a minimum security patch level (SPL). The security processor verifies that a table SPL of a firmware security table is greater than or equal to the minimum SPL, the firmware security table including multiple firmware identifiers for firmware code modules, and multiple check SPL values ​​each associated with a corresponding one of the firmware identifiers. The security processor also verifies the multiple firmware code modules by: for each firmware code module, (a) accessing each corresponding firmware module and obtaining a corresponding firmware SPL value, (b) accessing the firmware security table to obtain a corresponding one of the check SPL values, and (c) checking whether the corresponding firmware SPL value is equal to or greater than the corresponding check SPL value.

[0012] A security processor includes a microcontroller core, a set of write-once memory bits coupled to the microcontroller core, a RAM coupled to the microcontroller core, and a secure boot ROM coupled to the microcontroller core. The security processor operates to boot the security processor and read the set of write-once memory bits to obtain a minimum SPL. The security processor verifies that a table SPL of a firmware security table is greater than or equal to the minimum SPL, the firmware security table including a plurality of firmware identifiers for firmware code modules, and a plurality of check SPL values ​​each associated with a corresponding one of the firmware identifiers. The security processor further verifies the plurality of firmware code modules by, for each firmware code module, (a) accessing each corresponding firmware module and obtaining a corresponding firmware SPL value, (b) accessing the firmware security table to obtain a corresponding one of the check SPL values, and (c) checking whether the corresponding firmware SPL value is equal to or greater than the corresponding check SPL value.

[0013] One or more tangible, non-transitory computer-readable media holds a program product comprising instructions executable by a security processor. The instructions are executable to boot the security processor and, at the security processor, read a set of write-once storage bits to obtain a minimum security patch level (SPL). The instructions are further executable to verify that a table SPL of a firmware security table is greater than or equal to the minimum SPL, the firmware security table comprising a plurality of firmware identifiers for firmware code modules, and a plurality of check SPL values ​​each associated with a corresponding one of the firmware identifiers. The instructions are further executable to verify the plurality of firmware code modules by, for each firmware code module, (a) accessing each corresponding firmware module and obtaining a corresponding firmware SPL value, (b) accessing the firmware security table to obtain a corresponding one of the check SPL values, and (c) checking whether the corresponding firmware SPL value is equal to or greater than the corresponding check SPL value.

[0014] Figure 1 An accelerated processing unit (APU) 100 including an anti-rollback safety feature according to some embodiments is shown in block diagram form. The APU 100 is implemented as a system on a chip (SoC), which can be part of a variety of host data processing platforms. Although an APU is shown in this embodiment, other data processing platforms such as a central processing unit (CPU) or a graphics processing unit (GPU) can also be used. The APU 100 generally includes a CPU core complex 110, a graphics core 120, a set of display engines 130, a memory management center 140, a data fabric 150, a set of peripheral device controllers 160, a set of peripheral bus controllers 170, a system management unit (SMU) 180, a platform security processor (PSP) 210, a flash memory 220, and a set of storage controllers 190.

[0015] The CPU core complex 110 includes a CPU core 112 and a CPU core 114. In this example, the CPU core complex 110 includes two CPU cores, but in other embodiments, the CPU core complex 110 may include any number of CPU cores. Each of the CPU cores 112 and 114 is bidirectionally connected to a system management network (SMN) 145 forming a control fabric and bidirectionally connected to a data fabric 150, and is capable of providing memory access requests to the data fabric 150. Each of the CPU cores 112 and 114 may be a single core or may be a core complex having two or more single cores that share certain resources, such as cache.

[0016] The graphics core 120 is a high-performance graphics processing unit (GPU) capable of performing graphics operations such as vertex processing, fragment processing, shading, texture fusion, etc. in a highly integrated and parallel manner. The graphics core 120 is bidirectionally connected to the SMN 145 and to the data fabric 150, and is capable of providing memory access requests to the data fabric 150. In this regard, the APU 100 may support a unified memory architecture in which the CPU core complex 110 and the graphics core 120 share the same memory space, or a memory architecture in which the CPU core complex 110 and the graphics core 120 share a portion of the memory space, while the graphics core 120 also uses dedicated graphics memory that is not accessible to the CPU core complex 110.

[0017] Display engine 130 renders and rasterizes objects generated by graphics core 120 for display on a monitor. Graphics core 120 and display engine 130 are bidirectionally connected to a common memory management hub 140 for unified translation into appropriate addresses in memory, and memory management hub 140 is bidirectionally connected to data fabric 150 for generating such memory accesses and receiving read data back from the memory system.

[0018] The data fabric 150 includes a crossbar switch for routing memory access requests and memory responses between any memory access agent and the memory controller 190. The data fabric also includes a system memory map defined by the basic input / output system (BIOS) for determining the destination of memory accesses based on the system configuration and provides buffering for each virtual connection.

[0019] Peripheral controllers 160 include a USB controller 162 and a Serial Advanced Technology Attachment (SATA) interface controller 164, each of which is bidirectionally connected to system hub 166 and bidirectionally connected to SMN 145. These two controllers are merely examples of peripheral controllers that may be used in APU 100.

[0020] The peripheral bus controller 170 includes a system controller hub 172 and a peripheral device controller hub 174, each of which is bidirectionally connected to an input / output (I / O) hub 176 and bidirectionally connected to the SMN 145. The system controller hub 172 is connected to the flash memory 220 via an appropriate communication link. The I / O hub 176 is also bidirectionally connected to the system hub 166 and bidirectionally connected to the data fabric 150. Thus, for example, the CPU core can program registers in the USB controller 162, the SATA interface controller 164, the system controller hub 172, or the peripheral device controller hub 174 via a path routed through the I / O hub 176 via the data fabric 150.

[0021] SMU 180 is a local controller that controls the operation of resources on APU 100 and synchronizes communications between them. SMU 180 manages the power-up sequencing of the various processors on APU 100 and controls multiple off-chip devices via reset, enable, and other signals. SMU 180 also manages power to the various processors and other functional blocks.

[0022] The Platform Security Processor (PSP) 210 is a local security controller that controls the firmware boot process on the APU 100. The PSP 210 also performs certain software validation and firmware rollback prevention (FAR) features, as will be described further below.

[0023] While a SoC implementation is shown, this is not limiting and other computing platforms may also benefit from the FAR techniques described herein.

[0024] Figure 2 A more detailed view of a PSP 210 according to some embodiments is shown in block diagram form. The PSP 210 includes a microcontroller core 212, RAM such as static RAM (SRAM) 216 connected to the microcontroller core 212, a boot ROM 218 connected to the microcontroller core 212, and a plurality of write-once storage locations 214 connected to the microcontroller core 212.

[0025] Generally, the PSP 210 operates as a secure processor for the APU 100. The PSP 210 may include additional functional blocks (not shown for clarity), such as cryptographic logic for performing security checks and interface logic for communicating with the SMN 145 and the data fabric 150. In operation, the PSP 210 performs a secure boot of the APU 100 (including implementing the FAR feature described herein) and implements other security-related functions requested by the CPU core complex 110 and other peripheral controllers of the APU 100.

[0026] Boot ROM 218 is preferably a secure boot ROM with tamper-resistant features and holds executable code and configuration data for initializing PSP 210 .

[0027] The write-once storage bits 214 preferably include a plurality of write-once bits, such as a 32-bit array configured as an array for storing a minimum security patch level (SPL) as described below. The write-once storage bits 214 may also include a single bit or other bit arrays for tracking other values. The bits are preferably implemented as fuses located on-chip with the PSP 210, but any suitable write-once technology may be used. Although this particular security processor implementation is provided as an example, other types of security processors may be used to implement the features described herein when combined with suitable secure memory and write-once storage bits.

[0028] Figure 3 A process 300 for verifying and loading firmware according to some embodiments is shown in flowchart form. Process 300 is typically performed on a security processor such as PSP 210 and implements the FAR feature, which defines a write-once security patch level (SPL) used as a hardware root of trust. The minimum SPL is the minimum version number updated when a major update is made to the firmware to prevent the firmware from rolling back to a previous version. Process 300 begins at block 302, where the security processor is started from a boot ROM (such as a security ROM integrated with the security processor). In this embodiment, the boot ROM code from which the security processor is started includes instructions that control process 300 until block 320, where the boot loader code is allowed to execute and control process 300.

[0029] At block 304, process 300 checks whether the secure state is enabled. This check may include checking one or more write-once bits, typically written or burned during factory configuration, to determine that the secure state is required and the FAR feature is enabled. If the secure state is not enabled, process 300 proceeds to block 306, where a non-secure boot of the host platform is performed without using the FAR feature.

[0030] If the secure state is enabled at block 304, process 300 proceeds to block 308, where a set of write-once storage bits are read to obtain a minimum security patch level (SPL). If the read fails, or returns an invalid value, process 300 proceeds to block 310, where the boot process is stopped. Such stopping may include storing a record of the failure in non-volatile memory, recording the reason for the stop.

[0031] After successfully reading the write-once memory bits at block 308, the firmware security table (FST) is loaded and verified at block 312. Typically, the FST is loaded from a host SoC or on a separate chip such as Figure 1 The non-volatile memory in the flash memory 220 of the security processor is loaded into the SRAM 216 on the security processor. The FST includes a plurality of firmware identifiers for the firmware code modules, and a plurality of check SPL values ​​are each associated with a corresponding one of the firmware identifiers, as shown in FIG. Figures 5 and 6 As further described, FST verification includes cryptographically checking the FST against a stored signature or other suitable value to confirm that the FST has not been modified. If the verification fails at block 312, a recovery procedure is entered at block 313. This procedure can cause the boot to stop or attempt to restore a previous FST version if a previous FST version that meets the minimum SPL check is available. A non-secure boot to secure mode or other suitable recovery procedure can also be used.

[0032] If the FST is successfully loaded and verified at block 312, block 314 reads the table SPL value stored with the FST and verifies that the table SPL is greater than or equal to the minimum SPL obtained at block 308. If the table SPL fails the check, process 300 proceeds to the recovery procedure at block 313.

[0033] If the table SPL passes the check at block 314, then the boot loader is loaded and verified at block 316. The boot loader is preferably loaded from an off-chip non-volatile memory such as flash memory 220 ( Figure 1 The verification may include a suitable known cryptographic verification, such as comparing the signature of the boot loader executable code to a stored value, or checking the signature using a public key. If the boot loader fails to load and verify successfully, the process 300 proceeds to the recovery procedure at block 313.

[0034] If the boot loader is successfully loaded and verified at block 316, the boot loader SPL is compared to the boot loader check SPL from the FST at block 318. This comparison includes checking whether the boot loader SPL value is greater than or equal to the boot loader check SPL value stored in the FST. The boot loader FST is preferably obtained from the boot loader's firmware header (such as the one for the boot loader) along with the boot loader. Figure 6 If the check fails at box 318 , the process 300 proceeds to the recovery procedure at box 313 .

[0035] If the check at block 318 passes, the boot loader begins loading the secure processor and executing it at block 320. At this point, the boot loader controls process 300 to verify the remaining firmware modules required to boot the host platform. Process 300 proceeds to block 322, where the boot loader begins iteratively loading, verifying, and validating firmware modules for the various controllers on the host system until all desired firmware modules are loaded. The loading and verification process is similar to that described above, with signatures or other cryptographic checks calculated for the corresponding firmware modules and compared to stored values. If a firmware module fails to load and verify successfully, process 300 proceeds to the recovery procedure at block 313.

[0036] If the firmware module passes verification at block 322, block 324 continues with verification of the firmware module to prevent malicious rollback activity. The verification includes: for each firmware code module, (a) accessing each corresponding firmware module and obtaining a corresponding firmware SPL value, (b) accessing the FST to obtain a corresponding one of the check SPL values, and (c) checking whether the corresponding firmware SPL value is equal to or greater than the corresponding check SPL value. Preferably, the firmware SPL value is stored in the firmware header along with the firmware module.

[0037] If the verification at block 324 passes, then at block 326, the firmware is loaded into the target controller on the host platform. Block 326 may include commands from the secure processor to the target controller to load and execute the firmware. If the verification at block 324 fails, then process 300 proceeds to the recovery procedure at block 313.

[0038] After each firmware module is loaded at block 326 , process 300 proceeds to block 322 to load and verify the next firmware module until all modules are loaded.

[0039] While a single FST is used in this embodiment, other embodiments may use multiple FSTs, each similar to the FST described herein, to check the SPL value against a write-once stored SPL value, or against an entry in the FST. For example, a boot loader may provide for loading and verifying firmware modules for a secure operating system. A secondary FST may be used for this purpose, which may be verified by a boot loader running on a secure processor and then used by a secure operating system to execute code on another processor, such as the CPU core complex 110 ( Figure 1 ) to verify additional firmware modules under the control of the secure operating system. In such cases, the secure processor can satisfy requests from the secure operating system to load or load and verify firmware modules.

[0040] Although process 300 includes verifying a firmware module, other types of modules may also be verified according to the FST to provide rollback resistance. For example, a secure operating system module or library may be verified and loaded in a manner similar to the firmware module described above.

[0041] Although in this embodiment, process 300 begins under the control of executable code from the secure boot ROM and passes control to the boot loader, other versions may operate the secure processor differently. In some embodiments, the secure boot ROM may perform all firmware module verification without loading the boot loader. In other versions, such as Figure 4 The bootloader controls the process of reading the write-once storage bits and verifying the FST.

[0042] As can be appreciated, the use of FSTs herein for verifying firmware updates has the advantage of requiring fewer write-once memory bits than techniques that track firmware versions directly in write-once memory. Verification of the FST based on the minimum SPL provides a similar level of security as using write-once memory directly, but uses less circuit area.

[0043] Figure 4 Another process 400 for verifying and loading firmware and software according to some embodiments is shown in flowchart form. Process 400 has many similar operations to process 300, but the initial verification of table SPL is performed by the secure processor executing the boot loader rather than by the boot ROM code. This technique provides more configurability and upgradeability for the secure processor while still maintaining the anti-rollback functionality described above.

[0044] Process 400 begins at block 402, where the secure processor executes a boot loader stored in off-chip non-volatile memory. Blocks 404 and 406 proceed similarly to blocks 304 and 306, except that they are under the control of the boot loader rather than the boot ROM code. At block 404, process 400 checks whether the secure state is enabled. If the secure state is not enabled, process 300 proceeds to block 306, where a non-secure boot of the host platform is performed without using the FAR feature.

[0045] If the secure state is enabled at block 404, process 400 proceeds to block 408, where the secure processor, under control of the boot loader, reads a set of write-once storage bits to obtain a minimum security patch level (SPL). If the read fails, or returns an invalid value, process 400 proceeds to block 410, where the boot process is stopped.

[0046] After successfully reading the write-once storage bits at block 408, the firmware security table (FST) is loaded and verified at block 412. The FST is similar to the Figure 3 If the check fails at block 412, a recovery procedure is entered at block 413. This procedure may cause the boot to stop or attempt to recover a previous FST version if one is available that still meets the minimum SPL check at block 414. A non-secure boot to secure mode or other suitable recovery procedure may also be used.

[0047] If the FST is successfully loaded and verified at block 412, then at block 414, the secure processor, under control of the boot loader, reads the table SPL value stored with the FST and executes a sequence in which the table SPL is checked to see if an update is required. Block 414 checks whether the table SPL is less than the minimum SPL obtained at block 408. If so, process 400 proceeds to the recovery procedure at block 413.

[0048] If the table SPL is not less than the minimum SPL at block 414, the minimum SPL may still need to be updated. Block 415 checks whether the table SPL is equal to the minimum SPL. If not, process 400 proceeds to block 416, where a check is performed to determine whether the minimum SPL needs to be updated in a write-once storage bit. This check detects that a firmware update has been performed, which requires an update to the minimum SPL. This check can be implemented using one or more settings that can be configured by the security update code when the update is performed. A write-once storage bit, such as a fuse, can serve as an SPL update flag and be checked by the security processor to see if the bit has been previously set to indicate a need for an SPL update. This bit is typically one of many provided on a security processor that allows multiple updates. If set, the boot loader must update the minimum SPL value. In addition to or in lieu of the write-once bit, another check can be performed to detect an update. For example, a BIOS flag can be set to indicate that an SPL update flag needs to be set in a write-once storage bit. This scenario should only be used in architectures where the BIOS is trusted to be secure. If the BIOS flags that it is needed, the process 400 sets the SPL update flag before performing any other actions. If a minimum SPL update is not needed at block 416 , the process 400 proceeds to block 418 .

[0049] If an update requiring a minimum SPL update is detected at block 416 , block 417 sets the minimum SPL to the table SPL by writing the new value to the write-once storage bit. The update to the minimum SPL may require a restart or may proceed to block 418 .

[0050] Block 418 verifies the boot loader by checking whether the boot loader SPL is greater than or equal to the boot loader check SPL in FST. If the boot loader SPL fails this check, the process 400 proceeds to the recovery procedure at block 413.

[0051] If the boot loader SPL passes the check at block 418, process 400 proceeds to block 422, where loading, checking, and verifying the firmware modules begins. At block 422, the boot loader begins iteratively loading, checking, and verifying the firmware modules for the various controllers on the host system until all desired firmware modules are loaded. The loading and verification are performed similarly to those described above, with signatures or other cryptographic checks calculated for the corresponding firmware modules and compared to stored values. If the firmware module fails to load and verify successfully, process 400 proceeds to the recovery procedure at block 413.

[0052] If the firmware module passes verification at block 422, block 424 continues with verification of the firmware module to prevent malicious rollback activity. The verification includes: for each firmware code module, (a) accessing each corresponding firmware module and obtaining a corresponding firmware SPL value, (b) accessing the FST to obtain a corresponding one of the check SPL values, and (c) checking whether the corresponding firmware SPL value is equal to or greater than the corresponding check SPL value. Preferably, the firmware SPL value is stored in the firmware header along with the firmware module.

[0053] If verification passes at block 424, the firmware is loaded into the target controller on the host platform at block 426. Block 426 may include commands from the security processor to the target controller to load and execute the firmware. If verification fails at block 424, process 400 proceeds to the recovery procedure at block 413. After each firmware module is loaded at block 426, process 400 proceeds to block 422 to load and verify the next firmware module until all modules are loaded.

[0054] It should be noted that the process of updating the minimum SPL value at blocks 415, 416, and 417 can also be integrated into Figure 3 The process 300 is executed under the control of a boot ROM or a boot loader.

[0055] Figure 5 A firmware security table (FST) 500 according to some embodiments is shown in table form. As described above, the FST 500 is preferably stored in a non-volatile memory such as flash memory and then loaded into the SRAM 216 ( Figure 2 ), in which the FST is used to verify the firmware. The FST 500 includes a set of firmware identifiers, as shown by the Firmware Image ID column of the Firmware Code Module. The FST 500 also includes a plurality of check SPL values, each of which is associated with a corresponding one of the firmware identifiers.

[0056] Figure 6A diagram of a firmware module 600 according to some embodiments is shown. The firmware module 600 includes executable firmware program code and a firmware header for use with the FAR technology herein. The firmware header is presented as a file header or otherwise associated with the firmware executable code stored in non-volatile memory. The firmware header includes a firmware image ID that matches the associated ID in the FST. The header version identifies the version of the header, which can be used to interpret the header format. A firmware SPL is included, which is used in the verification described above to be checked against the associated SPL value stored in the FST. Other data items such as signatures may also be included in the firmware header. In addition, similar structures can be used for other firmware or software to be verified by a secure processor, such as a secure operating system (OS) executable code or other software code.

[0057] Figure 1 The APU 100 or any portion thereof, or other implementations of a data processing platform employing the techniques herein, can be described or represented by a computer-accessible data structure in the form of a database or other data structure that can be read by a program and used directly or indirectly to fabricate an integrated circuit. For example, the data structure can be a behavioral-level description of hardware functionality or a register-transfer-level (RTL) description in a high-level design language (HDL) such as Verilog or VHDL. The description can be read by a synthesis tool, which can synthesize the description to produce a netlist comprising a list of gates from a synthesis library. The netlist comprises a set of gates that also represent the functionality of the hardware comprising the integrated circuit. The netlist can then be placed and routed to produce a data set describing the geometry to be applied to a mask. The mask can then be used in various semiconductor fabrication steps to produce the integrated circuit. Alternatively, the database on the computer-accessible storage medium can be a netlist (with or without a synthesis library) or a data set, or Graphics Data System (GDS) II data, as desired.

[0058] Although specific embodiments have been described, various modifications to these embodiments will be apparent to those skilled in the art. For example, multiple FSTs can be employed, each with a minimum SPL stored in a write-once storage location. FSTs can be used to verify other types of software. The specific locations of write-once storage locations, boot ROMs, and non-volatile memory can be changed within security constraints. In addition, a security processor can verify firmware or software modules based on the SPL values ​​stored in the FST as a service to other processors or controllers in the host system. Various encryption schemes can also be used on the data values ​​stored in the FST without changing the secure FAR functionality described herein.

[0059] Therefore, it is intended by the appended claims to cover all modifications of the disclosed embodiments that fall within the scope of this disclosure.

Claims

1. A method for verifying firmware of a computing platform, comprising: Start the security processor; At the security processor, reading a set of write-once storage bits to obtain a minimum security patch level SPL; verifying, at the security processor, that a table SPL of a firmware security table is greater than or equal to the minimum SPL, the firmware security table comprising a plurality of firmware identifiers for firmware code modules, and a plurality of check SPL values ​​each associated with a corresponding one of the firmware identifiers; Verify multiple firmware code modules; as well as Prior to verifying the plurality of firmware code modules, accessing a boot loader including a boot loader SPL value and checking whether the boot loader SPL value is greater than or equal to an associated boot loader check SPL value stored in the firmware security table, wherein the boot loader performs the verification of the plurality of firmware code modules.

2. The method of claim 1, further comprising: If the boot loader SPL value is greater than or equal to the associated boot loader check SPL value stored in the firmware security table, loading the boot loader into the security processor and executing the boot loader; If not, then perform the recovery procedure; and Verifying the multiple firmware code modules further includes: for each firmware code module, (a) accessing each corresponding firmware module and obtaining a corresponding firmware SPL value, (b) accessing the firmware security table to obtain a corresponding one of the check SPL values, and (c) checking whether the corresponding firmware SPL value is equal to or greater than the corresponding check SPL value. 3 . The method of claim 2 , wherein loading the boot loader into the secure processor comprises loading from non-volatile memory. 4 . The method of claim 1 , wherein booting the secure processor comprises booting from a secure read-only memory (ROM) integrated with the secure processor.

5. The method of claim 1 , further comprising: loading data from the firmware security table into a random access memory RAM in the security processor; as well as The loaded data is accessed when verifying the plurality of firmware code modules.

6. The method of claim 1 , further comprising updating the firmware security table, and in association with updating the firmware security table, increasing the table SPL and writing a new lowest SPL value to the set of write-once storage bits. 7 . The method of claim 1 , further comprising, after verifying the selected one of the firmware code modules, loading the selected one of the firmware code modules into a processor and initializing the processor under control of the security processor.

8. The method of claim 1, wherein reading the set of write-once memory bits comprises reading a set of one-time programmable fuses.

9. A data processing platform comprising: Non-volatile memory; a system on a chip coupled to the non-volatile memory and comprising: a processor comprising one or more processing cores; a security processor comprising a microcontroller core, a set of write-once memory bits coupled to the microcontroller core, a random access memory RAM coupled to the microcontroller core, and a secure boot read-only memory ROM coupled to the microcontroller core; wherein the security processor operates to: Starting the security processor; reading the set of write-once storage bits to obtain a minimum security patch level SPL; verifying that a table SPL of a firmware security table is greater than or equal to the minimum SPL, the firmware security table comprising a plurality of firmware identifiers for firmware code modules, and a plurality of check SPL values ​​each associated with a corresponding one of the firmware identifiers; Verifying multiple firmware code modules; and Prior to verifying the plurality of firmware code modules, accessing a boot loader including a boot loader SPL value and checking whether the boot loader SPL value is greater than or equal to an associated boot loader check SPL value stored in the firmware security table, wherein the boot loader performs the verification of the plurality of firmware code modules.

10. The data processing platform of claim 9, wherein the security processor is further operative to: If the bootloader SPL value is greater than or equal to the associated bootloader SPL value stored in the firmware security table, then loading the boot loader into the security processor and executing the boot loader; If not, then perform the recovery procedure; and Verifying the multiple firmware code modules further includes: for each firmware code module, (a) accessing each corresponding firmware module and obtaining a corresponding firmware SPL value, (b) accessing the firmware security table to obtain a corresponding one of the check SPL values, and (c) checking whether the corresponding firmware SPL value is equal to or greater than the corresponding check SPL value.

11. The data processing platform of claim 10, wherein loading the boot loader into the secure processor comprises loading from a non-volatile memory.

12. The data processing platform of claim 11, wherein the non-volatile memory is external to the secure processor.

13. The data processing platform of claim 10, further comprising a secure read-only memory (ROM) integrated with the secure processor, and wherein booting the secure processor comprises booting from the secure ROM.

14. The data processing platform of claim 10, wherein the security processor is further operative to detect an update of the firmware security table, and in association with updating the firmware security table, increase the table SPL and write a new minimum SPL value to the set of write-once storage bits.

15. A security processor comprising: microcontroller core; a set of write-once memory bits coupled to the microcontroller core; a random access memory RAM coupled to the microcontroller core; and wherein the security processor operates to: Starting the security processor; reading the set of write-once storage bits to obtain a minimum security patch level SPL; Verify that the table SPL of the firmware security table is greater than or equal to the minimum SPL, The firmware security table includes a plurality of firmware identifiers for firmware code modules, and a plurality of check SPL values ​​are each associated with a corresponding one of the firmware identifiers; Verifying a plurality of firmware code modules by, for each firmware code module, (a) accessing each corresponding firmware module and obtaining a corresponding firmware SPL value, (b) accessing the firmware security table to obtain a corresponding one of the check SPL values, and (c) checking whether the corresponding firmware SPL value is equal to or greater than the corresponding check SPL value; and Prior to verifying the plurality of firmware code modules, accessing a boot loader including a boot loader SPL value and checking whether the boot loader SPL value is greater than or equal to an associated boot loader check SPL value stored in the firmware security table, wherein the boot loader performs the verification of the plurality of firmware code modules.

Images