Security management and control method, baseboard management controller, computer program product, and storage medium

Abstract

Embodiments of the present disclosure provide a security management and control method, a baseboard management controller, a computer program product, and a storage medium. A hardware-isolated security subsystem and functional subsystem are configured in the baseboard management controller, which can effectively ensure the defense capability of the security subsystem against hardware attacks. On this basis, security management and control firmware is configured in the security subsystem, and the security subsystem can control secure boot of a computing device by executing the security management and control firmware. In addition, via a bus interface of the baseboard management controller itself, access requests initiated by respective systems-on-chip within the computing device for a target storage component can be received, and the security subsystem can perform access control on such access requests by executing the security management and control firmware.

Description

Security management method, baseboard management controller, computer program product and storage medium Cross-reference to Related Applications

[0001] The present disclosure claims priority to Chinese Patent Application No. 202411358634.4, filed on September 26, 2024, the entire contents of which are incorporated herein by reference. TECHNICAL FIELD

[0002] The present disclosure relates to the technical field of security, and particularly relates to a security management method, a baseboard management controller, a computer program product and a storage medium. BACKGROUND

[0003] With the increasing demand for confidential computing in cloud computing and edge computing, the exposed attack surface also increases, and therefore, a more powerful security solution is needed to enhance the security of computing devices.

[0004] As a key to enhance the security of computing devices, the Root of Trust (ROT) becomes particularly important. At present, a hardware ROT board card, which can be referred to as a Platform Root of Trust (PROT) board card, is usually embedded in a computing device. Through the PROT board card, it can be ensured that the startup and operation of each System-on-Chip (SOC) in the computing device meet the security standards, thereby protecting the security of the computing device.

[0005] However, the hardware cost of such a PROT board card is high and the compatibility with the diverse SOCs in the computing device is insufficient, resulting in an excessively high cost of protecting the security of the computing device. SUMMARY

[0006] Aspects of the present disclosure provide a security management method, a baseboard management controller, a computer program product and a storage medium to protect the security of a computing device.

[0007] The embodiment of the present disclosure provides a security management method, which is suitable for a baseboard management controller (BMC) installed in a computing device, the BMC is provided with a security subsystem and a function subsystem, the security subsystem and the function subsystem are hardware-isolated, and the method comprises the following steps: executing a preset security management firmware by the security subsystem to control the security start of the computing device; receiving an access request for a target storage component from one or more system on chips (SoCs) in the computing device through a bus interface of the BMC after the security start of the computing device, the target storage component being a storage component that needs to be protected; and transmitting the access request to the target storage component through the function subsystem to protect the data stored in the target storage component if the security subsystem determines that the access request meets the security requirements according to the security management firmware.

[0008] Further, the function subsystem is provided with a communication controller for communicating with the target storage component, and the security subsystem is provided with a filter for controlling a communication link connected by the communication controller, and the step of transmitting the access request to the target storage component through the function subsystem if the security subsystem determines that the access request meets the preset security requirements comprises the following steps: setting the filter to a conducting state to turn on the communication link between the communication controller corresponding to the access request and the target storage component if the security subsystem determines that the access request meets the security requirements according to the security management firmware; and transmitting the access request to the target storage component to be accessed through the communication controller by using the communication link.

[0009] Further, the method can further comprise the following steps: setting the filter to a blocking state to disconnect the communication link between the communication controller corresponding to the access request and the target storage component to intercept the access request if the security subsystem determines that the access request does not meet the security requirements.

[0010] Further, the method can further comprise the following steps: transmitting the accesser identity information corresponding to the access request to the security subsystem through the function subsystem after the access request is received; and determining that the access request meets the security requirements if the accesser identity information is located in a permitted list set for the target storage component in the security management firmware by the security subsystem.

[0011] Further, the security subsystem comprises a first physical core, the function subsystem comprises a second physical core, and a data exchange area is arranged between the security subsystem and the function subsystem. After the baseboard management controller is powered on, the method further comprises: copying, by the first physical core after a secure boot, a preset secure boot firmware into the data exchange area; executing, by the first physical core after determining that the secure boot firmware passes a security verification, the secure boot firmware to send a start signal to the second physical core; executing, by the second physical core after receiving the start signal, a boot loader corresponding to the function subsystem if it is determined that the boot loader passes the security verification by executing the secure boot firmware, the boot loader being used to guide the second physical core to perform a subsequent start operation; and performing, by the second physical core, a security verification on the subsequent start operation based on the secure boot firmware to complete a secure start of the second physical core.

[0012] Further, the method can further comprise: when it is monitored by the security subsystem that the function subsystem is restarted, controlling the second physical core to restart securely without restarting the security subsystem.

[0013] Further, after the baseboard management controller is powered on, the method further comprises: during a start process of the security subsystem, if it is monitored that there is another powered-on bus device in the computing device in addition to the baseboard management controller, performing, by the security subsystem, a security verification on an identity and a firmware of the powered-on bus device; and if it is detected by the security subsystem that any powered-on bus device does not pass the security verification, stopping, by the security subsystem, the start.

[0014] Further, the security subsystem is controlled to start securely based on a security control firmware arranged in the security subsystem, comprising: after the security subsystem is started securely, executing, by the security subsystem, the security control firmware to measure a firmware required to be used by each system on chip in the computing device to obtain a measurement result corresponding to each system on chip; controlling, by the security subsystem, each system on chip in the computing device to be powered on according to the measurement result; and after each system on chip is powered on, taking the security subsystem as a root of trust to establish a start trust chain for the computing device to control the computing device to start securely.

[0015] Further, the method can further comprise: if it is monitored by the security subsystem that any firmware used by any system on chip in the computing device needs to be restored, reading, from a special storage component arranged for the security subsystem, a recovery firmware corresponding to the firmware; and replacing, by the security subsystem, the firmware with the recovery firmware.

[0016] Further, the method can further comprise: in the case that any firmware fails to pass the security verification, the start-up delay exceeds a preset threshold, and / or the on-chip system initiates a recovery instruction, determining that the firmware needs to be recovered.

[0017] Further, based on a virtualization technology, a plurality of virtual machines in any on-chip system in the computing device share the security subsystem, and the method further comprises: receiving a call request for the security subsystem initiated by any virtual machine in the on-chip system; and executing the security control firmware by using the security subsystem to respond to the call request.

[0018] Further, a data exchange area is arranged between the security subsystem and the function subsystem, and the method further comprises: writing control record information generated in the security control process into the data exchange area by the security subsystem; reading the control record information from the data exchange area by the function subsystem and forwarding the control record information to a security monitoring system outside the baseboard management controller; and wherein the control record information comprises alarm information and / or abnormal information.

[0019] Further, the target storage component comprises a flash memory for storing basic input / output system firmware and / or a flash memory for storing various firmware required by the baseboard management controller; and the access request complies with an enhanced serial peripheral interface protocol.

[0020] The embodiments of the present disclosure further provide a baseboard management controller comprising a security subsystem and a function subsystem, the security subsystem and the function subsystem are hardware-isolated, and the security subsystem and the function subsystem perform the security control method described above.

[0021] The embodiments of the present disclosure further provide a computer-readable storage medium storing a computer program, when the computer program is executed by one or more processors, the one or more processors are caused to perform the security control method described above.

