Firmware hot update method and system for management and control processor MCP

Abstract

This application proposes a firmware hot-update method and system for a Management and Control Processor (MCP), relating to the field of server technology. The method, applied to an operating system (OS), includes: in response to a firmware update request, constructing a request packet including the address, version number, and digital signature of the firmware image to be updated; invoking a first SMC instruction via security monitoring to request a Trusted Firmware Activated Function (ATF) to verify and authorize the request packet; in response to receiving verification and authorization approval information from the ATF, writing the firmware image to be updated into a pre-defined memory area dedicated to the MCP; and sending a data-ready notification to the ATF via a second SMC instruction, so that the ATF triggers the System Control Processor (SCP) to reset the MCP, causing it to boot from the pre-defined memory area and load the firmware image to be updated. This solution enables millisecond-level firmware hot updates without service interruption.

Description

Technical Field

[0001] This application relates to the field of server technology, and more specifically, to a firmware hot-update method and system for a management control processor (MCP). Background Technology

[0002] The Management and Control Processor (MCP) is a dedicated coprocessor integrated into the server system-on-a-chip (SoC) and is responsible for low-level hardware control functions such as power management, sensor monitoring, and reset control. During server operation, the MCP firmware needs to be updated to fix firmware vulnerabilities or optimize the power processing unit (PPU) control strategy.

[0003] In existing technologies, firmware updates for the Management and Control Processor (MCP) typically rely on a system-wide reboot: this requires upgrading the Basic Input / Output System (BIOS) and resetting the entire server system-on-a-chip (SoC) to reload the new firmware from non-volatile memory onto the MCP. The specific process involves: first, downloading the new firmware via the out-of-band Management Controller (BMC) and triggering a BIOS update; then, resetting the main CPU and all coprocessors; and finally, loading the MCP firmware during system re-initialization. This process results in a complete interruption of server services and is time-consuming from triggering the update to the MCP taking effect.

[0004] Therefore, how to perform short-duration hot updates to the firmware of the Management and Control Processor (MCP) without interrupting business operations has become a pressing technical problem in this field. Summary of the Invention

[0005] The purpose of this application is to provide a method and system for hot-updating the firmware of a Management and Control Processor (MCP), which can perform short-duration hot updates to the firmware of the MCP while ensuring uninterrupted service.

[0006] This application is implemented as follows: In a first aspect, this application provides a firmware hot-update method for a Management and Control Processor (MCP), applied to an operating system (OS). The method includes: in response to a received firmware update request, constructing an update request package, the update request package including the address, version number, and digital signature of the firmware image to be updated; invoking a first SMC instruction through security monitoring to request a Trusted Firmware Activation Function (ATF) to verify and authorize the update request package; in response to receiving verification and authorization pass information returned by the Trusted Firmware ATF, writing the firmware image to be updated into a preset memory area, the preset memory area being an update area dedicated to the Management and Control Processor (MCP); and sending a data ready notification to the Trusted Firmware ATF through a second SMC instruction, so that the Trusted Firmware ATF triggers the System Control Processor (SCP) to perform a reset operation on the Management and Control Processor (MCP), causing the Management and Control Processor (MCP) to start from the preset memory area and load the firmware image to be updated.

[0007] Secondly, this application provides a firmware hot update system for a Management and Control Processor (MCP), comprising: an operating system (OS) module, configured to: construct an update request package in response to a received firmware update request, the update request package including the address, version number, and digital signature of the firmware image to be updated; invoke a first SMC instruction via security monitoring to request a trusted firmware ATF module to verify and authorize the update request package; write the firmware image to be updated into a preset memory area in response to receiving verification and authorization pass information returned by the trusted firmware ATF module, the preset memory area being an update area dedicated to the Management and Control Processor (MCP) module; and send a data ready notification to the trusted firmware ATF module via a second SMC instruction. The trusted firmware ATF module is configured to: receive and verify the update request package sent by the operating system (OS) module, and return verification and authorization pass information to the operating system (OS) module after successful verification and authorization; and send a reset instruction to the System Control Processor (SCP) module. The System Control Processor (SCP) module is configured to: perform a reset operation on the Management and Control Processor (MCP) module in response to the reset instruction sent by the trusted firmware ATF module. The Management and Control Processor (MCP) module is used to boot from a preset memory area and load the firmware image to be updated after a reset.

[0008] Compared with the prior art, this application has at least the following advantages or beneficial effects: This application proposes a firmware hot-update method for a Management and Control Processor (MCP). Because it only resets the MCP's own power domain without affecting the operation of the main CPU and other cores, the server services remain completely unaware, allowing for hot updates of the MCP's firmware without service interruption. Furthermore, the entire update process is performed in-band, further reducing the hot-update time. Moreover, by directly writing the firmware image to be updated into a preset memory area and booting from that area, bypassing the traditional Flash read path, the hot-update time is further reduced. In addition, this application constructs a complete secure and trusted chain, from verifying the update request packet to isolating execution in a secure environment, ensuring that only legitimate and compatible firmware can be loaded, fundamentally guaranteeing the security and reliability of the hot-update process. Attached Figure Description

