CN116881929A

CN116881929A - Safety protection method and device, electronic equipment and substrate controller chip

Info

Publication number: CN116881929A
Application number: CN202311144704.1A
Authority: CN
Inventors: 高明; 李宏宏; 杨清娜
Original assignee: Suzhou Inspur Intelligent Technology Co Ltd
Current assignee: Suzhou Inspur Intelligent Technology Co Ltd
Priority date: 2023-09-06
Filing date: 2023-09-06
Publication date: 2023-10-13
Anticipated expiration: 2043-09-06
Also published as: CN116881929B

Abstract

The embodiment of the application provides a safety protection method, a device, electronic equipment and a substrate controller chip, wherein the safety protection method is applied to substrate control and comprises the following steps: after the substrate controller is powered on, starting a real-time operating system in the substrate controller; under the condition that the real-time operating system is successfully started, executing the safety starting check of the substrate controller through the real-time operating system; after the safety start-up verification is passed, starting a non-real-time operating system in the substrate controller; the non-real time operating system accesses the hardware bus of the substrate controller by communicating with the real time operating system. According to the application, the problems that the hardware of the substrate controller needs to be changed and the cost is high when the substrate controller is subjected to safety protection in the related technology are solved, and the effect of safety protection of the substrate controller can be achieved under the condition that the hardware of the substrate controller does not need to be changed and additional devices do not need to be added.

Description

Safety protection method and device, electronic equipment and substrate controller chip

Technical Field

The embodiment of the application relates to the field of computers, in particular to a safety protection method and device, electronic equipment and a substrate controller chip.

Background

With the rapid development of technologies such as cloud computing, big data, artificial intelligence and the like, a server serves as an important infrastructure and plays an important role in digital economy.

The BMC (Baseboard Management Controller ) is a management system of servers, and is also a child node of a data center management network. The BMC can realize remote control and maintenance of the server, can comprehensively and finely monitor the server, provides rich and detailed logs, effectively improves the management efficiency of the server and reduces the operation cost. The BMC presents potential safety hazards, which threatens the safe operation of the server and affects the safe operation of the whole data center.

In order to protect the BMC, a PFR (Platform Firmware Resilience, platform firmware recovery) technology is proposed in the related art, which is used for protecting a platform asset, detecting malicious or erroneous behaviors such as damaging firmware, and recovering the platform firmware to a good state, and the technology uses a CPLD (Complex Programming logic device, complex programmable logic device) as a core, and performs functions such as secure boot verification and data management on a flash memory image of the BMC through the CPLD, so as to implement secure management on the whole BMC.

However, if PFR technology is used in existing projects, hardware of a server board must be changed, including using a more advanced CPLD, modifying a circuit of a motherboard PCB (Printed Circuit Board, chinese name, printed circuit board), and the like, so that implementation based on a wire network device is not possible and the cost is high.

Disclosure of Invention

The embodiment of the application provides a safety protection method, a safety protection device, electronic equipment and a substrate controller chip, which at least solve the problems that the hardware of the substrate controller needs to be changed and the cost is high when the substrate controller is subjected to safety protection in the related technology.

According to an embodiment of the present application, there is provided a security protection method applied to a substrate controller, on which a real-time operating system and a non-real-time operating system are running, the method including: after the substrate controller is powered on, starting a real-time operating system in the substrate controller; under the condition that the real-time operating system is successfully started, executing the safety starting check of the substrate controller through the real-time operating system; after the safety start-up verification is passed, starting a non-real-time operating system in the substrate controller; the non-real time operating system accesses the hardware bus of the substrate controller by communicating with the real time operating system.

In one exemplary embodiment, a flash memory of a baseboard controller stores a baseboard controller boot image, and the baseboard controller boot image is used for security boot verification, wherein the baseboard controller boot image comprises a real-time operating system partition, a non-real-time operating system partition and a firmware trusted partition.

In one exemplary embodiment, the live operating system partition includes a live operating system image area, a first root of trust area, and a live operating system signature area; before starting the real-time operating system in the substrate controller, the method further comprises: the method comprises the steps of obtaining a safe starting public key stored in a chip of a substrate controller, and calculating a signature on a mirror image area and a first trusted root area of a real-time operating system through the safe starting public key; judging whether the obtained signature is the same as the real-time operating system signature in the real-time operating system signature area, wherein the real-time operating system signature is obtained by encrypting the real-time operating system mirror image area and the first trusted root area through a secure starting private key; and starting the real-time operating system under the condition that the obtained signature is the same as the signature of the real-time operating system, and determining that the starting of the substrate controller fails under the condition that the obtained signature is different from the signature of the real-time operating system.

In one exemplary embodiment, the firmware trusted partition includes a first code signature area, a first image signature area, a firmware trusted data area, and a firmware trusted signature area, where the first code signature area stores a code signature public key; the performing a secure boot check of the substrate controller by the real-time operating system includes: verifying the code signature public key of the first code signature area, and determining that the starting of the substrate controller fails under the condition that the code signature public key fails to verify; under the condition that the code signature public key verification is successful, verifying the signature on the trusted data area of the firmware and the first mirror image signature area through the code signature public key; under the condition that the verification signature fails, determining that the starting of the substrate controller fails, and under the condition that the verification signature is successful, verifying the signatures of the whole real-time operating system partition and the whole non-real-time operating system partition through the code signature public key; and under the condition that the signature verification of the whole of the real-time operating system partition and the whole of the non-real-time operating system partition fails, determining that the safe start verification fails, and under the condition that the signature verification of the whole of the real-time operating system partition and the whole of the non-real-time operating system partition succeeds, determining that the safe start verification succeeds.

In one exemplary embodiment, the real-time operating system partition includes a first trusted root area, the first trusted root area stores a root public key, the first code signing area further stores a signature result of the code signing public key by a root private key, and verifying the code signing public key of the first code signing area includes: calculating a signature on the code signature public key in the first code signature area by using the root public key, and judging whether the obtained signature is the same as a signature result stored in the first code signature area; under the condition that the obtained signature is the same as the stored signature result, determining that the code signature public key verification is successful; and under the condition that the obtained digital signature is the same as the stored signature result, determining that the code signature public key fails to verify.

In one exemplary embodiment, the firmware trusted signature area stores a firmware trusted signature obtained by encrypting the first image signature area and the firmware trusted data area by a code signing private key, and verifying the signature of the firmware trusted data area and the first image signature area by the code signing public key includes: calculating signatures for the firmware trusted data area and the first mirror image signature area through the code signature public key, and judging whether the obtained signatures are the same as the firmware trusted signatures stored in the firmware trusted signature area; under the condition that the obtained signature is different from the firmware trusted signature, determining that verification of the signature fails; and under the condition that the obtained signature is the same as the firmware trusted signature, determining that the verification signature is successful.

In one exemplary embodiment, verifying the signature of the real-time operating system partition and the non-real-time operating system partition as a whole with the code signing public key comprises: calculating the integral signatures of the real-time operating system partition and the non-real-time operating system partition by using a code signature public key, and judging whether the obtained signature is the same as the image signature stored in the first image signature area, wherein the image signature is obtained by encrypting the integral of the real-time operating system partition and the non-real-time operating system partition by using a code signature private key; under the condition that the obtained signature is different from the mirror image signature, determining that the signature verification of the whole of the real-time operating system partition and the non-real-time operating system partition fails; and under the condition that the obtained signature is the same as the mirror image signature, determining that the signature verification of the whole of the real-time operating system partition and the non-real-time operating system partition is successful.

In one exemplary embodiment, the non-real time operating system partition includes a boot program, a kernel, and an application program, and in one exemplary embodiment, the booting the non-real time operating system in the baseboard controller includes: the real-time operating system starts a bootstrap program, the bootstrap program starts a kernel, and the kernel starts a non-real-time operating system; before the non-real-time operating system accesses the hardware bus of the substrate controller by communicating with the real-time operating system, the method further comprises: starting an application program by a non-real-time operating system; and under the condition that the application program is started, the non-real-time operating system executes read-write access operation on the hardware bus in a mode of communicating with the real-time operating system.

In one exemplary embodiment, including a bus command whitelist in a firmware trusted partition, a hardware bus for a non-real-time operating system to access a baseboard controller by communicating with a real-time operating system includes: the non-real-time operating system writes the hardware bus information and the read-write content into the shared memory, and triggers an interrupt notification real-time operating system; the real-time operating system acquires hardware bus information and read-write content from the shared memory, and verifies the hardware bus information through a bus command white list; when the hardware bus information passes the verification, the real-time operating system accesses the hardware bus according to the hardware bus information and the read-write content, writes the access result into the shared memory, and triggers an interrupt notification non-real-time operating system; the non-real-time operating system obtains the access result from the shared memory.

In an exemplary embodiment, the method further comprises: under the condition that the substrate controller receives the firmware recovery mirror image, analyzing from the firmware recovery mirror image to obtain a recovery header area and a recovery data area, wherein the recovery data area comprises a compressed data area and a compressed header area, the compressed data area stores the compressed original mirror image, the compressed header area stores compression information, and the recovery header area stores a signature result of the recovery data area; the real-time operating system verifies the recovery data area through the recovery head area; and under the condition that the verification of the recovery data area is successful, the original image is decompressed from the recovery data area based on the compression information, and the firmware is upgraded based on the original image.