[0022] The embodiments of the present disclosure further provide a computer program product comprising a computer program, when the computer program is executed by one or more processors, the one or more processors are caused to perform the security control method described above.

[0023] In the embodiments of the present disclosure, a new baseboard management controller is provided, in which a security subsystem and a function subsystem are arranged, and the security subsystem and the function subsystem are hardware isolated, which can guarantee the hardware independence of the security subsystem, so as to effectively guarantee the defense capability of the security subsystem against hardware attacks. On this basis, a security management firmware is arranged in the security subsystem, and the security subsystem can control the secure boot of the computing device by executing the security management firmware. Moreover, the baseboard management controller can receive an access request initiated by each system on chip in the computing device for a target storage component such as a flash memory through a bus interface of the baseboard management controller itself, and the security subsystem can perform access control on the access request by executing the security management firmware, and the function subsystem can transparently transmit the access request that meets the security requirements to the target storage component to be accessed. Accordingly, the baseboard management controller can be used as a platform root of trust in the computing device to control the secure boot of the computing device and protect the data stored in the target storage component in the computing device, so as to guarantee the security of the computing device. In addition, since the PROT board card is no longer needed to be installed in the computing device, the number of hardware in the computing device can be effectively reduced, and the hardware cost can be saved. Moreover, since the bus interface in the baseboard management controller can be reused, the development cost caused by interface compatibility problems can be saved. BRIEF DESCRIPTION OF DRAWINGS

[0024] The accompanying drawings, which are included to provide a further understanding of the present disclosure and constitute a part of the present disclosure, illustrate certain illustrative embodiments of the present disclosure and are used to explain the present disclosure, but do not limit the present disclosure. In the drawings:

[0025] FIG. 1 is a schematic diagram of an internal structure of a computing device according to an illustrative embodiment of the present disclosure;

[0026] FIG. 2 is a schematic diagram of an internal structure of a baseboard management controller according to an illustrative embodiment of the present disclosure;

[0027] FIG. 3 is a schematic diagram of an optional structure of a security subsystem according to an illustrative embodiment of the present disclosure;

[0028] FIG. 4 is a schematic diagram of a logic of a secure boot process in a BMC according to an illustrative embodiment of the present disclosure;

[0029] FIG. 5 is a schematic diagram of a shared logic of a security subsystem according to an illustrative embodiment of the present disclosure;

[0030] FIG. 6 is a schematic diagram of a flow of a security management method according to another illustrative embodiment of the present disclosure. DETAILED DESCRIPTION

[0031] In order to make the purposes, technical solutions and advantages of the present disclosure clearer, the technical solutions of the present disclosure will be described below in connection with specific embodiments of the present disclosure and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present disclosure.

[0032] Before starting to describe the technical solutions provided by the embodiments of the present disclosure in detail, several technical concepts related to the present disclosure are simply explained as follows.

[0033] The baseboard management controller (BMC) is an embedded hardware component used for remotely monitoring and managing the hardware status of a server, allowing administrators to perform remote power-on, power-off, reboot, and monitoring of temperature, voltage, and fan speed, etc.

[0034] The platform root of trust (PROT) is a set of trust sources embedded in a computing device, in the form of a board card, also known as a PROT board card, used to ensure that the platform startup and operation process complies with relevant security specification standards, including hardware, firmware and software components, which provide key security services.

[0035] The system on a chip (SOC) refers to a complete system integrated on a single chip. A typical SOC can include but is not limited to a processor (CPU), a graphics processing unit (GPU), and a neural processing unit (NPU), etc., without further examples.

[0036] As introduced in the background, it is currently necessary to install a PROT board card in a computing device to ensure the security of the computing device. However, the cost of the PROT board card is relatively high, especially in cloud computing and edge computing scenarios, where the number of servers is large. Installing a PROT board card on the server to ensure security will require a considerable cost. Moreover, most current servers use advanced RISC machines (ARM) architecture, so the number and types of SOCs contained in the server are relatively large, which leads to the need for interface development on the PROT card for different types of SOCs to provide communication interfaces on the PROT card that are adapted to different types of SOCs. This results in a considerable amount of development work. It can be seen that the current way of ensuring the security of a computing device by installing a PROT board card in the computing device is too costly.

[0037] To this end, the embodiment proposes a new technical concept, which proposes that the BMC is taken as the platform root of trust of the computing device to guarantee the security of the computing device. Based on the technical concept proposed in the embodiment, the PROT board card is no longer needed to be installed in the computing device, and the security of the computing device can be guaranteed based on the BMC.

[0038] To implement the technical concept, in the embodiment, the BMC is reformed in terms of hardware and software.

[0039] The technical solutions provided by the embodiments of the disclosure are described in detail below with reference to the drawings.

[0040] FIG. 1 is a schematic diagram of the internal structure of a computing device according to an example embodiment of the disclosure. Referring to FIG. 1, the computing device is equipped with the BMC provided by the embodiment, and is also equipped with a CPU and other SOCs. The BMC and the SOCs are connected to the bus of the computing device.

[0041] FIG. 2 is a schematic diagram of the internal structure of a baseboard management controller according to an example embodiment of the disclosure.

[0042] Referring to FIGS. 1 and 2, in the embodiment, the BMC is reformed in terms of hardware.

[0043] In the embodiment, a security subsystem and a function subsystem can be provided in the BMC. In the embodiment, the security subsystem is used to be responsible for the work related to security management, and the function subsystem is responsible for the native work of the BMC and provides assistance for the security subsystem. As mentioned in the foregoing conceptual explanation section, the native work of the BMC can include, but is not limited to, booting, shutting down, restarting, and monitoring temperature, voltage, and fan speed, and will not be expanded and described here.

[0044] In the embodiment, it is proposed that the security subsystem and the function subsystem are hardware-isolated. The hardware isolation means that the security subsystem and the function subsystem each have independent hardware. The security subsystem and the function subsystem can access the internal bus of the BMC, and the internal bus of the BMC is connected to the system bus in the computing device, thereby realizing the communication link of the computing device to the security subsystem and the function subsystem.

[0045] Referring to FIG. 2, the security subsystem and the function subsystem each have independent physical cores, read-only memories (ROMs), and random access memories (RAMs). This can guarantee the hardware independence of the security subsystem, thereby effectively guaranteeing the defense capability of the security subsystem against hardware attacks. Preferably, in the embodiment, the physical cores in the security subsystem and the function subsystem can each use a RISC-V physical core, of course, this is only preferred, and the embodiment is not limited thereto.

[0046] In addition, referring to FIG. 2, in the embodiment, a one-time program (OTP) unit can also be arranged in the security subsystem. The OTP refers to a storage device or a memory unit that can be programmed only once. Once programmed, the data is permanently written and cannot be overwritten or erased. In the embodiment, the related keys required for starting the security subsystem and the like can be stored in the OTP, and static encryption is performed in a manner known only to the ROM in the security subsystem. After the OTP is started, the OTP can be used to derive a device identification (ID), and only read operations performed by the ROM in the security subsystem are allowed. The OTP can serve as a root of trust of the security subsystem to support the trustworthiness of the security subsystem itself. In this way, in the embodiment, on the one hand, the security subsystem has independent hardware, and on the other hand, the security subsystem also contains the OTP as a root of trust. These two aspects can effectively guarantee the trustworthiness of the security subsystem.