[0009] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a flowchart of an embodiment of a firmware hot update method for a management control processor (MCP) according to this application; Figure 2 This is a flowchart illustrating the process of trusted firmware ATF verifying and authorizing update request packets in one embodiment of this application; Figure 3 This is a flowchart illustrating the verification of the legality of a digital signature based on a pre-stored platform public key in one embodiment of this application; Figure 4 This is a flowchart of yet another embodiment of a firmware hot update method for a management control processor (MCP) according to this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. It should be understood that this application is not limited to the exemplary embodiments described herein.

[0012] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0013] To facilitate understanding of the technical solutions provided in this application, some concepts will be introduced below.

[0014] 1. Operating System (OS): An operating system is system software that runs on the main CPU of a server. It is responsible for managing computer hardware resources, providing user interfaces, and running applications. In this application, the OS is the initiator of the hot update process, capable of sensing business load and proactively triggering firmware updates.

[0015] 2. Trusted Firmware (ATF): Arm Trusted Firmware is a secure firmware that runs at the highest exception level (EL3) of ARM architecture processors, providing an entry point for switching from the insecure to the secure world. In this application, the Trusted Firmware (ATF) acts as a security arbitrator, responsible for verifying the legitimacy of the update request packet and authorizing subsequent operations.

[0016] 3. System Control Processor (SCP): The System Control Processor (SCP) is a dedicated processor integrated into the system-on-a-chip (SoC) and is responsible for low-level hardware coordination functions such as system-level power management, clock control, and reset control. In this application, the SCP acts as a hardware execution agent, resetting the Management Control Processor (MCP) according to the Trusted Firmware ATF instructions.

[0017] 4. Management Control Processor (MCP): The Management Control Processor is a dedicated coprocessor integrated into the server system-on-a-chip (SoC) and is responsible for low-level hardware control functions, including power processing unit management, sensor monitoring, and reset control. In this application, the Management Control Processor (MCP) has an independent power domain and is the target of firmware hot updates. After a reset, it boots new firmware from a preset memory area.

[0018] In conventional technical solutions, firmware updates for the Management and Control Processor (MCP) typically rely on a system reboot. Therefore, when the MCP firmware needs updating (e.g., fixing PPU control logic vulnerabilities) or runtime policies need adjustment (e.g., RAS thresholds), the Baseboard Management Controller (BMC) must download the new firmware and trigger a Basic Input / Output System (BIOS) update. This is followed by a reset of the main CPU and all coprocessors, with the MCP firmware loading completed during system reinitialization. This process causes a complete interruption of server services, and the time from triggering the update to the MCP taking effect is typically on the order of seconds or more.

[0019] This shows that this solution, which relies on a complete system restart, cannot meet the requirements of high availability scenarios. Furthermore, out-of-band updates triggered by the out-of-band board management controller (BMC) require cross-network transmission and authentication, resulting in high response latency, making it unsuitable for millisecond-level tuning scenarios.

[0020] In the process of developing this application, the inventors discovered that the root cause of these defects in the existing solution is that the update process relies entirely on the out-of-band board management controller (BMC) and the basic input / output system (BIOS), fails to utilize the operating system (OS)'s real-time perception of workload, and the reset range covers the entire system-on-a-chip rather than being limited to the power domain of the management and control processor (MCP) itself.

[0021] Based on this, this application proposes a hot update scheme that is led by the operating system (OS), securely arbitrated by the trusted firmware (ATF), precisely reset by the system control processor (SCP), and started based on the random access memory (RAM), thereby enabling millisecond-level firmware hot updates without service interruption.

[0022] After introducing the basic principles of this application, various non-limiting embodiments of this application will be described in detail below with reference to the accompanying drawings. Unless otherwise specified, the various embodiments and features described below can be combined with each other.

[0023] Please see Figure 1 The firmware hot update method of the management and control processor (MCP), applied to the operating system (OS), includes: Step S101: In response to the received firmware update request, construct an update request packet, the update request packet including the address, version number and digital signature of the firmware image to be updated.

[0024] It's important to note that the operating system (OS) typically performs the following actions before receiving a firmware update request: When the OS determines, based on changes in workload, security policy adjustments, or underlying hardware status monitoring, that the Management and Control Processor (MCP) firmware needs updating (e.g., fixing a vulnerability in the Power Processing Unit (PPU) control logic) or its runtime policies need adjustment (e.g., modifying reliability / availability / serviceability (RAS) thresholds), the OS sends an update prompt to the user space or upper-level management software. In response to this update prompt, the user or upper-level management software prepares the firmware image to be updated and related update parameters, and sends a firmware update request to the OS through the management interface to trigger the subsequent update process. Simply put, a firmware update request is a control command sent by the upper-level management software or user space program to the OS in response to an update prompt from the OS or an operation instruction from maintenance personnel, used to trigger the MCP firmware hot update process.