In one exemplary embodiment, in a case where the firmware to be upgraded is the substrate controller firmware and the firmware recovery image is the substrate controller recovery image, the original image is the original substrate controller image, and performing the firmware upgrade based on the original image includes: closing the access function of the flash memory area where the substrate controller starting mirror image is located, writing the original substrate controller mirror image into the flash memory area where the substrate controller starting mirror image is located through the real-time operating system, and restarting the substrate controller.

In an exemplary embodiment, in a case where the firmware to be upgraded is a bios firmware and the firmware recovery image is a bios recovery image, the original image is an original bios image, and performing the firmware upgrade based on the original image includes: and closing the server host, writing the original basic input output system image into a flash memory area running the basic input output system image through the real-time operating system, and restarting the server host.

In one exemplary embodiment, in a case where the firmware to be upgraded is complex programmable logic device firmware and the firmware recovery image is complex programmable logic device recovery image, the original image is the original complex programmable logic device image, performing firmware upgrade based on the original image includes: stopping the use function of the firmware of the complex programmable logic device, writing the original complex programmable logic device image into a flash memory area running the complex programmable logic device image through the real-time operating system, and restarting the complex programmable logic device.

In one exemplary embodiment, in a case where the firmware to be upgraded is a field programmable gate array firmware and the firmware recovery image is a field programmable gate array recovery image, the original image is an original field programmable gate array image, performing the firmware upgrade based on the original image includes: stopping the use function of the field programmable gate array firmware, writing the original field programmable gate array mirror image into a flash memory area running the field programmable gate array mirror image through the real-time operating system, and restarting the field programmable gate array.

In an exemplary embodiment, the method further comprises: under the condition that the real-time operating system detects damaged firmware, the real-time operating system reads a firmware recovery mirror image from a flash memory of a substrate controller, wherein the firmware recovery mirror image comprises a recovery head area and a recovery data area, the recovery data area comprises a compressed data area and a compressed head area, the compressed data area stores a compressed original mirror image, the compressed head area stores compressed information, and the recovery head area stores a signature result of the recovery data area; the real-time operating system verifies the recovery data area through the recovery head area; and under the condition that the verification of the recovery data area is successful, the original image is decompressed from the recovery data area based on the compressed information, and firmware recovery is performed based on the original image.

In one exemplary embodiment, the recovery header area includes a second root of trust area, a second code signature area, and a second image signature area, the second root of trust area storing a root public key, and verifying the recovery header area by the real-time operating system includes: calculating a signature on a code signature public key in a second code signature area by using a root public key, and judging whether the obtained signature is identical to a first signature result in the second code signature area, wherein the first signature result is obtained by signing the code signature public key through a root private key; under the condition that the obtained signature is the same as the first signature result, calculating the signature on the recovery data area by using a code signature public key, and judging whether the obtained signature is the same as a second signature result in a second mirror image signature area, wherein the second signature result is obtained by signing the recovery data area by using a code signature private key; and under the condition that the obtained signature is the same as the second signature result, determining that the verification of the recovery data area is successful, and under the condition that the obtained signature is different from the second signature result, determining that the verification of the recovery data area is failed.

According to another embodiment of the present application, there is provided a safety device applied to a substrate controller on which a real-time operating system and a non-real-time operating system are running, the device including: the first starting unit is used for starting a real-time operating system in the substrate controller after the substrate controller is electrified; the safety starting verification unit is used for executing safety starting verification of the substrate controller through the real-time operating system under the condition that the real-time operating system is successfully started; the second starting unit is used for starting the non-real-time operating system in the substrate controller after the safety starting verification is passed; and the access unit is used for accessing the hardware bus of the substrate controller by the non-real-time operating system in a mode of communicating with the real-time operating system.

According to a further embodiment of the application, there is also provided a computer readable storage medium having stored therein a computer program, wherein the computer program is arranged to perform the steps of any of the method embodiments described above when run.

According to a further embodiment of the application there is also provided an electronic device comprising a memory having stored therein a computer program and a processor arranged to run the computer program to perform the steps of any of the method embodiments described above.

According to the application, after the substrate controller is electrified, the safety starting verification of the substrate controller is executed by means of the characteristics of rapid starting, light weight, timely response and the like of the real-time operating system, after the safety starting verification is passed, the non-real-time operating system in the substrate controller is started, and the non-real-time operating system accesses the hardware bus of the substrate controller in a mode of communicating with the real-time operating system to ensure the safety of the hardware bus in running and improve the safety of the whole server system, so that the problems that the hardware of the substrate controller is required to be changed and the cost is high when the substrate controller is safely protected in the related art are solved, and the effect of safety protection of the substrate controller can be realized under the condition that the hardware of the substrate controller is not required to be changed and additional devices are not required to be added.

Drawings

Fig. 1 is a block diagram of a hardware structure of a mobile terminal of a security protection method according to an embodiment of the present application;

FIG. 2 is a schematic diagram of an embedded system of the present embodiment;

FIG. 3 is a schematic diagram of an alternative embedded system of the present embodiment;

FIG. 4 is a flow chart of a method of safeguarding in accordance with an embodiment of the present application;

FIG. 5 is a flow chart of generating a substrate controller boot image according to an embodiment of the application;

FIG. 6 is a schematic diagram of a substrate controller boot image in accordance with an embodiment of the present application;

FIG. 7 is a method of safeguarding a substrate controller during a start-up phase in accordance with an embodiment of the present application;

FIG. 8 is a method of safeguarding an operational phase of a substrate controller according to an embodiment of the application;

FIG. 9 is a schematic diagram of a substrate controller mirror region according to an embodiment of the application;

FIG. 10 is a schematic diagram of the structure of a firmware restore mirror area according to an embodiment of the application;

FIG. 11 is a flow chart of generating a firmware recovery image in accordance with an embodiment of the present application;

FIG. 12 is a flow chart of a firmware upgrade according to an embodiment of the present application;

FIG. 13 is a flow chart of firmware recovery according to an embodiment of the application;

fig. 14 is a block diagram of a safety shield apparatus in accordance with an embodiment of the present application.

Detailed Description

Embodiments of the present application will be described in detail below with reference to the accompanying drawings in conjunction with the embodiments.

It should be noted that the terms "first," "second," and the like in the description and the claims of the present application and the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order.

The method embodiments provided in the embodiments of the present application may be performed in a mobile terminal, a computer terminal or similar computing device. Taking the operation on a mobile terminal as an example, fig. 1 is a block diagram of a hardware structure of a mobile terminal of a security protection method according to an embodiment of the present application. As shown in fig. 1, the mobile terminal may include one or more (only one is shown in fig. 1) processors 102 and a memory 104 for storing data, and the processors 102 may include, but are not limited to, a microprocessor (Microcontroller Unit, MCU) or a programmable logic device (Field Programmable Gate Array, FPGA) or the like processing means, wherein the mobile terminal may further include a transmission device 106 for communication functions and an input-output device 108. It will be appreciated by those skilled in the art that the structure shown in fig. 1 is merely illustrative and not limiting of the structure of the mobile terminal described above. For example, the mobile terminal may also include more or fewer components than shown in fig. 1, or have a different configuration than shown in fig. 1.

The memory 104 may be used to store computer programs, such as software programs and modules of application software, such as computer programs corresponding to the security protection method in the embodiment of the present application, and the processor 102 executes the computer programs stored in the memory 104 to perform various functional applications and data processing, that is, implement the method described above. Memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include memory remotely located relative to the processor 102, which may be connected to the mobile terminal via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The transmission device 106 is used to receive or transmit data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider of the mobile terminal. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, simply referred to as NIC) that can connect to other network devices through a base station to communicate with the internet. In one example, the transmission device 106 may be a Radio Frequency (RF) module, which is configured to communicate with the internet wirelessly.

In this embodiment, an embedded system is provided, which may be operated on the mobile terminal, and fig. 2 is a schematic diagram of the embedded system in this embodiment, as shown in fig. 2, where the embedded system may include:

a chip and at least two operating systems, wherein the chip comprises a processor 1102, a hardware controller 1104, a first bus 1106 and a second bus 1108, wherein the bandwidth of the first bus 1106 is higher than the bandwidth of the second bus 1108, and the first bus 1106 is configured in a multi-master multi-slave mode and the second bus 1108 is configured in a master multi-slave mode; at least two operating systems run based on the processor 1102; at least two operating systems communicate over a first bus 1106; at least two operating systems implement control of the hardware controller via a second bus 1108.

Wherein, the chip can be a BMC chip; the processor may be a multi-core processor, and the hardware controller may be configured to control an external device connected to a corresponding external interface.

And the BMC chip realizes interconnection among the on-chip ARM core, the storage unit and the controller hardware resource through the first bus and the second bus. The ARM core is interconnected with each controller through a second bus, so that interaction between the core and each controller is realized. Meanwhile, ARM cores are connected to a first bus (for example, the ARM cores can be connected through an AXI (Advanced eXtensible Interface) Bridge), and communication between the cores is realized through the first bus.