[0047] In addition, referring to FIG. 2, a data exchange area can also be arranged between the security subsystem and the function subsystem. Optionally, a storage area can be divided from the RAM contained in the function subsystem to serve as the data exchange area. The data exchange area can be used for data exchange between the security subsystem and the function subsystem.

[0048] FIG. 3 is a schematic diagram of an optional structure of a security subsystem according to an example embodiment of the present disclosure. FIG. 3 shows more hardware components that can be arranged in the security subsystem.

[0049] Referring to FIG. 3, in the embodiment, an instruction closely coupled memory (ICCM) and a data closely coupled memory (DCCM) and the like can also be arranged in the security subsystem. The ICCM is located near the processor core, can store a set of instructions and support high-speed access, is used to improve the performance of the physical core, and reduce the delay of accessing the memory. In the embodiment, the related instructions generated in the security subsystem can be cached in the ICCM. The DCCM is used to store frequently accessed data, is close to the physical core, and is used to realize high-speed data access and improve overall processing performance. In the embodiment, the data frequently accessed by the physical core in the security subsystem, such as the metric value, can be stored in the DCCM.

[0050] It should be understood that the hardware components arranged in the BMC in the embodiment are not limited to those shown in FIGS. 2 and 3. In actual applications, other hardware components can be arranged as needed, and more examples are not given here.

[0051] Referring to FIG. 1 and FIG. 2, in the embodiment, the BMC is also reformed in the software aspect.

[0052] In the technical concept proposed in the embodiment, it is proposed to integrate a trusted platform module (TPM) in the BMC to support the BMC to support the work related to security management. For this purpose, referring to FIG. 1, in the embodiment, it is proposed to set a security management firmware in the security subsystem. The security management firmware can contain the functional logic required by the trusted platform module, and the physical core in the security subsystem executes the security management firmware to realize the functional logic corresponding to the trusted platform module. In this way, the physical core in the security subsystem can serve as the built-in trusted platform module in the BMC, and perform the related functional logic in the process of security management of the computing device.

[0053] The inventors found in the research process that in the process of security management of the computing device, more encryption and decryption operations are required. In order to ensure the trustworthiness of the encryption and decryption operations, referring to FIG. 2, in the embodiment, it is also proposed to set an encryption and decryption engine in the security subsystem. The encryption and decryption engine in the embodiment meets the national security requirements. Alternatively, the encryption and decryption engine can be designed based on an open source Titan (OpenTitan) security chip design platform, of course, the embodiment is not limited thereto, and other ways can also be used to realize the encryption and decryption engine in the security subsystem, which will not be illustrated more herein. In addition, in order to be compatible with different types of encryption and decryption engines, a bus bridge or the like can be used in the security subsystem to perform protocol conversion to connect the encryption and decryption engine to the internal bus of the BMC, which will not be illustrated more herein.

[0054] Accordingly, in the embodiment, the trusted platform module and the encryption and decryption engine can be integrated in the security subsystem, which provides functional component support for using the BMC in the embodiment as a platform root of trust, so that the security subsystem has the functional components required by the platform root of trust. In this way, the physical core and the encryption and decryption engine in the security subsystem in the embodiment can perform their respective functions in the process of security management of the computing device, and realize the various security management functions originally provided by the PROT board card.

[0055] Based on the above-mentioned hardware and software method of reforming the BMC, the BMC in the embodiment can serve as a platform root of trust of other SOC in the computing device. The process of security management of the computing device by the BMC as a platform root of trust in the embodiment will be described below.

[0056] As mentioned above, in the computing device, the BMC and other SOC provided by the embodiment are connected on the bus of the computing device, therefore, in the embodiment, the original bus interface on the BMC can be used to ensure the interface compatibility between the BMC and other SOC in the security management process, which obviously avoids the problem of insufficient interface compatibility of the existing PROT board card mentioned in the background art.

[0057] It can be understood that in the embodiment, the BMC still exposes the original bus interface to other SOC in the computing device, and the other SOC in the computing device does not perceive the change of the internal hardware structure and the change of the internal software logic of the BMC in the embodiment.

[0058] In the computing device, the BMC is the first hardware component to be powered on, therefore, the BMC can be powered on and started before the CPU and other SOC, which provides time guarantee for the BMC to be used as PROT to manage and control the security of the computing device. In the embodiment, after the BMC is powered on, the security subsystem and the function subsystem arranged in the BMC are sequentially started in a secure manner. After the security subsystem and the function subsystem are started in a secure manner, the security management and control of the computing device can be performed.

[0059] In the embodiment, the security management and control of the BMC on the computing device can include the security start aspect and the access protection aspect of the target storage component. The target storage component is a storage component that needs to be protected in the computing device. The two security management and control aspects are described below.

[0060] Security start aspect.

[0061] In the embodiment, the security subsystem can execute the security management and control firmware as described above, and according to the measurement logic arranged in the security management and control firmware, the security subsystem can perform security measurement on each firmware used by each SOC in the computing device when starting, and after ensuring that the firmware passes the measurement, the SOC can be allowed to start, so that the computing device can be controlled to start in a secure manner. In this way, the security management and control firmware in the embodiment has the control function of active measurement in addition to the related function of the trusted platform module, therefore, based on the security management and control firmware, the physical core in the security subsystem can be used as the trusted platform control module (TPCM) built in the BMC.

[0062] In actual application, after determining that the related firmware passes the measurement, the BMC can use its own bus interface to perform read and write operations on the control component such as the complex programmable logic device (CPLD) in the computing device, to realize the power control of each SOC, so as to control the start of each SOC according to the measurement result.

[0063] In an optional implementation, after the security subsystem is started, the security subsystem can measure the firmware required by each SOC in the computing device by executing the security management firmware, to obtain a measurement result corresponding to each SOC; the security subsystem can control each SOC in the computing device to be powered on according to the measurement result; after each SOC is powered on, the security subsystem can establish a startup trust chain for the computing device as a root of trust, to control the computing device to be started safely.

[0064] In this optional implementation, the security subsystem controls each SOC to be powered on only after the security subsystem determines that the firmware required by the SOC passes the measurement, and the security subsystem can itself serve as a root of trust to ensure the trustworthiness of each startup link involved in the startup process of the SOC. The startup process of the SOC usually involves multiple startup links. The security subsystem in this embodiment can measure the trustworthiness of each adjacent startup link, and allow the startup link to continue only after the measurement passes. Similarly, the startup link can measure the trustworthiness of the next startup link, and allow the next startup link to continue only after the measurement passes. In this way, a startup trust chain can be established for the computing device. That is, each startup link in the startup trust chain of the computing device passes the measurement, and only then can the related SOC be started safely. Therefore, the security subsystem in this embodiment can control the computing device to be started safely.

[0065] It should be understood that the implementation provided above for the startup process is optional, and the embodiment is not limited thereto. In this embodiment, the security management firmware described above can be designed to use other implementation schemes to ensure that the computing device is started safely during the startup process of the computing device. For example, more measurement dimensions can be added, and the order between the startup links in the startup trust chain and the trust measurement manner can be designed flexibly, and so on. Here, more examples of implementation schemes are provided.