[0025] Next, upon receiving the request, the operating system kernel driver (e.g., mcp_update.ko) does not directly write the firmware to the target location. Instead, it first constructs a structured update request packet. This request packet contains three core elements: the address of the firmware image to be updated (usually a physical address used to locate the storage location of the firmware binary data in memory), the version number (used for subsequent compatibility checks), and the digital signature (signature data generated based on the platform's private key for the firmware image, used for authentication and integrity protection).

[0026] In other words, step S101 transforms a firmware update intent into a structured data packet carrying complete identity credentials and metadata, providing an input basis for subsequent security verification. The digital signature mechanism ensures the trustworthiness of the firmware source and the integrity of its content. Simultaneously, by including the version number, it provides data support for subsequent hardware compatibility testing.

[0027] Step S102: Invoke the first SMC instruction through security monitoring to request the trusted firmware ATF to verify and authorize the update request packet.

[0028] After constructing the update request packet, the operating system (OS) executes a custom security monitoring call (SMC) first instruction (e.g., SMC call number 0x84000001) to switch the central processing unit (CPU) from the insecure world (EL1, the exception level where the OS operates) to the secure world (EL3, the exception level where the trusted firmware ATF operates), and passes the physical address of the update request packet as a parameter to the trusted firmware ATF. Upon capturing this first SMC instruction, the trusted firmware ATF takes over the processing flow, parses the incoming update request packet, verifies the legality of the digital signature to ensure the source of the firmware image to be updated is trustworthy and has not been tampered with, and verifies the compatibility of its version number with the hardware capability registers to ensure that the firmware image to be updated is supported by the current hardware platform.

[0029] In other words, in step S102 above, by having the trusted firmware ATF act as a security arbitrator to verify and authorize the update request packet, the security of the key storage and signature verification process is ensured, preventing malicious software from stealing keys or bypassing verification at the operating system (OS) layer.

[0030] Step S103: In response to receiving the verification and authorization pass information returned by the trusted firmware ATF, the firmware image to be updated is written to a preset memory area, which is an update area dedicated to the management control processor MCP.

[0031] Once the Trusted Firmware ATF completes verification and confirms its legitimacy, it returns verification and authorization pass information to the operating system (OS). This return information is not only a status indicator but also implies that the Trusted Firmware ATF has completed dynamic configuration of memory access permissions: after successful verification, the Trusted Firmware ATF sets temporary permissions for a preset memory region, allowing the OS to access and write data to this region. This operation decouples the firmware write operation from the security verification operation; that is, security verification is performed by the Trusted Firmware ATF in the secure world, while writing is performed by the OS in the insecure world, with the two connected through a temporary permission authorization mechanism. In this way, write permissions to the sensitive preset memory region can be granted shortly after the Trusted Firmware ATF verification, preventing the permanent leakage of write permissions.

[0032] Step S104: Send a data ready notification to the trusted firmware ATF via the second SMC instruction, so that the trusted firmware ATF triggers the system control processor SCP to perform a reset operation on the management control processor MCP, so that the management control processor MCP starts from the preset memory area and loads the firmware image to be updated.

[0033] After the firmware image to be updated is fully written to the preset memory area, the operating system (OS) switches back to the secure world by executing a second SMC instruction (e.g., SMC call number 0x84000002) and sends a data ready notification to the trusted firmware ATF. Upon receiving this notification, the trusted firmware ATF confirms that the firmware is in place and then sends a reset command to the system controller processor (SCP) through an inter-processor communication mechanism (such as a mailbox). The SCP, acting as a hardware execution agent, operates the management control processor (MCP) to perform an independent power domain reset according to the reset command, enabling the MCP to boot from the preset memory area and load the firmware image to be updated after restarting and resetting.

[0034] In other words, step S104 above, through the layered collaboration between the Trusted Firmware (STF) and the System Control Processor (SCP), achieves a reset of only the power domain of the Management Control Processor (MCP) without affecting the operation of the Central Processing Unit (CPU) and other cores. This allows for hot firmware updates to the MCP without interrupting services. Furthermore, since the entire update process is collaboratively completed by in-band modules such as the Operating System (OS), Trusted Firmware (ATF), and System Control Processor (SCP), it does not rely on cross-network transmission and authentication by the Baseboard Management Controller (BMC). Therefore, the update take-off time is short, typically compressed to the millisecond level (<100ms), meeting the dynamic optimization requirements of high-availability scenarios.

[0035] It's important to note that in-band processing refers to the processing path directly completed by internal components of the main system (operating system OS, trusted firmware ATF, system controller processor SCP). Data is transferred between different exception levels within the processor without external network intervention. Out-of-band processing, on the other hand, refers to processing that requires cross-network transmission and authentication, resulting in a longer response time compared to in-band processing.

[0036] In summary, this application achieves uninterrupted business management and control processor (MCP) firmware hot update by having the operating system (OS) actively initiate the process, request verification through a secure channel, write the firmware to a dedicated memory area, and trigger a reset.

[0037] Specifically, in this application, the operating system (OS) responds to the firmware update request and constructs an update request package containing a digital signature. This fully utilizes the OS's real-time perception capability of business load, enabling it to proactively trigger optimization based on the current operating status, thus overcoming the drawback of the traditional solution where the OS cannot participate in MCP behavior optimization.

[0038] Secondly, this application sends the request to the trusted firmware ATF for verification and authorization by calling the first SMC instruction through security monitoring. This isolates the security-critical operation in a secure environment, which can effectively ensure the credibility of the source and the integrity of the content of the update process.

[0039] Furthermore, only after authorization can the operating system (OS) write the firmware image to be updated into a dedicated preset memory area of ​​the management and control processor (MCP), thus preventing the leakage of write permissions to the sensitive preset memory area.

[0040] Finally, this application notifies the trusted firmware ATF via the second SMC instruction. The trusted firmware ATF then triggers the system control processor SCP to perform an independent power domain reset on the management control processor MCP, enabling it to directly boot the new firmware from the memory area. This achieves efficient hot updates without service interruption by resetting only the management control processor MCP within the band, overcoming the shortcomings of traditional solutions that rely on a complete system reboot leading to service interruption and high latency for out-of-band updates. It should be noted that because this application bypasses the traditional Flash read path by directly writing the firmware image to be updated into a preset memory area and booting from that area, it further reduces the time required for hot updates.

[0041] It should be noted that in traditional firmware update schemes, after the management control processor (MCP) is reset, it needs to read the firmware from the Flash memory to the internal random access memory (RAM) before execution. This requires a path of "accessing the Flash controller → addressing → reading → transferring", and the slow Flash read speed results in a long update time.

[0042] In this application, the operating system (OS) directly writes the new firmware (the firmware image to be updated) into the dedicated update area of ​​the management and control processor (MCP), which is typically the on-chip static random access memory (SRAM). After reset, the system control processor (SCP) is configured to boot from RAM. The MCP directly reads and executes the firmware from the SRAM without accessing the Flash memory, thus bypassing the slow read path and reducing the update take-off time to the millisecond level.

[0043] Based on the aforementioned scheme, in some implementations of this application, the step of constructing an update request packet includes: obtaining the physical address of the firmware image to be updated as the address of the firmware image to be updated; calling the kernel cryptographic module to perform a signature operation on the firmware image to be updated based on the platform private key to generate the digital signature; and encapsulating the physical address, the version number, and the digital signature into structured data to obtain the update request packet.

[0044] Understandably, this implementation uses physical addresses to accurately locate the firmware storage location, avoiding data addressing errors; the digital signature generated by the platform's private key provides a reliable basis for subsequent verification of the firmware's authenticity and content integrity by the Trusted Firmware ATF, preventing unauthorized or tampered firmware from entering the update process, thus ensuring the security of the hot update process from the source.

[0045] Based on the aforementioned solution, please refer to Figure 2 In some implementations of this application, the steps of the trusted firmware ATF verifying and authorizing the update request packet include: Step S201: The trusted firmware ATF parses the update request packet to obtain the address, the version number, and the digital signature; Step S202: The trusted firmware ATF verifies the legality of the digital signature based on the pre-stored platform public key and checks the compatibility of the version number with the hardware capability register; Step S203: If the verification and check are both successful, the verification and authorization success information is fed back to the operating system OS to authorize the operating system OS to access the preset memory area.

[0046] Understandably, this implementation uses Trusted Firmware ATF to perform dual verification on update request packets, establishing a secure and reliable execution prerequisite for subsequent operations. Specifically, after capturing an update request packet, Trusted Firmware ATF first parses the packet, extracting three core data items: address, version number, and digital signature. Next, Trusted Firmware ATF verifies the legitimacy of the digital signature based on a pre-stored platform public key, confirming the firmware's authenticity and lack of tampering; simultaneously, it checks the compatibility of the version number with the hardware capability registers, confirming that the new firmware is supported by the current hardware. Only when both verifications pass will Trusted Firmware ATF send verification and authorization approval information to the operating system (OS), thereby authorizing the OS to subsequently access the preset memory area.

[0047] Based on the aforementioned solution, please refer to Figure 3 In some implementations of this application, the verification of the legality of the digital signature based on the pre-stored platform public key includes: Step S301: Reading the platform public key from a one-time programmable fuse (eFuse), wherein the platform public key is an asymmetric key paired with a platform private key, and the platform private key is stored offline by the device manufacturer; Step S302: Calling a secure cryptographic library function to decrypt the digital signature using the platform public key to obtain a first hash value; Step S303: Performing a hash operation on the firmware image to be updated indicated by the address to obtain a second hash value; Step S304: Comparing whether the first hash value and the second hash value are consistent, and if they are consistent, determining that the digital signature is legal.

[0048] Understandably, this implementation constructs an immutable firmware root of trust through hardware-bound keys and hash comparison mechanisms. Specifically, by storing the platform's public key in a one-time programmable fuse (eFuse), the physical immutability of the verification key is ensured, preventing the possibility of key theft or tampering. Simultaneously, offline storage of the platform's private key further eliminates the risk of private key exposure. Through hash value comparison, the Trusted Firmware ATF can accurately determine whether the firmware has been tampered with, thus ensuring that only officially signed, legitimate firmware can proceed with the update process.

[0049] Based on the aforementioned scheme, in some implementations of this application, the step of authorizing the operating system (OS) to access the preset memory region includes: configuring a memory management unit (MMU) or a memory protection unit (MPU) to temporarily map the base address of the preset memory region to an address space that the OS is allowed to write to; wherein, the access permission of the mapping is set to write-only.

[0050] Understandably, in this implementation, after the trusted firmware ATF completes verification, it configures the Memory Management Unit (MMU) or Memory Protection Unit (MPU) to temporarily map the base address of a preset memory region to an address space that the operating system (OS) is allowed to write to. During this process, the access permission for this mapping is set to write-only, meaning the OS can only write data to this region and cannot read any content from it. This effectively prevents the risk of the firmware image content being maliciously read or leaked. Furthermore, this temporary mapping mechanism follows the principle of least privilege, granting write access only for a very short time after verification, avoiding permanent access and thus preventing the preset memory region from being exposed and vulnerable to attack for extended periods.

[0051] Based on the aforementioned scheme, in some implementations of this application, the verification and authorization pass information is generated and issued by the trusted firmware ATF after verifying that the digital signature has passed and confirming that the version number is compatible with the current hardware indicated by the hardware capability register.

[0052] It is understandable that this implementation explicitly defines the prerequisites for generating verification and authorization information, namely, both verification conditions must be met simultaneously. This dual verification ensures that only firmware from a trustworthy source and compatible with the hardware can be authorized. Specifically, digital signature verification guarantees that the firmware has not been tampered with, and version compatibility checks prevent system failures caused by firmware incompatibility with hardware, thus guaranteeing the security and reliability of the hot update process from the source.

[0053] Based on the aforementioned scheme, in some implementations of this application, the step of writing the firmware image to be updated to a preset memory region includes: transferring the firmware image to be updated from the storage region indicated by the address to the preset memory region through a direct memory access DMA engine or a physical memory copy function; wherein, the preset memory region is a reserved address space in the on-chip static random access memory (SRAM), its memory attributes are configured as device memory (DeviceMemory), caching is prohibited, and the write operation is atomic.

[0054] It should be noted that in this implementation, the preset memory region is limited to the address space reserved in the on-chip static random access memory (SRAM), and its memory attribute is configured as Device Memory. This means that access to this region is prohibited from using caching, and each write operation is atomic, meaning that the write process cannot be interrupted or split.

[0055] In summary, this implementation achieves efficient data transfer and reduces the burden on the central processing unit (CPU) through Direct Memory Access (DMA) or physical copy methods. Limiting the target area to on-chip Static Random Access Memory (SRAM) and configuring it as Device Memory ensures deterministic and immediate effectiveness of write operations, avoiding data latency or consistency issues that may arise from caching mechanisms. Atomic writing guarantees the integrity of the firmware image, preventing firmware corruption due to write interruptions and providing a reliable data foundation for the subsequent direct boot of the Management and Control Processing Unit (MCP).

[0056] Based on the aforementioned scheme, in some implementations of this application, the step of the trusted firmware ATF triggering the system control processor SCP to perform a reset operation on the management control processor MCP includes: the trusted firmware ATF sending a reset command to the system control processor SCP, so that the system control processor SCP, according to the reset command, operates the power processing unit PPU or a dedicated reset controller to perform an independent power domain reset operation on the management control processor MCP, causing the management control processor MCP to enter a reset state; after a preset delay, the reset state of the management control processor MCP is released, and a boot mode register is configured to instruct the management control processor MCP to boot from a preset memory area.

[0057] In this implementation, upon receiving a data-ready notification, the Trusted Firmware (ATF) sends a reset command to the System Control Processor (SCP). Based on this reset command, the SCP operates the Power Processing Unit (PPU) or a dedicated reset controller to perform an independent power domain reset operation on the Management Control Processor (MCP), putting it into a reset state. After a preset delay to ensure memory data stability, the SCP releases the MCP from its reset state and simultaneously configures the boot mode register, instructing the MCP to boot from a preset memory region.

[0058] It should be noted that by performing an independent power domain reset on the Management and Control Processor (MCP), only the MCP is reset while the main CPU and other cores continue to run, achieving uninterrupted hot updates. Simultaneously, the configuration of its boot mode register guides the MCP to boot directly from memory, bypassing the traditional Flash read path and compressing the update take-off time to the millisecond level.

[0059] Based on the aforementioned solution, please refer to Figure 4 In some implementations of this application, after the management control processor MCP starts from the preset memory area and loads the firmware image to be updated, the method further includes: step S105: obtaining the update result and new version number of the management control processor MCP; step S106: reporting the update result and the new version number as an audit event to the baseboard management controller BMC via the internal integrated circuit I²C bus or mailbox.

[0060] In this implementation, the update results are reported to the out-of-band management channel, i.e., to the Baseboard Management Controller (BMC), via the internal integrated circuit I²C bus or mailbox. This enables independent auditing and recording of hot update operations, and the update records can still be traced even if the main system fails.

[0061] To enable those skilled in the art to more intuitively understand this application, a specific example will be provided below. This example is an exemplary demonstration combining the overall technical paradigm of this application with some optional implementation details. It should be noted that the following demonstration is intended to aid understanding and does not constitute an exhaustive list of all embodiments of this application, nor does it imply that this application must include all the details described below in its specific implementation.

[0062] This example uses an ARMv8-A server platform as an example, illustrating a firmware hot update method for the Management Control Processor (MCP) initiated by the operating system kernel, verified by the Trusted Firmware TF (ATF), and coordinated by the System Control Processor (SCP). Specifically, this example processes firmware data packets through a four-stage pipeline: OS → Trusted Firmware TF → SCP → MCP, ultimately generating a verified and effective new MCP runtime state. The following section divides this example into multiple processing steps according to data processing logic, explaining the input, processing, and output of each step. The specific processing flow of this example is as follows: Step 1: The operating system (OS) kernel constructs and submits a firmware request package.

[0063] The input data for step 1 are: the physical address phys_addr and the target version number target_version of the management control processor MCP firmware binary image provided by user space.

[0064] The processing steps in step 1 are as follows: The kernel driver mcp_update.ko calls the kernel cryptographic module (such as crypto_sign_rsa_pss(phys_addr, KEK_pub)) to generate an RSA-PSS digital signature sig based on the platform private key; it constructs a structured request packet req_pkt, i.e., req_pkt = {phys_addr, target_ver, sig}, which contains the physical address phys_addr, the target version number target_ver, and the digital signature sig; and it calls the security monitor to invoke the first SMC instruction (smc(0x84000001, virt_to_phys(&req_pkt))), passing the physical address of the request packet as a parameter to the security world.

[0065] The output data of step 1 is: the physical address of the firmware request packet req_pkt_phys carrying the signature, which is passed to EL3 (abnormal level 3) via the security monitoring call exception channel to obtain the trusted firmware ATF.

[0066] In other words, step 1 transforms user intent into structured data with secure credentials, providing input for subsequent verification, and secure monitoring calls ensure that the data transmission path is protected by hardware isolation.

[0067] Step 2: The trusted firmware ATF intercepts security monitoring calls and parses request packets.

[0068] The input data for step 2 is: the physical address of the firmware request packet req_pkt_phys, which is read from general-purpose register x0 by the trusted firmware ATF after the security monitoring call is abnormally triggered.

[0069] The processing steps in step 2 are as follows: The exception handler maps the physical address of the firmware request packet to the secure world virtual address req_pkt_virt; it parses the request packet pointed to by the virtual address and extracts three pieces of data: physical address phys_addr, target version number target_ver, and digital signature sig.

[0070] The output data of step 2 is: the parsed structured parameters, namely the physical address phys_addr, the target version number target_ver, and the digital signature sig, which are used by the subsequent verification module.

[0071] In other words, step 2 completes the controlled data transfer from the insecure world to the secure world, avoiding the direct exposure of physical addresses to untrusted code.

[0072] Step 3: The trusted firmware ATF performs a two-factor security check.

[0073] The input data for step 3 are: the parsed physical address phys_addr, the target version number target_ver, the digital signature sig, and the platform public key KEK_pub_efuse burned into the one-time programmable fuse eFuse.

[0074] Step 3 involves the following steps: First, signature verification is performed by calling a secure cryptographic library function (such as crypto_verify_rsa_pss(phys_addr, sig, KEK_pub_efuse)) to verify the digital signature sig using the platform's public key, comparing the firmware hash value with the signature decryption result. Second, a version compatibility check is performed by reading the hardware capability register HW_CAP_REG to determine whether the power processing unit (PPU) control logic required by the target version number target_ver is supported by the current system-on-a-chip. If any verification fails, the process jumps to the error handling branch and returns an update rejection status (i.e., returns SMC_MCP_UPDATE_DENIED).

[0075] The output data of step 3 is: the verification pass flag verify_ok and the temporary authorization token auth_token.

[0076] In other words, step 3 ensures through double verification that only legitimate and compatible firmware can proceed to the next stage, thus blocking malicious or incompatible updates from the source.

[0077] Step 4: Trusted Firmware ATF Authorizes Operating System (OS) to Access Management Control Processor (MCP) Update Area.

[0078] Input data for step 4: temporary authorization token auth_token and management control processor MCP random access memory update area base address update_base, which is, for example, 0x8000_0000.

[0079] Step 4 involves configuring the Memory Management Unit (MMU) or Memory Protection Unit (MPU) to map the update region base address (update_base) to the Device Memory attribute, temporarily granting write permissions to EL1 (exception level 1), i.e., the operating system (OS); and writing an update-ready message (MSG_MCP_UPDATE_READY) to the System Controller Processor (SCP) via the mailbox to notify that the update region is ready.

[0080] The output data of step 4 is: the OS has write permissions to the Management Control Processor (MCP) Random Access Memory Update Zone (MCP_RAM_UPDATE_ZONE) accessible to the Management Control Processor (OS), and the System Control Processor (SCP) status register is set to the ready state (i.e., the System Control Processor (SCP) status register SCP_STATE = READY).

[0081] In other words, step 4, based on the principle of least privilege, only grants access to sensitive areas momentarily after verification, thus avoiding the risk of persistent permission leakage.

[0082] Step 5: The operating system (OS) writes the firmware data stream to the update area.

[0083] The input data for step 5 are: the firmware binary stream pointed to by the physical address phys_addr and its length fw_size, and the update base address update_base, which has been authorized and is in a writable state.

[0084] Step 5 involves calling the physical memory copy function memcpy_phys (the calling instruction is memcpy_phys(update_base, phys_addr, fw_size)) to transfer the firmware byte by byte from the storage area pointed to by the physical address phys_addr to the on-chip static random access memory SRAM pointed to by the update area base address update_base; after the write is completed, the second SMC instruction (such as smc(0x84000002)) is called through security monitoring to report the data readiness to the trusted firmware ATF.

[0085] The output data of step 5 is: the complete firmware image fw_image_in_sram located in the update area of ​​the random access memory of the management control processor MCP.

[0086] In other words, step 5 ensures that the write operation has no cache latency by utilizing the Device Memory property, achieving physical-level write atomicity and providing data consistency guarantee for subsequent resets.

[0087] Step 6: The trusted firmware ATF triggers the system control processor SCP to perform a precise reset of the management control processor MCP.

[0088] The input data for step 6 is: the data ready signal received by the trusted firmware ATF from the operating system OS.

[0089] Step 6 involves the following actions: The trusted firmware ATF sends a reset command MSG_MCP_RESET to the system controller SCP via the mailbox; the system controller SCP operates the power processing unit PPU or a dedicated reset controller, first setting the reset signal MCP_RST_N of the management controller MCP to put it into the reset state, and after a preset delay, such as 1 millisecond, to ensure that the static random access memory (SRAM) data is stable, clearing the reset signal to put it out of the reset state; at the same time, the boot mode register BOOT_MODE_REG is set to the random access memory boot mode BOOT_FROM_RAM, instructing the management controller MCP to boot from the static random access memory (SRAM).

[0090] The output data of step 6 is: the management control processor MCP reset completion signal MCP_RST_DONE and the status of the boot mode register set to random access memory boot mode (i.e., BOOT_MODE = RAM).

[0091] In other words, step 6 involves resetting the power domain of the management control processor (MCP) with precise control, while the main central processing unit continues to run. At the same time, the boot mode register guides the management control processor (MCP) to skip the flash boot read-only memory (Boot ROM) and directly execute the new firmware in the static random access memory (SRAM), which can improve read efficiency.

[0092] Step 7: The Management Control Processor (MCP) performs a self-test and determines the startup path.

[0093] The input data for step 7 are: the firmware image fw_image_in_sram in the update area of ​​the Management Control Processor (MCP) Random Access Memory, and the backup image backup_image in the backup area MCP_BACKUP_ZONE of the Management Control Processor (MCP).

[0094] Step 7 involves the following actions: Performing a Cyclic Redundancy Check (CRC) to calculate the CRC32 value of the firmware image fw_image_in_sram and comparing it with the pre-stored value in the image header. Attempting to initialize peripherals such as the Power Processing Unit (PPU) register and sensor interfaces. Based on the CRC and initialization results, a decision is made: if the CRC passes and peripheral initialization is successful, execution jumps to the firmware image entry point, and an update success event UPDATE_OK is sent to the Trusted Firmware ATF; if it fails, the backup image backup_image is automatically loaded and the startup is retried, with a maximum of two retries. If the retry still fails, safe mode is entered, and an update failure event UPDATE_FAIL is sent to the Trusted Firmware ATF.

[0095] The output data of step 7 is: the management control processor MCP running state mcp_running_state, including active state ACTIVE, rollback state ROLLBACK or safe mode state SAFE_MODE, and the corresponding event signal UPDATE_OK for successful update or UPDATE_FAIL for failed update.

[0096] In other words, step 7 is a built-in rollback mechanism to ensure that the system can recover itself when the update fails, avoiding platform crashes due to firmware corruption.

[0097] Step 8: The Trusted Firmware (ATF) sends the update result back to the operating system (OS).

[0098] The input data for step 8 is: the UPDATE_OK event sent by the Management Control Processor (MCP) indicating either a successful update or an UPDATE_FAIL event indicating an update failure.

[0099] The processing action in step 8 is as follows: The trusted firmware ATF notifies the operating system OS of the update success status (SMC_MCP_UPDATE_SUCCESS) or update failure status (SMC_MCP_UPDATE_FAILURE) through the security monitoring call return value, i.e., general-purpose register x0; the operating system OS driver updates the internal state machine and informs the user space through the input / output control ioctl return code.

[0100] The output data of step 8 is: update_result, which is visible to the user space, including SUCCESS, FAILURE, or ROLLBACK.

[0101] In other words, a complete closed-loop feedback can be formed through step 8, and the upper-layer application can execute operation and maintenance strategies based on the results, such as retrying or issuing alarms, while the main business process remains uninterrupted.

[0102] Step 9 (optionally), the system control processor SCP reports an audit event to the baseboard management controller BMC.

[0103] The input data for step 9 is: update result update_result and new version number of the management control processor MCP new_ver.

[0104] The processing action in step 9 is as follows: The system control processor SCP writes an event log containing a timestamp, update result update_result, and new version number new_ver to the baseboard management controller BMC via the internal integrated circuit I²C bus or mailbox.

[0105] The output data for step 9 is: audit records in the Baseboard Management Controller (BMC) log library.

[0106] In other words, this example achieves independent auditing and logging of hot update operations through step 9, which facilitates centralized management and troubleshooting.

[0107] Based on the unified inventive concept of firmware hot update methods for Management and Control Processors (MCPs), this application also provides a firmware hot update system for a Management and Control Processor (MCP), comprising: an operating system (OS) module, configured to: construct an update request package in response to a received firmware update request, the update request package including the address, version number, and digital signature of the firmware image to be updated; invoke a first SMC instruction via security monitoring to request a trusted firmware ATF module to verify and authorize the update request package; write the firmware image to be updated into a preset memory area in response to receiving verification and authorization pass information returned by the trusted firmware ATF module, the preset memory area being an update area dedicated to the Management and Control Processor (MCP) module; and send a data ready notification to the trusted firmware ATF module via a second SMC instruction. The trusted firmware ATF module is configured to: receive and verify the update request package sent by the operating system (OS) module, and return verification and authorization pass information to the operating system (OS) module after successful verification and authorization; and send a reset instruction to the system control processor (SCP) module. The System Control Processor (SCP) module is used to perform a reset operation on the Management Control Processor (MCP) module in response to a reset command sent by the Trusted Firmware (ATF) module. The Management Control Processor (MCP) module is used to boot from a preset memory area and load the firmware image to be updated after the reset.

[0108] For the specific implementation process of the above system, please refer to the firmware hot update method of the management and control processor MCP provided in the above embodiment, which will not be repeated here.

[0109] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within this application. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A firmware hot-update method for a management and control processor (MCP), characterized in that, Applied to an operating system (OS), the method includes: In response to a received firmware update request, an update request packet is constructed, the update request packet including the address, version number and digital signature of the firmware image to be updated; The first SMC instruction is invoked through security monitoring to request the trusted firmware ATF to verify and authorize the update request packet; In response to receiving the verification and authorization pass information returned by the trusted firmware ATF, the firmware image to be updated is written to a preset memory area, which is an update area dedicated to the management and control processor MCP. The second SMC instruction sends a data ready notification to the trusted firmware ATF, so that the trusted firmware ATF triggers the system control processor SCP to perform a reset operation on the management control processor MCP, so that the management control processor MCP starts from the preset memory area and loads the firmware image to be updated.

2. The method according to claim 1, characterized in that, The step of constructing an update request packet includes: Obtain the physical address of the firmware image to be updated, and use it as the address of the firmware image to be updated; The kernel cryptography module is invoked to perform a signature operation on the firmware image to be updated based on the platform private key, thereby generating the digital signature. The physical address, the version number, and the digital signature are encapsulated into structured data to obtain the update request packet.

3. The method according to claim 1, characterized in that, The steps of the trusted firmware ATF in verifying and authorizing the update request packet include: The Trusted Firmware ATF parses the update request packet to obtain the address, the version number, and the digital signature; The Trusted Firmware ATF verifies the legitimacy of the digital signature based on the pre-stored platform public key and checks the compatibility of the version number with the hardware capability register. If both verification and checks pass, the OS is informed that the verification and authorization have passed, thus authorizing the OS to access the preset memory region.

4. The method according to claim 3, characterized in that, The verification of the legality of the digital signature based on the pre-stored platform public key includes: The platform public key is read from the one-time programmable fuse eFuse. The platform public key is an asymmetric key paired with the platform private key, which is stored offline by the device manufacturer. Call the secure cryptographic library function and use the platform's public key to decrypt the digital signature to obtain the first hash value; Perform a hash operation on the firmware image to be updated indicated by the address to obtain a second hash value; Compare the first hash value with the second hash value to see if they match. If they match, the digital signature is deemed valid.

5. The method according to claim 3, characterized in that, The step of authorizing the operating system (OS) to access the preset memory region includes: Configure a memory management unit (MMU) or a memory protection unit (MPU) to temporarily map the base address of the preset memory region to an address space that the operating system (OS) is allowed to write to; wherein the access permission of the mapping is set to write-only.

6. The method according to claim 1, characterized in that, The verification and authorization pass information is generated and issued by the trusted firmware ATF after verifying that the digital signature has passed and confirming that the version number is compatible with the current hardware indicated by the hardware capability register.

7. The method according to claim 1, characterized in that, The step of writing the firmware image to be updated into a preset memory area includes: The firmware image to be updated is transferred from the storage area indicated by the address to the preset memory area through the Direct Memory Access (DMA) engine or physical memory copy function. The preset memory region is a reserved address space in the on-chip static random access memory (SRAM), and its memory attributes are configured as device memory, with caching disabled and write operations having atomicity.

8. The method according to claim 1, characterized in that, The steps of the trusted firmware ATF triggering the system control processor SCP to perform a reset operation on the management control processor MCP include: The trusted firmware ATF sends a reset command to the system control processor SCP, so that the system control processor SCP, according to the reset command, operates the power processing unit PPU or a dedicated reset controller to perform an independent power domain reset operation on the management control processor MCP, so that the management control processor MCP enters the reset state. After a preset delay, the reset state of the management and control processor MCP is released, and the boot mode register is configured to instruct the management and control processor MCP to boot from a preset memory area.

9. The method according to any one of claims 1-8, characterized in that, After the step of the management control processor (MCP) booting from the preset memory region and loading the firmware image to be updated, the method further includes: Obtain the update result and new version number of the Management Control Processor (MCP); The update result and the new version number are reported as an audit event to the Baseboard Management Controller (BMC) via the internal integrated circuit I²C bus or mailbox.

10. A firmware hot-update system for a management and control processor (MCP), characterized in that, include: The operating system (OS) module is used to construct an update request packet in response to a received firmware update request. The update request packet includes the address, version number, and digital signature of the firmware image to be updated. And for invoking the first SMC instruction via security monitoring to request the trusted firmware ATF module to verify and authorize the update request packet; And in response to receiving the verification and authorization pass information returned by the trusted firmware ATF module, the firmware image to be updated is written to a preset memory area, which is an update area dedicated to the management control processor MCP module. And for sending a data ready notification to the trusted firmware ATF module via a second SMC instruction; The Trusted Firmware (ATF) module is used to receive and verify update request packets sent by the operating system (OS) module, and return verification and authorization pass information to the OS module after verification and authorization pass; and to send reset commands to the system control processor (SCP) module. The system control processor (SCP) module is used to perform a reset operation on the management control processor (MCP) module in response to a reset command sent by the trusted firmware (ATF) module. The Management and Control Processor (MCP) module is used to boot from a preset memory area and load the firmware image to be updated after a reset.

Images