The first bus is configured in a multi-master multi-slave mode, which may be a bus used for communication among a plurality of processor cores of a processor, for example, an AHB (Advanced High Performance Bus, advanced high-performance bus), and the second bus is configured in a one-master multi-slave mode, which may be a bus used for control between a processor and a hardware controller, for example, an APB (Advanced Peripheral Bus, peripheral bus), the bandwidth of the first bus being higher than the bandwidth of the second bus.

In one exemplary embodiment, the AHB is configured in a multi-master (master) multi-slave (slave) mode, the master will first send a burst request to the arbiter, the arbiter decides the right to get the master access to the bus properly, the master will send data and control signals to the arbiter after getting the right, the arbiter will determine the corresponding slave path through address resolution, and then send the request to the corresponding destination. The data of the same response is parsed by the decoder and then returned to the corresponding master. Many-to-many access is achieved through this multiplexed mechanism.

In an exemplary embodiment, the APB is configured in a master-multiple slave mode, the APB is suspended under the AHB bus system, and transactions are converted between the AHB bus systems by the AHB-APB Bridge, where Bridge is the master of the APB, and other peripheral devices are slave. The data request can only be sent to slave by Master, and the slave returns corresponding response data to Master after receiving the request, and the process can realize one-to-many access, and the access does not involve arbitration and Decoder parsing operation in AHB bus.

The embedded system may include at least two operating systems, the at least two operating systems being based on the processor running, and processing resources of the processor being dynamically allocated to the at least two operating systems, the processing resources of the processor including a processor core, the at least two operating systems communicating over a first bus, the at least two operating systems implementing control of the hardware controller over a second bus.