[0066] It should be noted that the security subsystem and the function subsystem in this embodiment are assumed to have been started safely when the security startup is described. The security startup scheme of the security subsystem and the function subsystem will be described in detail later, and will not be described here.

[0067] In this embodiment, the security management firmware executed by the security subsystem can be used to control the computing device to be started safely.

[0068] Access protection of the target storage component.

[0069] The target storage components in the embodiments can be storage components in a computing device for storing various firmware. For example, a flash memory for storing Basic Input Output System (BIOS) firmware, also referred to as BIOS flash. For another example, a flash memory for storing various firmware used by a BMC, also referred to as BMC flash. In the embodiments, the target storage components can be protected from access by the security subsystem and the functional subsystem to protect the data stored in the target storage components.

[0070] After the SOC in the computing device is powered on, the SOC can need to access the firmware in the target storage components. For example, after a CPU is powered on, the CPU can need to access the BIOS flash to use the BIOS firmware therein. In the embodiments, the BMC itself can be configured to receive access requests initiated by the SOC in the computing device to the target storage components via a bus interface of the BMC.

[0071] It should be understood that in the embodiments, no modification is required to the SOC in the computing device, and the SOC is only required to initiate access requests to the target storage components using specified bus protocols. The specified bus protocols can cause the access requests initiated by the SOC to the target storage components to pass through the BMC. In the embodiments, the bus protocols followed by the access requests can include, but are not limited to, Enhanced Serial Peripheral Interface (eSPI) and the like.

[0072] Taking the access requests following the eSPI protocol as an example, in the embodiments, based on the eSPI protocol, the BMC can present itself as an SPI device, that is, the BMC exposes an SPI slave interface to the outside, and the access requests initiated by the SOC in the computing device when the SOC needs to access the target storage components can be transmitted to the SPI slave interface of the BMC in the embodiments via a bus, so that the BMC in the embodiments can receive the access requests.

[0073] After the access request enters the BMC in the embodiment, the security subsystem in the embodiment can determine whether the access request meets the preset security requirement according to the security management firmware. The security requirement here can be designed as needed, and the security requirement is configured in the security management firmware as the basis for the security subsystem to evaluate the security of the access request. Based on this, the embodiment proposes that if it is determined that the access request meets the security requirement, the functional subsystem in the embodiment can pass the access request to the target storage component as needed. On the contrary, if it is determined that the access request does not meet the security requirement, the functional subsystem in the embodiment no longer delivers the access request to the target storage component. This can achieve access control of the target storage component, thereby ensuring that only the access request meeting the security requirement can reach the target storage component, and further protecting the data stored in the target storage component.

[0074] It can be understood that after the access request enters the BMC in the embodiment, it can be diverted to the functional subsystem based on the design of the internal bus of the BMC in the embodiment. The security subsystem in the embodiment can determine whether the access request meets the security requirement based on the integrated trusted platform module and encryption and decryption engine, and control the processing mode of the access request by the functional subsystem according to the determination result, that is, the security subsystem can control the functional subsystem to pass through the access request when the access request meets the security requirement, and the security subsystem can control the functional subsystem to block the access request when the access request does not meet the security requirement.

[0075] In the embodiment, the security subsystem is used for the security startup and protection of the target storage component, and can generate management and control record information in the case of security verification failure or access exception. The management and control record information can include alarm information and / or exception information, etc., for recording various abnormal events in the security management process. On this basis, the embodiment further proposes that the security subsystem can write the management and control record information generated in the security management process into the aforementioned data exchange area, and the functional subsystem can read the management and control record information from the data exchange area and forward it to the security monitoring system outside the BMC. This can timely deliver various management and control record information generated by the BMC as the platform trust root of the computing device to the external security monitoring system, so that the security monitoring system uses these management and control record information, for example, timely presents to the relevant staff or timely generates an exception solution, etc. Here, the security monitoring system is not limited, and is not expanded.

[0076] In summary, in the embodiment, a new BMC is provided, the security subsystem and the function subsystem are arranged in the BMC, and the security subsystem and the function subsystem are hardware isolated, which can guarantee the hardware independence of the security subsystem, thereby effectively guaranteeing the defense capability of the security subsystem against hardware attacks. On this basis, the security management firmware is arranged in the security subsystem, the security subsystem can control the secure boot of the computing device by executing the security management firmware, and the access request initiated by each system on chip in the computing device to the target storage component such as flash memory can be received through the bus interface of the baseboard management controller, the security subsystem can perform access control on the access request by executing the security management firmware, and the access request meeting the security requirements can be transmitted to the target storage component to be accessed by the function subsystem. Accordingly, the BMC can be used as the platform root of trust in the computing device to control the secure boot of the computing device and protect the data stored in the target storage component in the computing device, thereby guaranteeing the security of the computing device. In addition, since the PROT board card is no longer needed to be installed in the computing device, the number of hardware in the computing device can be effectively reduced, and the hardware cost can be saved, and since the bus interface in the BMC can be reused, the development cost caused by interface compatibility problems can be saved.

[0077] In the above or the following embodiments, the access control of the target storage component can be implemented in various manners in the BMC. The following provides an optional implementation manner.

[0078] Referring to FIG. 2, in the optional implementation manner, it is proposed that the communication controller for communicating with the target storage component can be arranged in the function subsystem, and the filter for controlling the communication link connected by the communication controller can be arranged in the security subsystem. The communication controller and the filter can be used in pairs. The pair use here can be understood as that for each communication controller arranged in the function subsystem, a corresponding filter is arranged in the security subsystem. From the perspective of the filter, one filter only affects the communication controller paired with it, and does not interfere with other communication controllers.

[0079] In addition, in the optional implementation manner, if there are multiple target storage components that need to be protected in the computing device, dedicated communication controllers and filters can be arranged for different target storage components.

[0080] In the optional implementation manner, the target storage component can access the internal bus of the BMC in the embodiment, so that the function subsystem (specifically, the communication controller in the function subsystem) and the target storage component that needs to be protected can also communicate in accordance with the bus protocol, and the bus protocol followed by the communication controller and the target storage component can be consistent with the bus protocol followed by the access request, for example, the eSPI protocol mentioned above.

[0081] For example, in the case of the eSPI protocol, the communication controller provided in the functional subsystem can be exposed as an SPI master interface (also referred to as an SPI Master interface), and the target storage component connected to the communication controller is the SPI slave device of the communication controller.

[0082] In this optional implementation, the filter can act as an on-off switch for controlling the communication link between the communication controller and the target storage component. The state of the filter can include an on state and an off state. When the filter is in the on state, the communication link between the communication controller and the target storage component controlled by the filter is turned on. Conversely, when the filter is in the off state, the communication link between the communication controller and the target storage component controlled by the filter is turned off. The state of the filter is controlled by the physical core in the security subsystem by executing the security control firmware.

[0083] Based on this, in this optional implementation: if the security subsystem determines that the access request meets the security requirements according to the security control firmware, the filter can be set to the on state to turn on the communication link between the communication controller corresponding to the access request and the target storage component; the communication controller can use the communication link to transparently transmit the access request to the target storage component to be accessed. If the security subsystem determines that the access request does not meet the security requirements according to the security control component, the filter can be set to the off state to turn off the communication link between the communication controller corresponding to the access request and the target storage component, so as to intercept the access request.

[0084] In this way, by switching the state of the filter, the access control of the target storage component can be realized.

[0085] In this optional implementation, the physical core in the security subsystem can determine whether the access request meets the security requirements by executing the security control firmware. In an exemplary solution, it is proposed that after receiving such an access request through the bus interface of the BMC, such an access request can be diverted to the functional subsystem based on the design of the internal bus of the BMC mentioned above. The functional subsystem can pass the access requester identity information corresponding to the access request to the security subsystem. The security subsystem can determine whether the access requester identity information is located in the permitted list set by the security control firmware for the target storage component to be accessed by executing the security control firmware. If yes, it is determined that the access request meets the security requirements.

[0086] In the example solution, such an access request can be specifically directed to a communication controller set in the functional subsystem for the target storage component requiring access. The communication controller can pass the access requester identity information corresponding to the access request to the security subsystem. The communication controller can write the access requester identity information to the data exchange area shown in FIG. 2, and the physical core in the security subsystem can read the access requester identity information from the data exchange area. Here, the access requester can be various firmware and application programs in the system on chip, which is not limited herein.

[0087] In this optional implementation, through the cooperation between the communication controller and the filter, and the guidance of the preset security management firmware in the security subsystem, the access management of the target storage component can be realized, and the access request that does not meet the security requirements can be blocked.

[0088] It should be understood that the above implementation is optional, and other implementations can also be used to realize the access management of the target storage component in the embodiment, for example, setting firmware for each filter, and presetting the aforementioned permitted list in the firmware of the filter, and then the filter judges whether the access request meets the security requirements and autonomously switches the conduction state and the blocking state, etc. The embodiment is not limited thereto, and no more examples are provided herein.

[0089] In the above or below embodiments, before the security management of the computing device, the security subsystem and the functional subsystem in the BMC need to be securely started. In the embodiment, various implementations can be used to realize the secure start of the security subsystem and the functional subsystem. Since the security subsystem involves the physical core in the security subsystem and the physical core in the functional subsystem, for the convenience of distinction, the physical core in the security subsystem is described as a first physical core, and the physical core in the functional subsystem is described as a second physical core.

[0090] The following provides an optional implementation of securely starting the functional subsystem: after the first physical core is securely started, the first physical core copies the preset security boot firmware to a data exchange area set between the security subsystem and the functional subsystem; after the first physical core determines that the security boot firmware passes the security verification, the first physical core executes the security boot firmware to send a start signal to the second physical core; after the second physical core receives the start signal, if it is determined that the boot loader corresponding to the functional subsystem passes the security verification by executing the security boot firmware, the second physical core executes the boot loader, and the boot loader is used to guide the second physical core to perform subsequent start operations; and the second physical core performs security verification on the subsequent start operations based on the security boot firmware to complete the security start of the second physical core.

[0091] In the optional implementation, the first physical core copies the preset secure boot firmware into the data exchange area in FIG. 2, and performs security verification on the secure boot firmware. The secure boot firmware contains function logic for sending a start signal to the second physical core, and the first physical core can execute the function logic to send the start signal to the second physical core. The start signal is used to trigger the second physical core to perform subsequent start procedures. This can ensure the credibility of the secure boot firmware, and further ensure that the second physical core is started safely.

[0092] The secure boot firmware also contains function logic for performing security verification on the boot loader corresponding to the function subsystem and the firmware required in other start procedures. After being started, the second physical core can execute the function logic in the secure boot firmware to perform security verification on the boot loader corresponding to the function subsystem. After the boot loader passes the security verification, the second physical core can execute the boot loader. The boot loader can guide the second physical core to continue to perform subsequent start operations, and the secure boot firmware can perform security verification on the firmware required in the subsequent start operations. In this way, a start trust chain corresponding to the start procedure of the function subsystem can be established, thereby ensuring the safe start of the function subsystem.

[0093] It should be understood that the above implementation of securely starting the function subsystem is optional, and the present embodiment is not limited thereto. In the present embodiment, other implementations can also be used to securely start the function subsystem. For example, the secure boot firmware can not be written into the data exchange area, but a special firmware for performing security verification logic can be preset for the function subsystem in the BMC flash. The security subsystem also performs security verification on the special firmware in advance. After passing the verification, the second physical core can be sent a start signal and allowed to use the special firmware, so as to use the special firmware as the starting point of the start trust chain, and ensure the safe start of the second physical core. No more examples are given here.

[0094] In the present embodiment, the security start procedure of the first physical core is not limited. The ROM included in the security subsystem can be pre-embedded with initialization firmware for measurement. Based on the initialization firmware, various firmware required in the start procedure of the first physical core in the security subsystem can be securely verified. After ensuring that the firmware passes the security verification, the first physical core can be safely started.

[0095] Preferably, during the starting process of the first physical core, a security verification step for other powered-on bus devices other than the BMC can also be added. The inventors have found in the research process that the power-on timing of other bus devices in the computing device can not be controlled by the BMC, which leads to the fact that other powered-on bus devices can exist in the computing device after the BMC is powered on, for example, some GPUs can be powered on after the computing device is powered on without being controlled by the BMC. In this regard, the embodiment proposes a preferred solution:

[0096] During the starting process of the security subsystem, if it is monitored that other powered-on bus devices exist in the computing device, the security subsystem performs security verification on the identity and firmware of the powered-on bus devices;

[0097] If the security subsystem detects that any powered-on bus device fails the security verification, the security subsystem stops starting.

[0098] In this preferred solution, a list of bus devices to be monitored can be preset in the security control firmware. If the powered-on bus devices monitored by the security subsystem do not match the list of bus devices, the security subsystem will stop starting. For example, if a powered-on bus device that is not included in the list of bus devices appears in the computing device, the security subsystem will stop starting, which can effectively avoid the security risk caused by installing unsafe hardware devices in the computing device. For another example, if a powered-on bus device in the computing device is included in the list of bus devices, but its corresponding firmware does not meet the security requirements, the security subsystem will also stop starting, which can effectively avoid the security risk of attacking the computing device by tampering with the firmware of the powered-on bus device.

[0099] In this way, in this preferred solution, by introducing a security verification step for other powered-on bus devices during the starting process of the security subsystem, the security risk of attacking the security subsystem in the embodiment by attacking other powered-on bus devices can be effectively avoided, the credibility and security of the security subsystem in the embodiment are ensured, and the credibility and security of the computing device are further ensured.

[0100] FIG. 4 is a logic diagram of a BMC internal security starting process according to an example embodiment of the present disclosure. FIG. 4 provides an example process of the security subsystem and the function subsystem starting in sequence. Referring to FIG. 4, the example process generally includes the following steps.

[0101] 1. After the BMC is powered on, the security subsystem is started first, and the first physical core starts executing the initialization firmware (Secure Boot ROM) included in the ROM of the security subsystem.

[0102] 2. By executing the Boot ROM, the first physical core can read the security management firmware preset in the embodiment from the BMC Flash.

[0103] 3. By executing the Boot ROM, the first physical core can perform security verification on the security management firmware. If the security verification is passed, the security management firmware can be loaded and executed. Otherwise, the booting will be stopped, and error reporting and processing will be performed.