The first operating system may be an operating system with a well-defined fixed time constraint, where all processing (task scheduling) needs to be done within the fixed time constraint, otherwise the system may be in error, which may be a real-time operating system (Real Time Operating System, RTOS for short, refers to an operating system that can accept and process with a sufficiently fast speed when external events or data are generated, and whose processing results can control the production process or make a fast response to the processing system within a specified time, schedule all available resources to complete real-time tasks, and control all real-time tasks to run in coordination. The second operating system does not have the feature, and the second operating system generally adopts a fair task scheduling algorithm, when the number of threads/processes increases, the CPU time needs to be shared, task debugging has uncertainty, and can be called as a non-real-time operating system, for example, contiki, heliOS, linux (collectively called GNU/Linux, a set of freely-transmissible Unix-like operating systems) or the like, and can also be a non-real-time operating system in other embedded systems, wherein the Linux system is a multi-user, multi-task and multi-CPU supporting operating system based on POSIX (Portable Operating System Interface ).

In one exemplary embodiment, the hardware controller may include one or more of a corresponding controller of a chip peripheral device that may include, but is not limited to, at least one of: I2C, USB (Universal Serial Bus ), UART (Universal Asynchronous Receiver/Transmitter, universal asynchronous receiver Transmitter), ADC (Analog to Digital Converter ), JTAG (Joint Test Action Group, joint test workgroup), RTC (Real Time Clock), GPIO (General Purpose Input/Output, universal input/Output), WDT (Watch Dog Timer), virtual UART (Virtual UART), super I/O (Super I/O), SGPIO (Serial General Purpose Input/Output, serial universal input/Output), PWM (Pulse Width Modulation ), fanTach (fan speed), timer (Clock), PECI (Platform Environment Control Interface ), mailBox (MailBox), but other types of controllers may also be included. The external interface may include one or more, and may include, but is not limited to, an external interface corresponding to any of the controllers described above.

Through the embedded system, the first operating system and the second operating system run based on the processor, and communication among the operating systems and control of the hardware controller are realized through buses with different functions. Because the first operating system and the second operating system are operated based on the same processor, the increase and the deployment of hardware devices are avoided, the system cost is reduced, and the operation between the processor resource support systems is reasonably utilized, so that the technical problem of lower operation efficiency of the operating systems can be solved, and the technical effect of improving the operation efficiency of the operating systems is achieved.

According to another aspect of the embodiment of the present application, there is further provided an embedded system, where the embedded system may be running on the BMC chip, and fig. 3 is a schematic diagram of an optional embedded system of the present embodiment, and as shown in fig. 3, the embedded system may include:

the real-time operating system and the non-real-time operating system are operated on the processor, and the response speed of the real-time operating system is higher than that of the non-real-time operating system; the real-time operating system and the non-real-time operating system may be similar to those in the foregoing embodiments, and it should be noted that, in the running process of the embedded system, the operating system may be started first, and then, the different operating systems perform interaction of service data.

In an exemplary embodiment, the real-time operating system and the non-real-time operating system may be started sequentially, the real-time operating system may be started faster than the non-real-time operating system, the real-time operating system may be started simpler than the non-real-time operating system, the non-real-time operating system may be started first and then the non-real-time operating system may be operated to meet the condition required by the non-real-time operating system, or the service started by the non-real-time operating system may be accelerated, so that the multi-system may start and operate the service more efficiently and rapidly.

Alternatively, in this embodiment, the real-time operating system may be, but is not limited to being, booted by a boot program of the real-time operating system, and the non-real-time operating system may be, but is not limited to being, booted by a boot program of the non-real-time operating system. Alternatively, both may be booted by the same boot program.

In one exemplary embodiment, the real-time operating system boot may be, but is not limited to, directed in the following manner: the chip is started to be electrified, and a first processor core distributed for the real-time operating system in the processor is awakened by the processor; and executing a bootstrap program of the real-time operating system through the first processor core to guide the real-time operating system to start.

Such as: under the safety protection scene of the server system, after the real-time operating system is guided to be started, the real-time operating system can carry out the safety verification of the starting stage of the substrate controller, and under the condition that the safety verification of the starting stage is successful, the non-real-time operating system is restarted, so that the safety of the system is improved.

In one exemplary embodiment, the interaction process may be implemented by, but is not limited to, adopting a mode of combining a storage space and an interrupt request to transmit, transmitting data between operating systems through the storage space, and notifying instructions between each other through the interrupt request. Alternatively, in this embodiment, the service data interacted between the operating systems may be, but is not limited to, any data that needs to be transmitted between the systems during the operation of the operating system to run the operation service. Such as: process data for the business, result data for the business, etc.

Such as: under the safety protection scene of the server system, the non-real-time operating system stores the hardware bus information and the read-write content into a storage space on the processor, and sends an interrupt request to the real-time operating system, wherein the interrupt request is used for requesting the real-time operating system to read the hardware bus information and the read-write content from the storage space so as to access the hardware bus, and the real-time operating system is used for responding to the interrupt request to read the hardware bus information and the read-write content from the storage space and accessing the hardware bus under the condition that the hardware bus information passes the verification.

Optionally, in this embodiment, after the real-time operating system accesses the hardware bus to obtain the access result, the access result is stored in a storage space on the processor, the non-real-time operating system is notified by the interrupt request, and the non-real-time operating system reads the access result from the storage space, thereby implementing access to the hardware bus.

For example, the device may be accessed via a 12C (Inter-Integrated Circuit) bus, I2C bus is a simple, bi-directional two-wire synchronous serial bus that requires only two wires to transfer information between devices connected to the bus; for another example, the flash memory may be accessed through an SPI (Serial Peripheral Interface ) bus, which is a high-speed, full duplex, synchronous communication bus, and occupies only four wires on the pins of the chip, saving pins of the chip, while saving space on the layout of the PCB, providing convenience, and more chips integrate such communication protocols, just for the simple and easy-to-use feature.

Alternatively, in this embodiment, a storage space on the processor may be, but is not limited to, a storage location dedicated to the interaction process between the operating systems, which may be referred to as a shared memory. The information (such as a storage address) of the shared memory corresponding to the real-time operating system may be carried in an interrupt request for requesting the non-real-time operating system to read the service data from the storage space, where the non-real-time operating system responds to the interrupt request and reads the service data from the shared memory indicated by the interrupt request.

In this embodiment, the interrupt requests may be transmitted between systems by means of a software protocol, or may be transferred through a hardware module. Taking a hardware module mailbox form as an example to transmit an interrupt request, a mailbox channel can be established between the real-time operating system and the non-real-time operating system, service data is read and written through a storage space, and the interrupt request is transmitted through the mailbox channel.

Through the embodiment, under the security protection scene of the server system, the embedded system of the embodiment can realize the secure start of the firmware and the secure operation of the firmware. The firmware safe start is to run the real-time operating system at first in the system start stage, make use of the characteristics of quick start, light weight, timely response and the like of the real-time operating system to perform the safe check of the system start stage, and restart the non-real-time operating system after the safe check passes, and enter the system normal operation stage when the start of the non-real-time operating system is completed. The firmware safe operation means that in the normal operation stage, the non-real-time operating system completes read-write access to the hardware bus in a mode of communicating with the real-time operating system, thereby realizing monitoring and protection of the system hardware bus, ensuring bus safety during operation and improving the overall safety of the system.

In an exemplary embodiment, firmware upgrade and recovery can also be implemented by the embedded system of the present embodiment, where firmware upgrade refers to that, when a server has a firmware upgrade requirement, after a security check of an realtime operating system on an uploaded firmware image passes, an image file is written into a storage location of a component to be upgraded by the realtime operating system, so as to complete the upgrade of the firmware image. Firmware recovery refers to that when the real-time operating system detects that the firmware is damaged, firmware backup stored in the flash memory area is read, and after the security verification of the backup firmware is completed, the backup firmware is recovered to the memory of the damaged firmware, and before the recovery of the firmware image is completed.

Fig. 4 is a flowchart of a security protection method according to an embodiment of the present application, implemented by the embedded system of the above embodiment, as shown in fig. 4, the flowchart includes the following steps:

in step S402, after the substrate controller is powered on, the real-time operating system in the substrate controller is started.

It should be noted that, the baseboard management controller is a remote management controller of the server, and can perform operations such as firmware upgrade and checking equipment on the server in a state that the server is not started, so that the security start verification of the baseboard controller is particularly important.

The embedded system is operated in the substrate controller, and the embedded system comprises a real-time operating system and a non-real-time operating system, and the real-time operating system has the characteristics of quick starting, light weight, timely response and the like.

Step S404, under the condition that the starting of the real-time operating system is successful, the safety starting verification of the substrate controller is executed through the real-time operating system.

It should be noted that, the firmware trusted partition stores a first image signature, firmware trusted data, a firmware trusted signature and a signature result of a public key corresponding to a private key used by the two signatures, where the firmware trusted signature is a signature result of the first image signature and the firmware trusted data, the first image signature is a signature result of an entire real-time operating system partition and a non-real-time operating system partition, and the firmware trusted partition includes a bus command whitelist. The method comprises the steps of reading a substrate controller to start an image through a real-time operating system, verifying signature results of public keys corresponding to private keys used by all signatures, indicating that safety starting verification fails under the condition that verification is not passed, verifying signature results of first image signatures and firmware trusted data through the public keys under the condition that verification is passed, verifying integral signature results of a real-time operating system partition and a non-real-time operating system partition under the condition that verification is passed, indicating that safety starting verification is successful under the condition that verification is not passed, and indicating that safety starting verification fails under the condition that verification is not passed.

In step S406, after the secure boot verification is passed, the non-real-time operating system in the substrate controller is started.

It should be noted that, the non-real-time operating system needs to access the device connected to the hardware bus by accessing the hardware bus, and after the secure boot verification is passed, the non-real-time operating system in the substrate controller is restarted, so that the security of accessing the hardware bus can be improved.

In step S408, the non-real-time operating system accesses the hardware bus of the substrate controller by communicating with the real-time operating system.

In an exemplary embodiment, the non-real-time operating system may write the hardware bus information and the read-write contents into the shared memory, notify the real-time operating system by means of an interrupt, verify the hardware bus information, access the hardware bus if the hardware bus information is verified, execute the access operation and write the access result into the shared memory, notify the non-real-time operating system by means of an interrupt, and acquire the access result again. In this embodiment, the non-real-time operating system does not directly access the hardware bus, but indirectly accesses the hardware bus by communicating with the real-time operating system, thereby improving the security of accessing the hardware bus.

Through the steps, after the substrate controller is electrified, the safety starting verification of the substrate controller is executed by means of the characteristics of rapid starting, light weight, timely response and the like of the real-time operating system, after the safety starting verification is passed, the non-real-time operating system in the substrate controller is started, the non-real-time operating system accesses the hardware bus of the substrate controller in a mode of communicating with the real-time operating system to ensure the safety of the hardware bus in the running process, and the overall safety of the server system is improved, so that the problems that the hardware of the substrate controller needs to be changed and the cost is high when the substrate controller is safely protected in the related art are solved, and the effect of safely protecting the substrate controller is achieved under the condition that the hardware of the substrate controller does not need to be changed and additional devices are not required to be added.

It should be noted that, before the secure boot verification is implemented based on the boot image of the substrate controller, the boot image of the substrate controller needs to be made. Fig. 5 is a flowchart of generating a substrate controller boot image according to an embodiment of the present application, and as shown in fig. 5, the process of generating the substrate controller boot image includes the steps of:

First, the real-time operating system partition is divided into a real-time operating system mirror region, a first trusted root region and a real-time operating system signature region. Compiling to generate a real-time operating system image, storing the real-time operating system image into a real-time operating system image area, writing a root public key into a first trusted root area, then integrally calculating a signature on the real-time operating system image area and the first trusted root area by using a safe starting private key, writing a result into a real-time operating system signature area, and generating data of the whole real-time operating system partition.

Second, the non-real time operating system partition is divided into a bootstrap partition, a kernel partition, and an application partition. Generating a bootstrap program, a kernel and an application program, and writing the bootstrap program, the kernel and the application program into corresponding partitions.

Further, the firmware trusted partition is divided into a first code signature area, a first mirror signature area, a firmware trusted data area and a firmware trusted signature area. Writing the code signature public key into the first code signature area to obtain a code signature public key area, calculating a signature on the code signature public key area by using the root private key, and writing the result into the code signature public key signature area.

And then, the code signature public key is used for integrally calculating the signature of the real-time operating system partition and the non-real-time operating system partition, a first image signature is obtained, and the first image signature is written into the first image signature area. And then writing the firmware trusted data in the firmware trusted data area, signing the first mirror image signing area and the firmware trusted data area as a whole by using a code signing public key, writing the result into the firmware trusted signing area, and finally packaging to generate a whole substrate controller starting mirror image.

FIG. 6 is a schematic diagram of a boot image of a substrate controller according to an embodiment of the present application, where the boot image of the substrate controller includes 5 partitions as shown in FIG. 6: a real-time operating system partition, a boot partition, a kernel partition, and an application partition, a firmware trusted partition.

The real-time operating system partition comprises a real-time operating system mirror image area, a first trusted root area and a real-time operating system signature area, wherein a root public key is stored in the first trusted root area, a real-time operating system signature is stored in the real-time operating system signature area, and the real-time operating system signature is a result obtained by calculating signatures of the real-time operating system mirror image area and the first trusted root area through a safe starting private key in a mirror image compiling stage.

The boot partition is used for storing a binary Uboot, which is a boot loader used for booting a starting kernel, that is, reading the kernel from the flash memory, placing the kernel into the memory, and starting the kernel. The boot loader is put on the flash memory just before, the boot loader is executed first after the substrate controller is powered on, the boot loader completes hardware initialization, sets a processor mode, closes a watchdog, shields interrupts, initializes the synchronous dynamic random access memory, sets a stack, sets a clock, and boots the kernel from the flash memory to the memory. The kernel partition is used for storing non-real-time operation and image files of the system kernel. The application program partition is used for storing the library functions, the file system and most executable programs.

The firmware trusted partition comprises a first code signature area, a first mirror image signature area, a firmware trusted data area and a firmware trusted signature area. The first code signing area stores two parts of data, one part is the code signing public key, the other part is the signing result of the code signing public key, and the signing uses the root private key. Stored in the first image signature area is a signature value for the live operating system partition and the non-live operating system partition as a whole by using a code signature private key. The firmware trusted data area comprises two areas, one is a bus command white list for recording a white list of access objects allowed to access the hardware bus, and the other is flash memory partition information. The firmware trusted signature area stores a firmware trusted signature, and the firmware trusted signature is a signature value of the first mirror image signature area and the firmware trusted data area as a whole by using a code signature private key.

It should be noted that, the starting process of the substrate controller starting mirror image for the whole system provides protection in the form of a digital signature chain, and 3 groups of asymmetric keys are used, including a secure starting private key and a secure starting public key, a root private key and a root public key, and a code signing private key and a code signing public key. The secure boot private key is used for calculating signatures for the real-time operating system image area and the first trusted root area of the real-time operating system partition, and the secure boot public key is stored in the boot chip and used for checking and protecting the real-time operating system image area and the first trusted root area of the real-time operating system partition. The root private key is used to calculate a signature over the protection code signature public key, and the root public key is used to verify the protection code signature public key. The code signature private key is used for calculating the signature on the first image signature area and the firmware trusted data area of the firmware trusted partition, and the code signature public key is used for checking and protecting the first image signature area and the firmware trusted data area of the firmware trusted partition.

It should be noted that, in this embodiment, in the stage of generating the mirror image of the substrate controller, the signature is calculated on the mirror image area of the real-time operating system and the first trusted root area by using the secure start private key, before the real-time operating system in the substrate controller is started, the signature verification is performed on the mirror image area of the real-time operating system and the first trusted root area by using the secure start public key stored in the start chip, and under the condition that the signature verification is passed, the real-time operating system can be started safely, thereby realizing the start protection of the real-time operating system itself.

In the generation stage of the boot image of the substrate controller, the signature is calculated on the trusted data area of the firmware and the first image signature area through the code signature private key, the signature is calculated on the whole of the real-time operating system partition and the non-real-time operating system partition, and the security of the code signature private key is important.

In the generation stage of the mirror image started by the substrate controller, the signature is calculated on the code signature public key through the root private key, and the calculated signature is stored in the first code signature area, so that the code signature public key is subjected to signature verification through the root public key to verify the validity of the code signature public key. The root public key is stored in the first trusted root area, and can be obtained from the first trusted root area under the condition that the verification signature of the real-time operating system mirror image area and the first trusted root area passes through the secure start public key before the real-time operating system is started.

That is, in the case where the code signing public key verification is successful, the entire of the firmware trusted data area and the first image signing area is signed by the code signing public key verification.

That is, in the case that the code signing public key verification is successful, the signature is verified on the real-time operating system partition and the non-real-time operating system partition as a whole by the code signing public key. Since the real-time operating system has been started, the non-real-time operating system may be started in the case where the real-time operating system partition and the non-real-time operating system partition integrally verify that the signature passes.

In one exemplary embodiment, the non-real time operating system partition includes a boot program, a kernel, and an application program, and booting the non-real time operating system in the substrate controller includes: the real-time operating system starts a bootstrap program, the bootstrap program starts a kernel, and the kernel starts a non-real-time operating system; before the non-real-time operating system accesses the hardware bus of the substrate controller by communicating with the real-time operating system, the method further comprises: starting an application program by a non-real-time operating system; and under the condition that the application program is started, the non-real-time operating system executes read-write access operation on the hardware bus in a mode of communicating with the real-time operating system.

The non-real-time operating system controls the application program to start in the starting process, and lays a foundation for the non-real-time operating system to execute read-write access operation on the hardware bus.

In an alternative exemplary embodiment, the real-time operating system is a FreeRTOS operating system, the non-real-time operating system is a Linux operating system, and fig. 7 is a method for protecting the start-up phase of the substrate controller according to an embodiment of the present application, as shown in fig. 7, the method includes:

After the substrate controller system is powered on and started, the starting chip initially checks the RTOS partition: and calculating a digital signature for the RTOS partition by using a secure start public key stored in the substrate controller chip, comparing the result with an RTOS signature stored in the RTOS signature area, if the comparison fails, starting the system, and if the comparison succeeds, starting the RTOS system.

After the RTOS system operates normally, the root public key is used to verify the first code signature region: and calculating a digital signature for the code protection public key area in the first code signature area by using the root public key, comparing the result with the code protection public key signature stored in the first code signature area, wherein the comparison fails, the system is started and succeeds, and the legitimacy of the code protection public key is verified.

Then, the firmware trusted signature area is verified using the code protection public key: taking the firmware trusted data area and the first mirror image signature area as a whole, calculating a digital signature on the firmware trusted data area and the first mirror image signature area by using a code protection public key, comparing the result with the firmware trusted signature stored in the firmware trusted signature area, if the comparison fails, starting the system to fail, and if the comparison is successful, continuing to check the first mirror image signature area by using the code protection public key: and calculating the digital signature of the whole of the real-time operating system partition and the non-real-time operating system partition by using a code protection public key, comparing the calculation result with the image signature of the first image signature area, if the calculation result is failed, completing the security check part in the whole starting process of the system after the failure of the system starting, executing a normal starting process, starting a bootstrap program by using an RTOS (real time operating system), starting an application program by using the bootstrap program, and entering a system operation stage when the application program is completely started and the starting of the whole substrate controller system is completed.

It should be noted that, in this embodiment, in the operation stage of the substrate controller, two sets of operating systems of the multi-core processor work simultaneously, where the main processor runs a non-real-time operating system, the coprocessor runs a real-time operating system, and the real-time operating system grasps the read-write control right (for example, I2C bus and SPI bus) of the system hardware bus, and the non-real-time operating side has no read-write right of the hardware bus, so as to implement indirect access of the hardware bus. When the hardware bus is needed to be used in the non-real-time operation, the non-real-time operation communicates with the real-time operation system in a mode of inter-core interrupt and shared memory, the real-time operation system is informed of the bus number, address and read-write content to be accessed, the real-time operation is used for checking the bus number, the hardware bus is actually accessed under the condition that the checking is passed, an access result is obtained, and then the non-real-time operation system is returned in a mode of inter-core interrupt and shared memory.

In an alternative exemplary embodiment, the real-time operating system is a FreeRTOS operating system, the non-real-time operating system is a Linux operating system, the hardware bus to be accessed is an I2C bus, and fig. 8 is a method for protecting the security of the operation stage of the substrate controller according to an embodiment of the present application, as shown in fig. 8, the method includes:

when a Linux system needs to access equipment on an I2C bus, an agent mode is initiated to access the I2C bus, the Linux system writes information such as the bus number of the I2C, the equipment slave address, access content and the like into a shared memory, triggers an interrupt to inform an RTOS system, acquires data transmitted by the Linux system from the shared memory after the RTOS system receives an interrupt message, acquires I2C white list data from a firmware trusted data area in a substrate controller starting mirror image, performs validity check on the I2C bus number and the equipment slave address according to the I2C white list data, judges whether the I2C bus and the equipment slave address which are allowed to be accessed in a white list are permitted, refuses to access under the condition of no, and returns error information to the Linux system; under the condition that the information is provided by the Linux system, the RTOS system accesses the hardware equipment on the I2C bus to obtain an access result, writes the access result into the shared memory, triggers an interrupt and notifies the Linux system, and after the Linux system receives the notification, the Linux system takes the I2C access result from the shared memory, so that the whole I2C access process is completed.

According to the embodiment, the real-time operating system realizes the proxy access of the non-real-time operation to the hardware bus, and the real-time operating system performs white list verification on the command on the hardware bus, so that the safety protection of the operation stage of the substrate controller is realized.

It should be noted that, in the working process of the substrate controller, there is a need for firmware upgrade, and in order to ensure the security of firmware upgrade, the embodiment uses a real-time operating system to implement the security upgrade of firmware, where the real-time operating system uses a firmware recovery mirror image to implement the security upgrade of firmware.

In this embodiment, firmware upgrade and recovery are described by taking a baseboard controller (BMC), a basic input output system (BIOS, basic Input Output System), a Complex Programmable Logic Device (CPLD), and a programmable logic device (FPGA) as examples, and fig. 9 is a schematic diagram of a baseboard controller mirror area according to an embodiment of the present application, where the baseboard controller mirror area includes a baseboard controller start mirror area and a firmware recovery mirror area, and as shown in fig. 9, the firmware recovery mirror area may include a baseboard controller recovery mirror area, a basic input output system recovery mirror area, a complex programmable logic device recovery mirror area, and a programmable logic device recovery mirror area.

FIG. 10 is a schematic diagram of a firmware recovery image area according to an embodiment of the present application, and as shown in FIG. 10, each type of firmware recovery image area may include:

the recovery head area comprises a second trusted root area, a second code signing area and a second mirror image signing area, wherein the second trusted root area stores a root public key, the second code signing area stores a code signing public key, a first signing result obtained by calculating the code signing public key by using a root private key, and the second mirror image signing area stores a signing result of the recovery data area by using the code signing private key.

The recovery data area includes a compression data area and a compression header area, where the compression header area stores compression information, for example, key information such as a type of a compression algorithm used, a mirror size before and after compression, and a mirror type. The compressed data area stores a compressed original image, for example, the recovery data area of the BMC recovery image area stores a compressed BMC image, the recovery data area of the BIOS recovery image area stores a compressed BIOS image, the recovery data area of the CPLD recovery image area stores a compressed CPLD image, and the recovery data area of the FPGA recovery image area stores a compressed FPGA image.

FIG. 11 is a flow chart of generating a firmware recovery image according to an embodiment of the application, as shown in FIG. 11:

first, an original image file of each firmware of the baseboard controller is generated, for example, an original BMC image, an original BIOS image, an original CPLD image, and an original FPGA image are generated. Further, the original image files of the firmware are compressed, the compressed image files are written into the compressed data areas of the partitions respectively, the compressed information is filled into the compressed header areas of the partitions in sequence, and the compressed data areas and the compressed header areas form a recovery data area. And for each mirror image partition, writing a root public key into a second trusted root area, writing a code signature public key into a second code signature area to obtain a code signature public key area, calculating a digital signature of the code signature public key area by using a root private key to obtain a first signature result, and writing the first signature result into the second code signature area. And calculating the digital signature of the recovery data area by using the code signature private key, writing the result into a second mirror image signature area, and forming a recovery head area by the second trusted root area, the second code signature area and the second mirror image signature area. And forming a firmware recovery mirror image by the recovery data area and the recovery head area, thereby completing the generation of the BMC recovery mirror image, the BIOS recovery mirror image, the CPLD recovery mirror image and the FPGA recovery mirror image, and writing the firmware recovery mirror image into the flash memory to obtain the BMC recovery mirror image area, the BIOS recovery mirror image area, the CPLD recovery mirror image area and the FPGA recovery mirror image area.

When a firmware upgrade is required, the generated firmware recovery image is uploaded to the substrate controller, and in an exemplary embodiment, the method further includes: under the condition that the substrate controller receives the firmware recovery mirror image, analyzing from the firmware recovery mirror image to obtain a recovery header area and a recovery data area, wherein the recovery data area comprises a compressed data area and a compressed header area, the compressed data area stores the compressed original mirror image, the compressed header area stores compression information, and the recovery header area stores a signature result of the recovery data area; the real-time operating system verifies the recovery data area through the recovery head area; and under the condition that the verification of the recovery data area is successful, the original image is decompressed from the recovery data area based on the compression information, and the firmware is upgraded based on the original image.

Fig. 12 is a flowchart of firmware upgrade according to an embodiment of the present application, in the case where firmware upgrade is required, an image is uploaded first, after a substrate controller detects that the image upload is completed, a recovery header area and a recovery data area are obtained by parsing from a firmware recovery image, a real-time operating system verifies a second code signature area by using a root public key, after the verification is successful, the recovery data area is verified by using a code signature public key, after the verification is successful, compression information is obtained from a compression header area in the recovery data area, and an original image file is decompressed from the compression data area according to the compression information.

After the original image file is obtained, judging the type of the firmware upgraded at the time. In one exemplary embodiment, in a case where the firmware to be upgraded is the substrate controller firmware and the firmware recovery image is the substrate controller recovery image, the original image is the original substrate controller image, and performing the firmware upgrade based on the original image includes: closing the access function of the flash memory area where the substrate controller starting mirror image is located, writing the original substrate controller mirror image into the flash memory area where the substrate controller starting mirror image is located through the real-time operating system, and restarting the substrate controller.

As shown in fig. 12, for upgrading the BMC firmware, the use of the flash memory area where the BMC boot image is located is stopped, the original BMC image is written into the flash memory area where the BMC boot image is located, and then the reboot system can validate the newly written BMC image, thereby realizing the upgrading of the BMC firmware.

As shown in fig. 12, for the upgrading of the BIOS firmware, the server host is first started, then the original BIOS image is written into the flash memory area running the BIOS image, and the server host is restarted to enable the newly written BIOS image to be effective, thereby realizing the upgrading of the BIOS firmware.

As shown in fig. 12, for upgrading the CPLD or the FPGA, the function of the corresponding firmware is firstly disabled, then the original images of the CPLD or the FPGA are written into the corresponding internal memory units, and finally the CPLD or the FPGA is restarted, thereby achieving the upgrading of the CPLD or the FPGA.

It should be noted that, in the process of the operation of the substrate controller, there is also a need for firmware recovery, and in order to ensure the security of firmware recovery, in this embodiment, the firmware exception recovery is implemented by using a real-time operating system.

In one exemplary embodiment, the method includes: under the condition that the real-time operating system detects damaged firmware, the real-time operating system reads a firmware recovery mirror image from a flash memory of a substrate controller, wherein the firmware recovery mirror image comprises a recovery head area and a recovery data area, the recovery data area comprises a compressed data area and a compressed head area, the compressed data area stores a compressed original mirror image, the compressed head area stores compressed information, and the recovery head area stores a signature result of the recovery data area; the real-time operating system verifies the recovery data area through the recovery head area; and under the condition that the verification of the recovery data area is successful, the original image is decompressed from the recovery data area based on the compressed information, and firmware recovery is performed based on the original image.

FIG. 13 is a flowchart of firmware recovery according to an embodiment of the present application, where a firmware recovery process is started when a firmware corruption is detected, after a substrate controller detects that an image upload is completed, a real-time operating system reads a firmware recovery image of a corresponding firmware recovery image area, parses the firmware recovery image to obtain a recovery header area and a recovery data area, verifies the recovery data area by using a root public key and a second code signature area, verifies the recovery data area by using a code signature public key after the verification is successful, acquires compression information from a compression header area in the recovery data area after the verification is successful, and decompresses an original image file from the compression data area according to the compression information.

As shown in fig. 13, after the original image file is obtained, the firmware type recovered at this time is determined, and a firmware recovery operation is performed according to the firmware type.

And for the recovery of the BMC firmware, stopping the use of the flash memory region where the BMC boot image is located, writing the original BMC image into the flash memory region where the BMC boot image is located, and then restarting the system to enable the newly written BMC image to take effect, thereby realizing the recovery of the BMC firmware.

For BIOS firmware recovery, firstly the server host computer writes the original BIOS image into the flash memory area running the BIOS image, and then the server host computer is restarted to enable the newly written BIOS image to be effective, thereby realizing the recovery of the BIOS firmware.

For CPLD or FPGA recovery, firstly, the function of the corresponding firmware is disabled, then the original mirror images of the CPLD or FPGA are written into the corresponding internal memory units, and finally, the CPLD or FPGA is restarted, so that the CPLD or FPGA recovery is realized.

From the description of the above embodiments, it will be clear to a person skilled in the art that the method according to the above embodiments may be implemented by means of software plus the necessary general hardware platform, but of course also by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (e.g. ROM/RAM, magnetic disk, optical disk) comprising instructions for causing a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to perform the method according to the embodiments of the present application.

In this embodiment, a safety protection device is further provided, and the safety protection device is used to implement the foregoing embodiments and preferred embodiments, and is not described in detail. As used below, the term "module" may be a combination of software and/or hardware that implements a predetermined function. While the means described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware, is also possible and contemplated.

Fig. 14 is a block diagram of a safety device according to an embodiment of the present application, which is applied to a substrate controller, and the substrate controller has a real-time operating system and a non-real-time operating system running thereon, as shown in fig. 14, and the device includes:

a first starting unit 141, configured to start a real-time operating system in the substrate controller after the substrate controller is powered on;

a secure start verification unit 142, configured to perform secure start verification of the substrate controller by using the real-time operating system if the real-time operating system is started successfully;

a second starting unit 143 for starting the non-real-time operating system in the substrate controller after the secure start-up verification is passed;

an access unit 144 for the non-real time operating system to access the hardware bus of the substrate controller by communicating with the real time operating system.

In one exemplary embodiment, a flash memory of a baseboard controller stores a baseboard controller boot image, and the baseboard controller boot image is used for secure boot verification, wherein the baseboard controller boot image comprises a real-time operating system partition, a non-real-time operating system partition and a firmware trusted partition, and the real-time operating system partition and the non-real-time operating system partition integrally comprise a real-time operating system partition and a non-real-time operating system partition.

In one exemplary embodiment, the live operating system partition includes a live operating system image area, a first root of trust area, and a live operating system signature area; the apparatus further comprises: the real-time operating system starting verification unit is used for acquiring a safe starting public key stored in a chip of the substrate controller before starting the real-time operating system in the substrate controller, and calculating a signature on a mirror image area and a first trusted root area of the real-time operating system through the safe starting public key; judging whether the obtained signature is the same as the real-time operating system signature in the real-time operating system signature area, wherein the real-time operating system signature is obtained by encrypting the real-time operating system mirror image area and the first trusted root area through a secure starting private key; and starting the real-time operating system under the condition that the obtained signature is the same as the signature of the real-time operating system, and determining that the starting of the substrate controller fails under the condition that the obtained signature is different from the signature of the real-time operating system.

In one exemplary embodiment, the firmware trusted partition includes a first code signature area, a first image signature area, a firmware trusted data area, and a firmware trusted signature area, where the first code signature area stores a code signature public key; the secure boot verification unit 142 includes: the first verification module is used for verifying the code signature public key of the first code signature area, and determining that the starting of the substrate controller fails under the condition that the code signature public key fails to verify; the second verification module is used for verifying the signature on the trusted firmware data area and the first mirror image signature area through the code signature public key under the condition that the code signature public key is successfully verified; the third verification module is used for determining that the starting of the substrate controller fails under the condition that the verification signature fails, and verifying the signatures of the whole real-time operating system partition and the whole non-real-time operating system partition through the code signature public key under the condition that the verification signature is successful; the determining module is used for determining that the safe starting verification fails under the condition that the signature verification of the real-time operating system partition and the non-real-time operating system partition is failed, and determining that the safe starting verification is successful under the condition that the signature verification of the real-time operating system partition and the non-real-time operating system partition is successful.

In an exemplary embodiment, the real-time operating system partition includes a first trusted root area, where the first trusted root area stores a root public key, the first code signing area further stores a signature result of signing a code public key by a root private key, and the first verification module is configured to calculate a signature for the code signing public key in the first code signing area by using the root public key, and determine whether the obtained signature is identical to the signature result stored in the first code signing area; under the condition that the obtained signature is the same as the stored signature result, determining that the code signature public key verification is successful; and under the condition that the obtained digital signature is the same as the stored signature result, determining that the code signature public key fails to verify.

In an exemplary embodiment, the firmware trusted signature area stores a firmware trusted signature obtained by encrypting the first image signature area and the firmware trusted data area through a code signature private key, and the second verification module is used for calculating signatures on the firmware trusted data area and the first image signature area through a code signature public key and judging whether the obtained signature is identical to the firmware trusted signature stored in the firmware trusted signature area; under the condition that the obtained signature is different from the firmware trusted signature, determining that verification of the signature fails; and under the condition that the obtained signature is the same as the firmware trusted signature, determining that the verification signature is successful.

In an exemplary embodiment, the third verification module is configured to calculate signatures of the real-time operating system partition and the non-real-time operating system partition by using a code signature public key, and determine whether the obtained signature is the same as a mirror signature stored in the first mirror signature area, where the mirror signature is obtained by encrypting the real-time operating system partition and the non-real-time operating system partition by using a code signature private key; under the condition that the obtained signature is different from the mirror image signature, determining that the signature verification of the whole of the real-time operating system partition and the non-real-time operating system partition fails; and under the condition that the obtained signature is the same as the mirror image signature, determining that the signature verification of the whole of the real-time operating system partition and the non-real-time operating system partition is successful.

In an exemplary embodiment, the non-real-time operating system partition includes a boot program, a kernel, and an application program, and the second starting unit 143 is configured to control the real-time operating system to start the boot program, the boot program starts the kernel, and the kernel starts the non-real-time operating system; before the non-real-time operating system accesses the hardware bus of the substrate controller in a communication mode with the real-time operating system, controlling the non-real-time operating system to start an application program; and under the condition that the application program is started, controlling the non-real-time operating system to execute read-write access operation on the hardware bus in a mode of communicating with the real-time operating system.

In one exemplary embodiment, the trusted partition of firmware contains a whitelist of bus commands, and access unit 144 includes: the writing module is used for controlling the non-real-time operating system to write the hardware bus information and the read-write content into the shared memory and triggering an interrupt notification real-time operating system; the verification module is used for controlling the real-time operating system to acquire hardware bus information and read-write contents from the shared memory, and verifying the hardware bus information through the bus command white list; the access module is used for accessing the hardware bus by the real-time operating system according to the hardware bus information and the read-write content under the condition that the hardware bus information passes the verification, writing the access result into the shared memory, and triggering the interrupt notification non-real-time operating system; and the acquisition module is used for controlling the non-real-time operating system to acquire the access result from the shared memory.

In an exemplary embodiment, the apparatus further comprises: the first analysis unit is used for analyzing a recovery head area and a recovery data area from the firmware recovery mirror image under the condition that the substrate controller receives the firmware recovery mirror image, wherein the recovery data area comprises a compressed data area and a compressed head area, the compressed data area stores a compressed original mirror image, the compressed head area stores compression information, and the recovery head area stores a signature result of the recovery data area; the first verification unit is used for controlling the real-time operating system to verify the recovery data area through the recovery head area; and the upgrading unit is used for decompressing the original image from the recovery data area based on the compression information and upgrading the firmware based on the original image under the condition that the verification of the recovery data area is successful.

In an exemplary embodiment, the recovery header area includes a second trusted root area, a second code signature area, and a second mirror image signature area, the second trusted root area storing a root public key, the first verification unit is configured to calculate a signature for a code signature public key in the second code signature area using the root public key, and determine whether the obtained signature is identical to a first signature result in the second code signature area, where the first signature result is obtained by signing the code signature public key by a root private key; under the condition that the obtained signature is the same as the first signature result, calculating the signature on the recovery data area by using a code signature public key, and judging whether the obtained signature is the same as a second signature result in a second mirror image signature area, wherein the second signature result is obtained by signing the recovery data area by using a code signature private key; and under the condition that the obtained signature is the same as the second signature result, determining that the verification of the recovery data area is successful, and under the condition that the obtained signature is different from the second signature result, determining that the verification of the recovery data area is failed.

In an exemplary embodiment, in a case where the firmware to be upgraded is the firmware of the substrate controller and the firmware recovery image is the firmware recovery image of the substrate controller, the original image is the original substrate controller image, and the upgrade unit is configured to close an access function of a flash memory area where the substrate controller boot image is located, write the original substrate controller image into the flash memory area where the substrate controller boot image is located through the real-time operating system, and restart the substrate controller.

In an exemplary embodiment, in a case where the firmware to be upgraded is a bios firmware and the firmware recovery image is a bios recovery image, the original image is an original bios image, and the upgrade unit is configured to close the server host, write the original bios image into the flash memory area running the bios image through the real-time operating system, and restart the server host.

In an exemplary embodiment, when the firmware to be upgraded is the firmware of the complex programmable logic device and the firmware recovery image is the recovery image of the complex programmable logic device, the original image is the original complex programmable logic device image, and the upgrade unit is configured to stop the use function of the firmware of the complex programmable logic device, write the original complex programmable logic device image into the flash memory area running the complex programmable logic device image through the real-time operating system, and restart the complex programmable logic device.

In an exemplary embodiment, in a case where the firmware to be upgraded is a field programmable gate array firmware and the firmware recovery image is a field programmable gate array recovery image, the original image is an original field programmable gate array image, and the upgrade unit is configured to stop a function of using the field programmable gate array firmware, write the original field programmable gate array image into a flash memory area running the field programmable gate array image through the real-time operating system, and restart the field programmable gate array.

In an exemplary embodiment, the apparatus further comprises: the device comprises a reading unit, a real-time operating system and a base plate controller, wherein the reading unit is used for reading a firmware restoration mirror image from a flash memory of the base plate controller under the condition that the real-time operating system detects damaged firmware, the firmware restoration mirror image comprises a restoration head area and a restoration data area, the restoration data area comprises a compression data area and a compression head area, the compression data area stores a compressed original mirror image, the compression head area stores compression information, and the restoration head area stores a signature result of the restoration data area; the second verification unit is used for controlling the real-time operating system to verify the recovery data area through the recovery head area; and the recovery unit is used for decompressing the original image from the recovery data area based on the compressed information and carrying out firmware recovery based on the original image under the condition that the verification of the recovery data area is successful.

In an exemplary embodiment, the recovery header area includes a second trusted root area, a second code signature area, and a second mirror image signature area, the second trusted root area storing a root public key, the second verification unit is configured to calculate a signature for a code signature public key in the second code signature area using the root public key, and determine whether the obtained signature is identical to a first signature result in the second code signature area, where the first signature result is obtained by signing the code signature public key by a root private key; under the condition that the obtained signature is the same as the first signature result, calculating the signature on the recovery data area by using a code signature public key, and judging whether the obtained signature is the same as a second signature result in a second mirror image signature area, wherein the second signature result is obtained by signing the recovery data area by using a code signature private key; and under the condition that the obtained signature is the same as the second signature result, determining that the verification of the recovery data area is successful, and under the condition that the obtained signature is different from the second signature result, determining that the verification of the recovery data area is failed.

It should be noted that each of the above modules may be implemented by software or hardware, and for the latter, it may be implemented by, but not limited to: the modules are all located in the same processor; alternatively, the above modules may be located in different processors in any combination.

Embodiments of the present application also provide a computer readable storage medium having a computer program stored therein, wherein the computer program is arranged to perform the steps of any of the method embodiments described above when run.

In one exemplary embodiment, the computer readable storage medium may include, but is not limited to: a usb disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a removable hard disk, a magnetic disk, or an optical disk, or other various media capable of storing a computer program.

An embodiment of the application also provides an electronic device comprising a memory having stored therein a computer program and a processor arranged to run the computer program to perform the steps of any of the method embodiments described above.

In an exemplary embodiment, the electronic device may further include a transmission device connected to the processor, and an input/output device connected to the processor.

Specific examples in this embodiment may refer to the examples described in the foregoing embodiments and the exemplary implementation, and this embodiment is not described herein.

It will be appreciated by those skilled in the art that the modules or steps of the application described above may be implemented in a general purpose computing device, they may be concentrated on a single computing device, or distributed across a network of computing devices, they may be implemented in program code executable by computing devices, so that they may be stored in a storage device for execution by computing devices, and in some cases, the steps shown or described may be performed in a different order than that shown or described herein, or they may be separately fabricated into individual integrated circuit modules, or multiple modules or steps of them may be fabricated into a single integrated circuit module. Thus, the present application is not limited to any specific combination of hardware and software.

The above description is only of the preferred embodiments of the present application and is not intended to limit the present application, but various modifications and variations can be made to the present application by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the principle of the present application should be included in the protection scope of the present application.

Claims

1. A method of security protection applied to a substrate controller having a real-time operating system and a non-real-time operating system running thereon, the method comprising:

after the substrate controller is powered on, starting the real-time operating system in the substrate controller;

under the condition that the real-time operating system is successfully started, executing the safety starting verification of the substrate controller through the real-time operating system;

starting the non-real-time operating system in the substrate controller after the safety start-up verification is passed;

the non-real-time operating system accesses the hardware bus of the substrate controller by communicating with the real-time operating system.

2. The method of claim 1, wherein a flash memory of the baseboard controller stores a baseboard controller boot image, the baseboard controller boot image is used for the secure boot verification, and the baseboard controller boot image includes a real-time operating system partition, a non-real-time operating system partition, and a firmware trusted partition.

3. The method of claim 2, wherein the live operating system partition comprises a live operating system image area, a first root of trust area, and a live operating system signature area; before booting the real-time operating system in the substrate controller, the method further comprises:

acquiring a secure start public key stored in a chip of the substrate controller, and calculating a signature on the real-time operating system mirror image area and the first trusted root area through the secure start public key;

judging whether the obtained signature is the same as the real-time operating system signature in the real-time operating system signature area, wherein the real-time operating system signature is obtained by encrypting the real-time operating system mirror image area and the first trusted root area through a safe starting private key;

and starting the real-time operating system under the condition that the obtained signature is the same as the signature of the real-time operating system, and determining that the starting of the substrate controller fails under the condition that the obtained signature is different from the signature of the real-time operating system.

4. The method of claim 2, wherein the firmware trusted partition includes a first code signature area, a first image signature area, a firmware trusted data area, and a firmware trusted signature area, wherein the first code signature area stores a code signature public key; performing a secure boot check of the substrate controller by the real-time operating system includes:

Verifying the code signature public key of the first code signature area, and determining that the starting of the substrate controller fails under the condition that the code signature public key fails to verify;

under the condition that the code signature public key verification is successful, verifying signatures on the firmware trusted data area and the first mirror image signature area through the code signature public key;

under the condition that signature verification fails, determining that the starting of the substrate controller fails, and under the condition that signature verification succeeds, verifying the signatures of the real-time operating system partition and the non-real-time operating system partition through the code signature public key;

and under the condition that the signature verification of the whole real-time operating system partition and the whole non-real-time operating system partition fails, determining that the safe starting verification fails, and under the condition that the signature verification of the whole real-time operating system partition and the whole non-real-time operating system partition succeeds, determining that the safe starting verification succeeds.

5. The method of claim 4, wherein the real-time operating system partition includes a first trusted root zone, the first trusted root zone storing a root public key, the first code signing zone further storing a signature result of the code signing public key by a root private key, and wherein verifying the code signing public key of the first code signing zone comprises:

Calculating a signature on the code signature public key in the first code signature area by using the root public key, and judging whether the obtained signature is identical to a signature result stored in the first code signature area;

under the condition that the obtained signature is the same as the stored signature result, determining that the code signature public key verification is successful;

and determining that the code signature public key verification fails under the condition that the obtained digital signature is the same as the stored signature result.

6. The method of claim 4, wherein the firmware trusted signature area stores a firmware trusted signature obtained by encrypting the first image signature area and the firmware trusted data area with a code signing private key, and wherein verifying the signature for the firmware trusted data area and the first image signature area with the code signing public key comprises:

calculating signatures for the firmware trusted data area and the first mirror image signature area through the code signature public key, and judging whether the obtained signature is identical to the firmware trusted signature stored in the firmware trusted signature area;

under the condition that the obtained signature is different from the firmware trusted signature, determining that verification signature fails;

And under the condition that the obtained signature is the same as the firmware trusted signature, determining that verification signature is successful.

7. The method of claim 4, wherein verifying the signature of the real-time operating system partition and the non-real-time operating system partition as a whole with the code signing public key comprises:

calculating the integral signatures of the real-time operating system partition and the non-real-time operating system partition by using the code signature public key, and judging whether the obtained signature is the same as the image signature stored in the first image signature area, wherein the image signature is obtained by encrypting the integral of the real-time operating system partition and the non-real-time operating system partition by using a code signature private key;

under the condition that the obtained signature is different from the mirror image signature, determining that the signature verification of the whole of the real-time operating system partition and the non-real-time operating system partition fails;

and under the condition that the obtained signature is the same as the mirror image signature, determining that the signature verification of the whole real-time operating system partition and the non-real-time operating system partition is successful.

8. The method of claim 2, wherein the non-real time operating system partition comprises a boot program, a kernel, and an application program, and wherein booting the non-real time operating system in the substrate controller comprises: the real-time operating system starts the bootstrap program, the bootstrap program starts the kernel, and the kernel starts the non-real-time operating system;

Before the non-real-time operating system accesses the hardware bus of the substrate controller by communicating with the real-time operating system, the method further comprises: the non-real-time operating system starts the application program; and under the condition that the application program is started, the non-real-time operating system executes read-write access operation on a hardware bus in a communication mode with the real-time operating system.

9. The method of claim 2, wherein the firmware trusted partition includes a whitelist of bus commands, and wherein the non-real-time operating system accessing the hardware bus of the baseboard controller by communicating with the real-time operating system comprises:

the non-real-time operating system writes the hardware bus information and the read-write content into the shared memory, and triggers an interrupt to inform the real-time operating system;

the real-time operating system acquires the hardware bus information and the read-write content from the shared memory, and verifies the hardware bus information through the bus command white list;

when the hardware bus information passes the verification, the real-time operating system accesses the hardware bus according to the hardware bus information and the read-write content, writes an access result into the shared memory, and triggers an interrupt to inform the non-real-time operating system;

And the non-real-time operating system acquires the access result from the shared memory.

10. The method according to claim 1, wherein the method further comprises:

under the condition that the substrate controller receives a firmware recovery mirror image, analyzing from the firmware recovery mirror image to obtain a recovery head area and a recovery data area, wherein the recovery data area comprises a compressed data area and a compressed head area, the compressed data area stores a compressed original mirror image, the compressed head area stores compressed information, and the recovery head area stores a signature result of the recovery data area;

the real-time operating system verifies the recovery data area through the recovery head area;

and under the condition that the verification of the recovery data area is successful, the original image is decompressed from the recovery data area based on the compression information, and firmware upgrading is performed based on the original image.

11. The method of claim 10, wherein, in the case where the firmware to be upgraded is a baseboard controller firmware and the firmware restoration image is a baseboard controller restoration image, the original image is an original baseboard controller image, and performing firmware upgrade based on the original image comprises:

And closing the access function of the flash memory area where the substrate controller starting mirror image is located, writing the original substrate controller mirror image into the flash memory area where the substrate controller starting mirror image is located through the real-time operating system, and restarting the substrate controller.

12. The method of claim 10, wherein in the case where the firmware to be upgraded is a bios firmware and the firmware recovery image is a bios recovery image, the original image is an original bios image, and performing the firmware upgrade based on the original image includes:

and closing the server host, writing the original basic input output system image into a flash memory area running the basic input output system image through the real-time operating system, and restarting the server host.

13. The method of claim 10, wherein in the case where the firmware to be upgraded is complex programmable logic device firmware and the firmware recovery image is complex programmable logic device recovery image, the original image is an original complex programmable logic device image, and performing firmware upgrade based on the original image comprises:

Stopping the use function of the firmware of the complex programmable logic device, writing the original complex programmable logic device image into a flash memory area running the complex programmable logic device image through the real-time operating system, and restarting the complex programmable logic device.

14. The method of claim 10, wherein in the case where the firmware to be upgraded is field programmable gate array firmware and the firmware recovery image is a field programmable gate array recovery image, the original image is an original field programmable gate array image, and performing the firmware upgrade based on the original image comprises:

stopping the use function of the field programmable gate array firmware, writing the original field programmable gate array image into a flash memory area running the field programmable gate array image through the real-time operating system, and restarting the field programmable gate array.

15. The method according to claim 1, characterized in that it comprises:

under the condition that the real-time operating system detects damaged firmware, the real-time operating system reads a firmware recovery image from a flash memory of the substrate controller, wherein the firmware recovery image comprises a recovery head area and a recovery data area, the recovery data area comprises a compressed data area and a compressed head area, the compressed data area stores compressed original images, the compressed head area stores compressed information, and the recovery head area stores a signature result of the recovery data area;

and under the condition that the verification of the recovery data area is successful, the original image is decompressed from the recovery data area based on the compression information, and firmware recovery is carried out based on the original image.

16. The method of claim 10 or 15, wherein the recovery header region includes a second root of trust region, a second code signature region, and a second image signature region, the second root of trust region storing a root public key, the validating the recovery header region by the live operating system comprising:

calculating a signature on a code signature public key in the second code signature area by using the root public key, and judging whether the obtained signature is identical to a first signature result in the second code signature area, wherein the first signature result is obtained by signing the code signature public key through a root private key;

calculating a signature on the recovery data area by using the code signature public key under the condition that the obtained signature is the same as the first signature result, and judging whether the obtained signature is the same as a second signature result in the second mirror image signature area, wherein the second signature result is obtained by signing the recovery data area by using a code signature private key;

And determining that the recovery data area verification is successful when the obtained signature is the same as the second signature result, and determining that the recovery data area verification is failed when the obtained signature is different from the second signature result.

17. A safety shield apparatus for use with a substrate controller having a real-time operating system and a non-real-time operating system running thereon, the apparatus comprising:

the first starting unit is used for starting the real-time operating system in the substrate controller after the substrate controller is electrified;

the safe starting verification unit is used for executing the safe starting verification of the substrate controller through the real-time operating system under the condition that the real-time operating system is successfully started;

the second starting unit is used for starting the non-real-time operating system in the substrate controller after the safety starting verification is passed;

and the access unit is used for the non-real-time operating system to access the hardware bus of the substrate controller in a mode of communicating with the real-time operating system.

18. A computer readable storage medium, characterized in that a computer program is stored in the computer readable storage medium, wherein the computer program, when executed by a processor, implements the safety protection method as claimed in any one of claims 1 to 16.

19. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the security protection method as claimed in any one of claims 1 to 16 when executing the computer program.

20. A substrate controller chip, comprising: a storage unit for storing a program, and a processing unit connected to the storage unit, the processing unit being configured to execute the program to perform the security protection method according to any one of claims 1 to 16.