[0104] 4. By executing the security management firmware, the first physical core can copy the security boot firmware (Secure Firmware) corresponding to the function subsystem to the data exchange area in FIG. 2, and perform security verification on the security boot firmware. If the security verification is passed, the security boot firmware can be loaded and executed. Otherwise, the booting will be stopped, and error reporting and processing will be performed.

[0105] 5. By executing the security boot firmware, the first physical core can send a boot signal to the initialization firmware (Application Boot ROM) executed by the first physical core in the function subsystem, and the first physical core completes the security booting. By executing the security boot firmware, the second physical core can perform security verification on the boot loader (Application Uboot) in the function subsystem. After the security verification is passed, the second physical core can start to execute the Application Uboot.

[0106] 6. By executing the Application Uboot, the second physical core can continue the subsequent booting process, and perform security verification on each firmware used in the subsequent booting process by executing the security boot firmware Secure FW. After each firmware passes the security verification, the second physical core can start to execute the runtime firmware (Application Runtime FW), that is, the function logic corresponding to the native work of the BMC, and the second physical core is booted in a secure manner.

[0107] 7. By executing the security boot firmware Secure FW, the second physical core can also provide a trusted proof to the security subsystem in the runtime phase using the stored security verification result.

[0108] It should be understood that the above description of the security process of the security subsystem and the function subsystem is only exemplary, and the embodiment is not limited thereto. In the embodiment, other implementation manners can also be used to realize the security booting of the security subsystem and the function subsystem. For example, more firmware for security verification can be set for the security subsystem and the function subsystem, and other function logic can be designed for the security boot firmware, and the like, which will not be further exemplified herein.

[0109] In addition, in this embodiment, the security subsystem will keep running after being started, and can perform security monitoring on the runtime of the function subsystem. If an abnormal event is detected in the runtime of the function subsystem, the security subsystem can control the function subsystem to restart. Of course, in some other cases, the function subsystem also supports manual restart. Regardless of the reason for the restart of the function subsystem, based on the hardware isolation between the security subsystem and the function subsystem, the security subsystem in this embodiment will not be affected by the restart of the function subsystem, and the security subsystem does not need to restart. In addition, in this embodiment, when the security subsystem detects that the function subsystem restarts, the security subsystem can perform the security startup control operation on the function subsystem again, such as the operation of copying the preset security boot firmware into the data exchange area and the subsequent operation mentioned in the foregoing optional implementation manner, to control the function subsystem to restart safely. The subsequent operation is as described above: after determining that the security boot firmware passes the security verification, executing the security boot firmware to send a startup signal to the second physical core; after receiving the startup signal, if it is determined that the boot loader corresponding to the function subsystem passes the security verification by executing the security boot firmware, executing the boot loader; performing security verification on the subsequent startup operation of the boot loader guided by the security boot firmware to complete the security startup of the second physical core. The subsequent operation is not repeated here.

[0110] Accordingly, in this embodiment, the security subsystem and the function subsystem arranged in the BMC can be sequentially started safely. The security subsystem can establish a startup trust chain by itself by using the foregoing OTP as a root of trust, and can perform security verification on other powered-on bus devices, thereby ensuring the safe startup of the security subsystem itself. After the security subsystem completes the safe startup, it can serve as a root of trust in the startup process of the function subsystem, and establish a startup trust chain for the function subsystem, thereby ensuring the safe startup of the function subsystem.

[0111] In the foregoing or the following embodiments, in addition to the foregoing security startup aspect and access protection aspect of the target storage component, the BMC can also include a firmware recovery aspect in the security management aspect of the computing device. The firmware recovery aspect is described below.

[0112] The firmware recovery aspect.

[0113] In this embodiment, it is proposed that: if the security subsystem detects that any firmware used by any SOC in the computing device needs to be recovered, the security subsystem reads the recovery firmware corresponding to the firmware from the special storage component arranged for the security subsystem; and the security subsystem can replace the firmware with the recovery firmware.

[0114] The special storage component can be arranged in the RAM included in the security subsystem, and can also be arranged outside the BMC. In this case, the special storage component can be connected to the internal bus of the BMC, and only the security subsystem in the BMC can access the special storage component. Alternatively, the security subsystem can access the special storage component in compliance with the eSPI protocol described above, and the security subsystem can also access and control the special storage component. To this end, referring to FIG. 3, a communication controller and a filter can be arranged in the security subsystem for the special storage component. The communication controller can expose an SPI master interface (and an SPI Master interface) to the special storage component, and the special storage component can serve as an SPI slave (exposing an SPI Slave interface) of the communication controller. The physical core in the security subsystem can control the filter corresponding to the special storage component by executing the security control firmware, so as to ensure that the filter only allows the physical core of the security subsystem to access the special storage component. The cooperation process between the communication controller and the filter can follow the description in the foregoing embodiments, which will not be repeated here.

[0115] In this way, the recovery firmware stored in the special storage component can be protected from tampering. The recovery firmware in this embodiment can be a standard version of firmware, which is only exemplary and is not limited in this embodiment. The recovery firmware stored in the special storage component can cover various firmware required by each SOC in the computing device, so as to provide firmware recovery support for each SOC. The name of the recovery firmware stored in the special storage component is not exemplified here.

[0116] In addition, in this embodiment, the security subsystem can monitor the firmware of each SOC in the computing device that needs to be recovered. In an exemplary monitoring scheme, the firmware is determined to need to be recovered when any firmware fails to pass the security verification, the startup delay exceeds the preset threshold, and / or the SOC initiates a recovery instruction.

[0117] As mentioned above, the security subsystem can control the computing device to perform a secure startup based on the preset security control firmware. In this process, the security subsystem performs security verification on the firmware required by each SOC in the computing device. Only the SOC that passes the security verification can be powered on and continue to start. Therefore, the security subsystem can determine that the firmware needs to be recovered when it is monitored that any firmware used by any SOC fails to pass the security verification.

[0118] In this exemplary scheme, a preset threshold can also be set for the startup delay of each firmware. The security subsystem can monitor the startup delay of each firmware. If it is monitored that the startup delay of any firmware exceeds the corresponding preset threshold, it can be determined that the firmware needs to be recovered.

[0119] In this example solution, SOC is also allowed to actively initiate a recovery instruction, which can be delivered to the BMC through the bus, and the internal bus of the BMC can guide the recovery instruction to the security subsystem. When the security subsystem receives such a recovery instruction, it can determine that the firmware indicated in the recovery instruction needs to be recovered.

[0120] It should be understood that the above several monitoring aspects are only exemplary, and the security subsystem can also use other monitoring aspects to monitor whether the firmware used by the SOC in the computing device needs to be recovered, and is not limited thereto, and no more examples of monitoring aspects are given here.

[0121] Accordingly, in this embodiment, based on the security subsystem in the BMC and the special storage component provided for the security subsystem, a secure control of the firmware recovery solution can be provided for the computing device, and the security of the firmware used by the SOC in the computing device is ensured.

[0122] In the above or the following embodiments, the virtual machines in each SOC in the computing device can also share the security subsystem in the BMC in this embodiment based on a virtualization technology.

[0123] In this embodiment, the virtualization technology used is not limited, and it is only required to be able to support the BMC in this embodiment to be shared by the virtual machines in the related SOC.

[0124] FIG. 5 is a sharing logic diagram of a security subsystem provided by an example solution of the present disclosure. Referring to FIG. 5, optionally, a Single Root I / O Virtualization (SR-IOV) technology can be used in this embodiment to realize the sharing of the security subsystem.

[0125] SR-IOV is an IO virtualization technology that allows a bus device (i.e., a PCIe device) to be shared among multiple virtual machines while maintaining high performance. The security subsystem contained in the BMC in this embodiment can be used as a PCIe device shared in the SR-IOV technology. The SR-IOV technology is implemented on the basis of the bus PCIe specification, and two types of functions are introduced in the SR-IOV technology: Physical Function (PF) and Virtual Function (VF). Based on this, in the SR-IOV technology, multiple VFs can be created on the PF, and each VF can be assigned to a virtual machine to allow the virtual machine to directly access and control the VF, thereby realizing efficient I / O virtualization.

[0126] Referring to FIG. 5, based on the SR-IOV technology, a plurality of VFs can be created for the security subsystem included in the BMC in the embodiment, and the VFs can be assigned to virtual machines in the SOC. In FIG. 5, the SOC is a CPU in the computing device, so the VFs created for the security subsystem in the embodiment can be assigned to a host CPU (Host CPU) and a virtual machine CPU (VCPU) in the computing device. The Host CPU and each VCPU can initiate a call request to the VF assigned to itself, and based on the SR-IOV technology, the call request can be transmitted to the security subsystem included in the BMC of the embodiment through the bus of the computing device.

[0127] Based on this, in the embodiment, the security subsystem can receive a call request initiated by any virtual machine on any SOC in the computing device to the security subsystem, and the security subsystem can execute a preset security control firmware to respond to the call request. In the embodiment, the call request can be used to instruct the security subsystem to perform various processing functions supported by the trusted platform module, and the processing tasks instructed by the call request are not limited herein and no specific examples are given.

[0128] Accordingly, in the embodiment, a plurality of virtual machines created on the SOC in the computing device can share the security subsystem provided in the embodiment, the security subsystem can receive call requests initiated by the virtual machines and respond to the call requests in time, so the virtualization requirements of the SOC in the computing device can be met, and fine security control can be provided for the computing device in the virtualization scenario.

[0129] FIG. 6 is a flowchart of a security control method provided by another exemplary embodiment of the disclosure, which can be executed by a BMC installed in a computing device, the BMC is provided with a security subsystem and a function subsystem, and the security subsystem and the function subsystem are hardware-isolated. Based on this, referring to FIG. 6, the method can include steps 600 to 602.

[0130] Step 600: executing a preset security control firmware by the security subsystem to control security startup of the computing device.

[0131] Step 601: after the security startup of the computing device, receiving, through a bus interface of the baseboard management controller, an access request initiated by one or more system on chips in the computing device to a target storage component, the target storage component being a storage component that needs to be protected.

[0132] Step 602: if the security subsystem determines, according to the security control firmware, that the access request meets the security requirements, transmitting the access request to the target storage component through the function subsystem to protect data stored in the target storage component.

[0133] In an optional embodiment, the functional subsystem is provided with a communication controller for communicating with the target storage component, and the security subsystem is provided with a filter for controlling a communication link connected by the communication controller. Step 602 can include: if the security subsystem determines that the access request meets the security requirement according to the security control firmware, setting the filter to an on state to turn on the communication link between the communication controller corresponding to the access request and the target storage component; and transmitting the access request to the target storage component to be accessed by the communication controller through the communication link.

[0134] In an optional embodiment, the method can further include: if the security subsystem determines that the access request does not meet the security requirement, setting the filter to an off state to disconnect the communication link between the communication controller corresponding to the access request and the target storage component to intercept the access request.

[0135] In an optional embodiment, the method can further include: after receiving the access request, transmitting, by the functional subsystem, visitor identity information corresponding to the access request to the security subsystem; and if the security subsystem determines that the visitor identity information is located in a permitted list set for the target storage component in the security control firmware, determining that the access request meets the security requirement.

[0136] In an optional embodiment, the security subsystem includes a first physical core, the functional subsystem includes a second physical core, and a data exchange area is provided between the security subsystem and the functional subsystem. After the baseboard management controller is powered on, the method can further include: copying, by the first physical core after a secure boot, a preset security boot firmware to the data exchange area; executing, by the first physical core after determining that the security boot firmware passes a security verification, the security boot firmware to send a start signal to the second physical core; executing, by the second physical core after receiving the start signal, a boot loader corresponding to the functional subsystem if it is determined that the boot loader passes the security verification by executing the security boot firmware, the boot loader being used to guide the second physical core to perform a subsequent start operation; and performing, by the second physical core, a security verification on the subsequent start operation based on the security boot firmware to complete a secure start of the second physical core.

[0137] In an optional embodiment, the method can further include: when it is monitored by the security subsystem that the functional subsystem is restarted, controlling the second physical core to restart securely without restarting the security subsystem.

[0138] In an optional embodiment, after the power-on of the baseboard management controller, the method can further comprise: during the startup process of the security subsystem, if it is monitored that there is another powered-on bus device in the computing device other than the baseboard management controller, then performing security verification on the identity and firmware of the powered-on bus device by the security subsystem; if the security subsystem detects that any powered-on bus device fails the security verification, then the security subsystem stops the startup.

[0139] In an optional embodiment, the step of controlling the security startup of the computing device based on the security management firmware set in the security subsystem can comprise: after the security startup of the security subsystem, executing the security management firmware by the security subsystem to measure the firmware required to be used by each system on chip in the computing device to obtain the measurement result corresponding to each system on chip; using the security subsystem to control the power-on of each system on chip in the computing device according to the measurement result; after the power-on of each system on chip, using the security subsystem as a root of trust to establish a startup trust chain for the computing device to control the security startup of the computing device.

[0140] In an optional embodiment, the method can further comprise: if it is monitored by the security subsystem that any firmware used by any system on chip in the computing device needs to be recovered, then reading the recovery firmware corresponding to the firmware from a dedicated storage component set for the security subsystem; replacing the firmware by the recovery firmware by the security subsystem.

[0141] In an optional embodiment, the method can further comprise: in the case that any firmware fails the security verification, the startup delay exceeds a preset threshold, and / or the system on chip to which the firmware belongs initiates a recovery instruction, determining that the firmware needs to be recovered.

[0142] In an optional embodiment, based on a virtualization technology, a plurality of virtual machines in any system on chip in the computing device share the security subsystem, the method can further comprise: receiving a calling request for the security subsystem initiated by any virtual machine in the system on chip; executing the security management firmware by the security subsystem to respond to the calling request.

[0143] In an optional embodiment, a data exchange area is set between the security subsystem and the function subsystem, the method can further comprise: writing the management record information generated in the security management process into the data exchange area by the security subsystem; reading the management record information from the data exchange area by the function subsystem and forwarding it to a security monitoring system other than the baseboard management controller; wherein the management record information comprises alarm information and / or abnormal information.

[0144] In an optional embodiment, the target storage component includes a flash memory for storing basic input / output system firmware and / or a flash memory for storing various firmware required to be used by the baseboard management controller; and the access request complies with a serial advanced technology attachment protocol.

[0145] It is worth mentioning that the technical details in the above embodiments of the security management method can refer to the related description of the baseboard management controller in the foregoing computing device embodiments, which will not be repeated here to save space, but this should not cause the loss of the protection scope of the present disclosure.

[0146] In addition, in some of the processes described in the above embodiments and accompanying drawings, a plurality of operations appearing in a specific order are included, but it should be clearly understood that these operations can be executed in the order appearing in this text or in parallel, and the serial numbers of the operations such as 601, 602, etc. are only used to distinguish different operations, and the serial numbers themselves do not represent any execution order. In addition, these processes can include more or fewer operations, and these operations can be executed in sequence or in parallel. It should be noted that the descriptions of "first", "second", etc. in this text are used to distinguish different physical cores, etc., and do not represent the order, nor limit that "first" and "second" are different types.

[0147] Correspondingly, the embodiments of the present disclosure also provide a computer readable storage medium storing a computer program, which is executed to implement each step in the above method embodiments.

[0148] Correspondingly, the embodiments of the present disclosure also provide a computer program product, which contains a computer program executed to implement each step in the above method embodiments.

[0149] Those skilled in the art should understand that the embodiments of the present disclosure can be provided as a method, a system, or a computer program product. Therefore, the present disclosure can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present disclosure can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0150] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

[0151] These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart block or blocks.

[0152] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

[0153] It should also be noted that the terms "comprising," "including," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements in the list, but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element preceded by "comprises a" does not, without more constraints, foreclose the existence of additional identical elements in the process, method, article, or apparatus that includes the recited element.

[0154] It should be noted that the user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present disclosure are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation portal for user to choose authorization or refusal.

[0155] The above merely provides an example of the present disclosure but is not intended to limit the present disclosure. The present disclosure can have various modifications and changes for those skilled in the art. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present disclosure shall be included in the protection scope of the present disclosure.

Claims

1. A method of safety management, wherein, A substrate management controller suitable for being installed in a computing device, a security subsystem and a function subsystem are arranged in the substrate management controller, the security subsystem and the function subsystem are hardware isolated, and the method comprises: performing a preset security control firmware by the security subsystem to control a secure boot of the computing device; after the secure boot of the computing device, receiving, by a bus interface of the substrate management controller, an access request for a target storage component from one or more system on chips in the computing device, the target storage component being a storage component that needs to be protected; if the security subsystem determines that the access request meets preset security requirements according to the security control firmware, the access request is transmitted to the target storage component by the function subsystem.

2. The method of claim 1, wherein, The function subsystem is provided with a communication controller for communicating with the target storage component, and the security subsystem is provided with a filter for controlling a communication link connected by the communication controller, if the security subsystem determines that the access request meets the security requirements according to the security control firmware, the access request is transmitted to the target storage component by the function subsystem, comprising: if the security subsystem determines that the access request meets the security requirements according to the security control firmware, the filter is set to an on state to turn on the communication link between the communication controller corresponding to the access request and the target storage component; the access request is transmitted to the target storage component to be accessed by the communication controller through the communication link.

3. The method of claim 2, wherein, Further comprising: if the security subsystem determines that the access request does not meet the security requirements, the filter is set to an off state to disconnect the communication link between the communication controller corresponding to the access request and the target storage component.

4. The method according to any one of claims 1 to 3, wherein, Further comprising: after receiving the access request, the access request corresponding to the visitor identity information is transmitted to the security subsystem by the function subsystem; if the security subsystem determines that the visitor identity information is in a permitted list set for the target storage component in the security control firmware, it is determined that the access request meets the security requirements.

5. The method of claim 1, wherein, The security subsystem comprises a first physical core, the function subsystem comprises a second physical core, and a data exchange area is arranged between the security subsystem and the function subsystem, after the substrate management controller is powered on, the method further comprises: the first physical core copies a preset security boot firmware to the data exchange area after a secure boot; the first physical core executes the security boot firmware after determining that the security boot firmware passes the security verification, to send a boot signal to the second physical core; after receiving the boot signal, if the second physical core determines that a boot loader corresponding to the function subsystem passes the security verification by executing the security boot firmware, the boot loader is executed, and the boot loader is used to guide the second physical core to perform a subsequent boot operation; The second physical core performs security verification on the subsequent boot operation based on the secure boot firmware to complete secure boot of the second physical core.

6. The method of claim 5, wherein, Further comprising: When it is monitored by the security subsystem that the functional subsystem is restarted, the second physical core is controlled to be re-booted securely without restarting the security subsystem.

7. The method of claim 1, wherein, After the substrate management controller is powered on, the method further comprises: During the booting process of the security subsystem, if it is monitored that there is another powered-on bus device in the computing device in addition to the substrate management controller, the identity and / or required firmware of the powered-on bus device is verified securely by the security subsystem; If the security subsystem detects that any powered-on bus device fails to pass the security verification, the security subsystem stops booting.

8. The method of claim 1, wherein, Based on the security management firmware set in the security subsystem, the computing device is controlled to be booted securely, including: After the security subsystem is booted securely, the security management firmware is executed by the security subsystem to measure the firmware required to be used by each system on chip in the computing device to obtain the measurement result corresponding to each system on chip; The security subsystem is used to control the power-on of each system on chip in the computing device according to the measurement result; After each system on chip is powered on, the security subsystem is used as a root of trust to establish a boot trust chain for the computing device to control the computing device to be booted securely.

9. The method of claim 1, wherein, Further comprising: If it is monitored by the security subsystem that any firmware used by any system on chip in the computing device needs to be recovered, the recovery firmware corresponding to the firmware is read from the special storage component set for the security subsystem; The firmware is replaced with the recovery firmware by the security subsystem.

10. The method of claim 9, wherein, Further comprising: In the case that any firmware fails to pass the security verification, the booting delay exceeds a preset threshold, and / or the system on chip initiates a recovery instruction actively, it is determined that the firmware needs to be recovered.

11. The method of claim 1, wherein, Based on virtualization technology, a plurality of virtual machines in any system on chip in the computing device share the security subsystem, and the method further comprises: A calling request initiated by any virtual machine in the system on chip for the security subsystem is received; The security management firmware is executed by the security subsystem to respond to the calling request.

12. The method of claim 1, wherein, A data exchange area is set between the security subsystem and the functional subsystem, and the method further comprises: Control record information generated in the security management process is written into the data exchange area by the security subsystem; The control record information is read from the data exchange area by the functional subsystem and is forwarded to a security monitoring system other than the substrate management controller; The control record information includes alarm information and / or abnormal information.

13. The method of claim 1, wherein, The target storage component includes a flash memory for storing basic input / output system firmware and / or a flash memory for storing various firmware required to be used by the substrate management controller; and the access request complies with the enhanced serial peripheral interface protocol.

14. A baseboard management controller, wherein, comprising a safety subsystem and a functional subsystem, the safety subsystem and the functional subsystem being hardware isolated, the safety subsystem and the functional subsystem performing the safety governance method of any of claims 1-13.

15. A computer readable storage medium storing a computer program, wherein, The computer program, when executed by one or more processors, causes the one or more processors to perform the safety governance method of any of claims 1-13.

16. A computer program product, wherein, The computer program, when executed by one or more processors, causes the one or more processors to perform the safety governance method of any of claims 1-13.

Images