Security protection method and device based on functional component, management chip and computer device

Abstract

This application discloses a security protection mechanism based on functional components. This mechanism is applied to a management chip, which runs at least one functional component to perform corresponding functions. During the operation of the functional component, if an access instruction to the functional component is received, and if the access instruction is to call a risky interface, i.e., a preset interface, a uniformly configured configuration file, such as a first configuration file indicating the allowed access range of the preset interface, can be used to verify whether the access object of the access instruction belongs to the allowed access range in the configuration file. If it belongs to the access range, the operation corresponding to the access instruction is executed; otherwise, it indicates that the access instruction is risky, and the access instruction is ignored or rejected, thereby avoiding security vulnerabilities and improving the security of computer devices.

Description

Technical Field

[0001] This application relates to the field of chip technology, and in particular to a security protection method, device, management chip, and computer equipment based on functional components. Background Technology

[0002] Currently, with the development of open-source baseboard management controllers (BMCs), they can provide a wealth of functions, including but not limited to server hardware status monitoring, power management, and firmware updates. Through open-source BMCs, users can utilize their open codebase to develop server management functions, i.e., functional components, suitable for their own hardware environments.

[0003] However, the aforementioned functional components bring a series of security issues. For example, since the development of these functional components requires high coding skills from developers, if their skills are insufficient, security vulnerabilities can easily be introduced during the development process, leading to various security problems. Therefore, there is an urgent need for a security protection method that can improve security. Summary of the Invention

[0004] This application provides a security protection method, device, management chip, and computer equipment based on functional components, which can provide effective security protection and improve the security of computer equipment.

[0005] Firstly, a security protection method based on functional components is provided, applied to a management chip. The management chip runs at least one functional component. When it receives an access command targeting this functional component, and the access command invokes a pre-defined interface that poses a risk, the method verifies the access command based on a first configuration file that restricts the allowed access scope of the pre-defined interface. If the verification passes, the method responds to the first access command; if the verification fails, the method does not respond to the access command, for example, by refusing to respond to the access command or ignoring it. By restricting the allowed access scope of the interface, even if the user has access rights to the interface, abnormal access is still restricted from the scope of access, thus achieving security protection for the computer device and improving its security.

[0006] Among them, the preset interfaces are pre-configured interfaces, which are interfaces with access risks. These include: interfaces for managing the operating system on the management chip, interfaces for managing the second functional components running on the management chip, and interfaces managed by the management chip. These preset interfaces include system command execution interfaces, file read / write / move interfaces, compressed file decompression interfaces, and mount interfaces, etc.

[0007] In some possible implementations, the first configuration file is configured with the input parameters allowed by the preset interface. In other possible implementations, the first configuration file is configured with the input parameters not allowed by the preset interface. Both configuration methods can realize the validation of the input parameters of the access command and achieve the purpose of restricting the range that can be accessed through the interface. The response configuration can be made according to the actual business to provide more flexible validation.

[0008] In some possible implementations, the method further inserts target executable code for triggering verification into the executable file in real time when loading the executable file containing the functional component containing the target function. Since the target executable code is dynamically inserted into the executable file only during loading, there is no need to modify the source code corresponding to the executable file. Therefore, the security protection provided by the embodiments of this application can be achieved without updating the functional component. Moreover, this approach is more refined, as it does not treat the functional component as a single entity, but rather finds the target function that calls the interface based on the interface, and then inserts executable code based on the target function. This avoids the inability to identify certain permission models and prevents the spread of risks.

[0009] In some possible implementations, the first configuration file is loaded when any executable file containing the target function is loaded. The timing of this loading includes various possible implementations, such as loading the first configuration file synchronously when the target executable code is inserted, loading the first configuration file after the target executable code is inserted, or loading the first configuration file when the first functional component 1 is loaded, etc.

[0010] In some possible implementations, the management chip's verification of access commands includes verification based on a first configuration file and verification based on a second configuration file. That is, the management chip is also configured with a second configuration file, which indicates the scope of system resources that are allowed to be accessed. This can be understood as indicating the interfaces that are allowed to be accessed. For example, the second configuration file indicates the interface and its corresponding access permissions. Accordingly, when performing verification based on these two types of configuration files, the second configuration file can be used to determine whether the interface the access command seeks to access is allowed. If not, the access command is rejected. If it is allowed, and the interface called by the access command is a preset interface, further verification is performed based on the first configuration file to determine whether the object the access command seeks to access is within the allowed access range of that interface. If it is within the allowed access range, the corresponding access command is executed; if it is not within the allowed access range, the access command is rejected. Thus, through verification from different perspectives, more refined security protection is achieved.

[0011] The second configuration file restricts the scope of allowed system resources from multiple dimensions to limit the security permissions of functional components and reduce the impact of security vulnerabilities. For example, this second configuration file restricts the scope of allowed system resources from one or more combinations of the following dimensions: directories, files, system commands, processes and process-related resources, network resources, and system hardware resources. Accordingly, the verification process based on the second configuration file includes one or more combinations of the following: verifying whether the access command has access permissions to the corresponding directory; verifying whether the access command has access permissions to the corresponding file; verifying whether the access command has the right to call the corresponding system command; verifying whether the access command has access permissions to the corresponding process; verifying whether the access command has access permissions to the resources related to the corresponding process; verifying whether the access command has access permissions to the corresponding network resources; and verifying whether the access command has access permissions to the corresponding system hardware resources. The specific verification combinations used can be based on business configuration.

[0012] Secondly, a security protection device based on functional components is provided, applied to a management chip, the management chip having a first functional component running on it, the device including at least one functional module, the at least one functional module being used to implement the method provided by the first aspect or any optional method of the first aspect.

[0013] In some embodiments, the modules in the security protection device are implemented via hardware or firmware. Specific details of the security protection device provided in the second aspect can be found in the first aspect or any alternative embodiment of the first aspect described above, and will not be repeated here.

[0014] Thirdly, a management chip is provided, which includes a processing unit, a storage unit, and multiple interfaces. The multiple interfaces are used to communicate with hardware components outside the management chip, and the processing unit is used to implement the method provided by the first aspect or any optional method of the first aspect.

[0015] Fourthly, a computer device is provided, comprising a processor, a memory, and a management chip, wherein the processor is connected to the memory, and the processor and the memory are respectively connected to the management chip, and the computer device is used to implement the method provided by the first aspect or any optional method of the first aspect.

[0016] Fifthly, a computer-readable storage medium is provided for storing at least one piece of program code for implementing the method provided in the first aspect or any alternative method of the first aspect.

[0017] In a sixth aspect, a computer program product is provided, which is used to implement the method provided in the first aspect or any alternative method of the first aspect. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of an implementation environment provided in an embodiment of this application;

[0019] Figure 2 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application;

[0020] Figure 3 This is a schematic diagram of the hardware structure of the management chip 300 provided in an embodiment of this application;

[0021] Figure 4 This application provides a functional architecture diagram of an exemplary management chip 300.

[0022] Figure 5 This is a schematic diagram of an exemplary implementation environment of the management chip provided in this application embodiment;

[0023] Figure 6 This is an exemplary flowchart of a security protection method based on functional components provided in this application embodiment;

[0024] Figure 7 This is a schematic diagram of an exemplary implementation environment of the management chip provided in this application embodiment;

[0025] Figure 8 This is an exemplary flowchart of a security protection method based on functional components provided in this application embodiment;

[0026] Figure 9 This is a schematic diagram of the structure of a security protection device based on functional components provided in an embodiment of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings. It should be noted that all information (including but not limited to interfaces), data (including but not limited to files, directories, etc.) and signals involved in this application are authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the interfaces involved in this application are all obtained under fully authorized conditions.

[0028] To facilitate understanding, the key terms and concepts involved in this application will be explained below.

[0029] Source code, also known as source program, refers to an uncompiled text file written according to certain programming language specifications. It includes a series of computer language instructions, such as program code written in C or Java.

[0030] An executable file is a file that can be loaded and executed by the operating system; such as an assembly language file or a binary file.

[0031] Compilation refers to converting source code written in one programming language into another programming language, such as converting source code written in C language into machine language or assembly language.

[0032] Executable code refers to code that a machine can directly execute, such as assembly language code and binary code.

[0033] A compiler is used to convert source code based on a high-level programming language into an executable file in a low-level programming language. High-level programming languages ​​can be procedural or object-oriented languages ​​such as Java, C, C++, and Python. Low-level programming languages ​​can be machine language or assembly language.

[0034] Dynamic instrumentation refers to inserting new program code into the executable file of a program while ensuring the integrity of the original program logic.

[0035] This application can be applied to scenarios where business logic is executed based on functional components of management chips. Currently, with the open source code of functional components of management chips such as BMCs, the services they provide typically need to support customer needs for hardware management and operation. This type of hardware management and operation often requires higher privileges, and once these privileges are compromised, it can affect the operating system environment and the operational security of computer equipment. However, the development of functional components is usually limited by the capabilities of technical personnel, making effective security protection impossible. Therefore, this application provides a security protection method based on functional components, which can effectively improve security.

[0036] The following is for reference. Figure 1 The implementation environment of this application will be described.

[0037] Figure 1 This is a schematic diagram of an implementation environment provided in an embodiment of this application. See also... Figure 1The implementation environment includes a computer device 101 and a server 102. The computer device 101 is equipped with a management chip, on which at least one functional component runs to perform corresponding functions, such as monitoring and managing the hardware of the computer device 101. It is understood that this at least one functional component can be an open-source component; however, the functional component running on the management chip can also include non-open-source components. The server is associated with the management chip and can provide services such as security protection. This security protection service can be based on the existing security mechanisms of the management chip (or it may not have any security mechanisms set up). The management chip provides a configuration file for additional security protection. By configuring isolation policies or access restrictions for access commands in the configuration file, the operation of the management chip can be made more secure and reliable. This configuration file can be configured uniformly by the server, or it can be distributed to the management chip by the server after a firmware update; this embodiment does not limit this. By providing unified security protection by the server, the technical requirements for developers are lower; only some technical personnel are needed for configuration, thus improving the quality and uniformity of security protection.

[0038] This application does not limit the type of computer device 101. For example, computer device 101 may be a general-purpose server or an artificial intelligence system.

[0039] Artificial intelligence (AI) servers, cloud servers, base stations, routers, switches, terminal devices, baseboard management controllers (BMC) boards, smart network interface cards (NICs), V2X devices, B2C devices, B2B devices, etc. Terminal devices include mobile phones, tablets, wearable devices, in-vehicle devices, augmented reality (AR) and virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, and personal digital assistants (PDAs), among other mobile terminal devices.

[0040] The transmission of the aforementioned configuration file is achieved through a communication connection between the management chip and the server, and can occur during firmware upgrades of the management chip by the server. In some embodiments, the management chip supports standard communication technologies and / or protocols. The network includes, but is not limited to, Transmission Control Protocol / Internet Protocol (TCP / IP) networks and RDMA networks such as RoCE networks, InfiniBand (IB) networks, Storage Area Networks (SANs), Local Area Networks (LANs), Metropolitan Area Networks (MANs), Wide Area Networks (WANs), mobile, wired or wireless networks, private networks, or any combination of virtual private networks. In some implementations, technologies and / or formats including Hypertext Markup Language (HTML), Extensible Markup Language (XML), etc., are used to represent data exchanged over the network. In addition, conventional encryption technologies such as Secure Sockets Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), and Internet Protocol Security (IPsec) can be used to encrypt all or part of the link. In other embodiments, custom and / or dedicated data communication technologies can be used to replace or supplement the aforementioned data communication technologies.

[0041] Figure 2 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. See also... Figure 2The computer device 200 may include a processor 201, a management chip 202, and a memory 203. The computer device 200 also includes an external memory interface 204 and a universal serial bus (USB) interface 205, etc. It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the computer device 200. In other embodiments of this application, the computer device 200 may include more or fewer components than illustrated, or combine certain components, or split certain components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0042] Processor 201 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0043] The processor 201 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 201 is a cache memory. This memory can store instructions or data that the processor 201 has just used or that are used repeatedly. If the processor 201 needs to use the instruction or data again, it can directly retrieve it from this memory. This avoids repeated accesses, reduces the waiting time of the processor 201, and thus improves the efficiency of the system.

[0044] Management chip 202 as described above Figure 1 As shown, the management chip 202 can connect to multiple hardware components of a computer device through its interface, thereby enabling the management of the hardware within the computer device. For example, the management chip 202 connects to the processor 201 through the interface, and also connects to the computer device's memory and hard disk through the same interface to monitor the working status of the memory and hard disk. The management chip 202 can also connect to the computer device's network card through the interface for network communication, enabling functions such as remote access.

[0045] Memory 203 can be used to store computer executable program code, which includes instructions. Memory 203 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, and universal flash storage (UFS). Processor 201 executes various functional applications and data processing of computer device 200 by running instructions stored in memory 203 and / or instructions stored in memory disposed in the processor.

[0046] The external memory interface 204 can be used to connect external memory, thereby expanding the storage capacity of the computer device 200. The external memory communicates with the processor 201 through the external memory interface 204 to perform data storage functions.

[0047] It is understood that the above structure is only one hardware possibility for implementing the management chip provided in the embodiments of this application, and the embodiments of this application do not specifically limit it.

[0048] Figure 3 This is a schematic diagram of the hardware structure of the management chip 300 provided in an embodiment of this application. See also... Figure 3 The management chip 300 includes at least one processing unit 301, at least one storage unit 302, and multiple interfaces, including at least one communication interface 303 and at least one sensor interface 304. The processing unit 301 is connected to the storage unit 302 and the at least one communication interface 303 and the at least one sensor interface 304, respectively. The management chip 300 is used to execute the functional component-based security protection method provided in the embodiments of this application.

[0049] The processing unit 301 is the core component in the hardware structure of the management chip. It is generally implemented as a low-power, high-performance microprocessor, such as an ARM (advanced RISC (reduced instruction set computer) machine) architecture processor or other low-power, high-performance embedded processor. It is used to execute the program code in the firmware stored in the memory unit of the management chip and to manage and monitor the hardware of the computer device.

[0050] Storage unit 302 typically includes various types of memory for storing firmware, system configuration information, log data, and other content. In some embodiments, storage unit 302 includes flash memory and random access memory (RAM).

[0051] Flash memory is a common type of storage used in management chips to store the chip's firmware. Firmware is software embedded in the hardware device that contains program code that controls the management chip's operation, defining how the chip interacts with the computer device's hardware and responds to external requests. For example, when the management chip boots up, it reads and executes the firmware code from flash memory to perform functions such as system monitoring and power management. The non-volatile nature of flash memory ensures that the firmware and related configuration data are not lost after the device is powered off. Furthermore, flash memory can be upgraded via a specific programming interface, allowing the management chip to continuously update its functionality or fix vulnerabilities. Flash memory also stores the bootloader. When the management chip boots up, the bootloader runs to initialize the hardware device, such as setting the processor's clock frequency and initializing the memory controller. Then, the bootloader loads the management chip's operating system kernel, stored in flash memory, into memory and starts the system.

[0052] RAM includes static random access memory (SRAM) or dynamic random access memory (DRAM) for temporary storage of data and program code. In some embodiments, SRAM can be used to store small amounts of critical data that the management chip needs to access quickly. DRAM is used to store system programs, data caches, etc., during operation. For example, when the management chip collects sensor data (such as temperature, voltage, etc.) from computer device hardware, this data is first stored in DRAM, then processed to determine whether to store it in flash memory or use it for other operations.

[0053] The aforementioned communication interface 303 is used to communicate with components other than the management chip 300. This communication interface 303 includes a network interface, a hardware management interface, and a serial interface, among others.

[0054] The management chip 300 is typically equipped with one or more network interfaces for connecting to an external network. For example, these network interfaces may be Ethernet interfaces, meaning they support standard Ethernet protocols such as 30 / 300 / 3000 Mbps Ethernet. Through these network interfaces, the management chip can perform remote management functions, such as accepting commands from a remote management console or sending status information of computer device hardware to a remote monitoring system.

[0055] The management chip 300 typically also includes one or more hardware management interfaces for connecting to and managing the hardware of a computer device. These hardware management interfaces allow the management chip to communicate with other hardware devices on the computer's motherboard, including the central processing unit (CPU), memory, and hard drive. It can obtain status information about this hardware, such as temperature, voltage, and fan speed, and send control commands, such as adjusting fan speed or restarting the hardware. This hardware management interface can be a physical interface or an interface implemented through software simulation. For example, it could be an Intelligent Platform Management Interface (IPMI) interface, a specialized interface for managing computer device hardware. Of course, the hardware management interface configured on the management chip can also be other protocol interfaces, matching the protocols supported by the hardware in the computer device.

[0056] The management chip 300 is typically also equipped with one or more serial interfaces for local debugging and simple communication tasks. For example, during the development and testing phases of the management chip, engineers can connect to the chip via the serial interface to send debugging commands and view debugging information. In some special cases, the serial interface can also serve as a backup communication method when network connectivity is unavailable or malfunctions. In some embodiments, the serial interface is also used to connect to a memory unit for communication.

[0057] The aforementioned sensor interface 304 is used to connect to sensors on the computer device hardware to receive analog or digital signals from the sensors. For example, this sensor interface 304 is an inter-integrated circuit (I2C) interface. This sensor interface 304 includes a temperature sensor interface for connecting to a temperature sensor installed within the computer device, capable of receiving analog or digital signals from the temperature sensor to obtain temperature information from different locations inside the computer device (such as near the CPU heatsink, around the hard drive slots, etc.). This sensor interface 304 also includes a voltage sensor interface for connecting to a voltage detection device within the computer device to monitor the power supply voltage of hardware devices such as the motherboard, CPU, and memory. When abnormal voltage fluctuations occur, the management chip can detect them promptly and take measures, such as issuing an alarm or adjusting the power supply, to protect the hardware from damage. This sensor interface 304 also includes a fan speed sensor interface for connecting to the computer device's cooling fan speed sensor to monitor the fan speed. The management chip can determine whether the cooling system is working properly based on the fan speed information and can adjust the fan speed as needed to ensure that the internal temperature of the computer device remains within a reasonable range.

[0058] In some embodiments, the management chip 300 further includes other hardware components, such as a clock circuit and a reset circuit. The clock circuit provides a stable clock signal to the management chip, ensuring that the various components within the chip operate synchronously. The reset circuit resets the management chip hardware to its initial state when an abnormal condition occurs (such as a software failure or power fluctuation). The reset circuit can restart the management chip manually (e.g., via a reset button) or automatically (e.g., when a power abnormality is detected), restoring it to normal operation.

[0059] It should be noted that the above description of each part is only one possible implementation of the management chip. The management chip can also be implemented in other forms, and the embodiments of this application do not limit this.

[0060] Figure 4 This application provides a functional architecture diagram of an exemplary management chip 300. See also... Figure 4 The functional architecture of the management chip 300 consists of, from top to bottom, the application layer, the operating system layer, the driver layer, and the hardware layer.

[0061] The hardware layer includes, for example: Figure 3 The processing unit 301, storage unit 302, communication interface 303, and sensor interface 304 shown are not described in detail here. The driver layer includes the aforementioned bootloader and core firmware.

[0062] The operating system layer is primarily responsible for managing and allocating the hardware resources of the management chip, providing a unified and abstract operating environment for upper-layer functional components. For example, in memory management, it allocates and reclaims memory space, ensuring that different programs (including application-level programs) can use memory rationally. The operating system layer also provides device drivers, enabling the management chip to communicate with various hardware devices (such as temperature sensors and Ethernet interfaces).

[0063] The driver layer provides a basic hardware operating environment for the operating system layer. After the management chip boots up, the driver layer completes hardware initialization and then hands control over to the operating system. For example, during the management chip boot phase, the firmware sets the processor's basic operating mode and the initial state of memory, enabling the operating system to boot smoothly and begin further resource management and device driver loading. The firmware also provides basic hardware control functions, such as simple data reading from sensor interfaces and operations on some hardware status registers. Taking a temperature sensor as an example, the firmware contains code that can directly read the raw data transmitted from the temperature sensor interface; this process does not require complex scheduling and resource management from the operating system.

[0064] The application layer (software layer) focuses on implementing specific business functions and directly addresses user needs. It can run various functional components, including open-source and non-open-source components, such as hardware monitoring, remote management, and configuration management components. The hardware monitoring component is responsible for real-time monitoring of the server hardware status. The remote management components include remote KVM (keyboard, video, mouse) applications and remote command execution applications. The remote KVM component allows administrators to remotely access the server's console via the network to perform operations such as installing the operating system and configuring server software. The remote command execution component receives commands from the administrator, such as querying server hardware status, setting network parameters, and updating firmware, and then passes these commands to the hardware layer of the management chip for execution. The configuration management component manages the server's basic input / output system (BIOS), unified extensible firmware interface (UEFI), and network configurations. Of course, the application layer can also run other types of components; this embodiment does not limit this.

[0065] Application-layer programs rely on services and resources provided by the operating system layer. They run in the runtime environment created by the operating system and require support from functions such as process management, memory management, and file systems provided by the operating system. For example, a hardware monitoring component needs the operating system to allocate memory space to store monitoring data, the operating system's file system to store configuration files and log files, and the operating system's process scheduling function to ensure that it can periodically obtain hardware status information. If the operating system malfunctions or malfunctions, the operation of application-layer programs will also be affected.

[0066] This application provides a security protection method based on functional components, applied to a management chip. The management chip runs at least one functional component to perform corresponding functions. During the operation of the functional component, if an access instruction is received, and if the instruction requests a call to a risky interface (i.e., a preset interface), a uniformly configured configuration file, such as a first configuration file indicating the allowed access range of the preset interface, can be used to verify whether the access object of the access instruction falls within the allowed access range. If it does, the operation corresponding to the access instruction is executed; otherwise, it indicates that the access instruction is risky, and the instruction is ignored or rejected, thereby avoiding security vulnerabilities. Optionally, this configuration file can be configured by any developer. For example, in the open-source community, the configuration file can be configured by the publisher of the open-source component or by the user of the open-source component. Open-source components can be exempt from related security protection code, reducing the security capability requirements for developers. Verification of risky interfaces can be overseen by a single security expert, ensuring the quality and consistency of system security protection.

[0067] To achieve the aforementioned verification, during the functional component loading stage, the management chip dynamically instrumentes target executable code into the executable file of the functional component. This target executable code instructs verification based on a first configuration file before executing the target function. Specifically, the method further includes: in response to loading the executable file of the first functional component and the executable code of the first functional component including a target function, inserting target executable code into the executable file of the first functional component. The target executable code instructs verification based on the first configuration file before executing the target function, and the target function calls a preset interface. Since the target executable code is dynamically inserted into the executable file during loading, there is no need to modify the source code corresponding to the executable file. Therefore, the security protection provided by this application embodiment can be achieved without updating the functional component. Moreover, this approach is more refined, avoiding treating the functional component as a single entity. Instead, it uses the interface as a starting point to find the target function that calls the interface, and then inserts executable code based on the target function. This prevents the inability to recognize certain permission models and avoids the spread of risks.

[0068] During the loading of the executable file, the management chip detects whether the functions in the executable file are target functions, that is, it detects whether there are functions in the executable file that call preset interfaces, thereby locating risky locations. If a target function is detected, target executable code is inserted before that target function so that the target executable code can be executed before the management chip executes the target function, thus realizing the detection of access instructions. The target executable code inserted for functions calling different interfaces can be the same or different. Whether the same executable code is inserted can be changed according to the code logic, which will not be elaborated on in this embodiment.

[0069] In some embodiments, the management chip detects whether a function in the executable file is a target function by: the management chip detecting the function in the executable file based on preset detection information, which includes preset function names, function identifiers, preset interface identifiers, etc. Taking the preset detection information including preset function names as an example, when loading the executable file of the functional component, the management chip detects the function names of the functions in the executable file. If a function with the preset function name exists, the target executable code is inserted before the function with the preset function name. Other methods are similar and will not be elaborated here. Of course, the detection method may also include the detection of other information, which is not limited in this embodiment. The above process can be called dynamic instrumentation. For example, the dynamic instrumentation can be performed by adding a plugin through the dynamic binary instrumentation (DBI) tool. The plugin is used to instruct the DBI tool to insert the target executable code when the executable file contains a target function.

[0070] In this embodiment, the preset interface is a pre-configured interface, i.e., an interface with access risks. For example, the preset interface includes interfaces for managing the operating system on the management chip, interfaces for managing other functional components running on the management chip, and interfaces managed by the management chip. The interfaces managed by the management chip refer to the interfaces provided by the computer devices managed by the management chip. The preset interface includes a system command execution interface, a file read / write / move interface, a compressed file decompression interface, and a mount interface. This preset interface can be set by developers based on actual business needs.

[0071] For functional components, access commands can be used to call the operating system interface of the management chip to access system resources. They can also call other functional components on the management chip and access interfaces managed by the chip, such as those provided by the operating system of a computer device. Correspondingly, by restricting access to objects accessible through preset interfaces—for example, restricting access to files through that interface—vulnerabilities in current security mechanisms are mitigated. Current security mechanisms typically detect the information carried by access commands to determine their security. However, this information can take many forms; for example, for a file's access path, the command might carry an absolute path or a relative path. Therefore, conventional detection methods are prone to misses, failing to achieve effective security protection. Restricting access to objects through certain risky interfaces, however, achieves effective security protection.

[0072] The first configuration file provided in this application embodiment can indicate the access scope allowed by a preset interface. The access scope includes various forms, such as indicating the files that are allowed to be accessed when the preset interface is called, or the interfaces that the preset interface allows to be called further.

[0073] In this embodiment, the management chip differentiates between open-source and non-open-source components during loading based on their type. For example, it performs target function detection when loading open-source components, but not when loading non-open-source components, thus providing targeted security protection against security vulnerabilities posed by open-source components. In some embodiments, the management chip performs target function detection on each functional component during loading to protect each individual component.

[0074] In some embodiments, the configuration file is stored in the storage unit of the management chip, so that when the executable file of the functional component is loaded, the configuration file can be loaded from the storage unit of the management chip. In some embodiments, the configuration file is stored on a server, and the management chip can obtain the configuration file through communication with the server and then perform the above loading process. This application does not limit this.

[0075] In some embodiments, the above-mentioned verification process for access commands includes: verifying the input parameters of the access command based on the input parameters allowed by the interface; if the input parameters of the access command meet the requirements of the allowed input parameters of the interface, the verification passes; otherwise, the verification fails. For example, for an interface, the allowed input parameters are less than 1000. If the input parameters of the access command are greater than 1000, the verification fails; if the input parameters of the access command are less than 1000, the verification passes. It is understood that the allowed input parameters of the interface may include at least one parameter. The above-mentioned non-compliance means that if any input parameter of the access command does not meet the requirements of the allowed input parameters of the interface, then the input parameters of the access command do not meet the requirements of the allowed input parameters of the interface. In other embodiments, the verification process includes: verifying the input parameters of the access command based on the input parameters not allowed by the interface; if the input parameters of the access command meet the requirements of the input parameters not allowed by the interface, the verification fails; otherwise, the verification passes. The above verification conditions can be set based on the actual business situation set by the developers, and this application embodiment does not limit this.

[0076] Below, in conjunction with Figure 5 and Figure 6 The above security protection process will be illustrated by example. Figure 5 An exemplary implementation environment for the management chip is provided, taking functional components 1, 2, and 3 as an example. Functional components 1 and 2 are open-source components, while functional component 3 is a non-open-source component. The executable file of functional component 1 includes function 1, which calls interface 1 of functional component 3 to execute function 1. The executable file of functional component 2 includes function 2, which calls interface 2 of the computer operating system to execute function 2. Both interface 1 and interface 2 are preset interfaces. Figure 6 This is an exemplary flowchart of the security protection method based on functional components, which includes the following steps.

[0077] Step 601: The management chip starts up and loads the executable files of functional components 1 to 3.

[0078] When the computer device is powered on, the management chip is triggered to start. When the management chip starts, it can load the executable files of the functional components, thereby enabling the functional components to run.

[0079] Step 602: In response to loading the executable file of functional component 1, the management chip inserts target executable code into the executable file of functional component 1. The target executable code is used to indicate that verification is performed based on configuration file config1 before executing function 1. Function 1 calls interface 1 of functional component 3.

[0080] In step 603, in response to loading the executable file of functional component 2, the management chip inserts target executable code into the executable file of functional component 2. The target executable code is used to indicate that verification is performed based on configuration file config1 before executing function 2. Function 2 calls interface 2 of the computer operating system.

[0081] To achieve configuration file-based verification, in this embodiment, configuration file config1 is loaded when any executable file containing a functional component including a target function is loaded. The timing of this loading can be implemented in various ways, such as loading configuration file config1 synchronously when inserting the target executable code in step 602, loading configuration file config1 after inserting the target executable code, loading configuration file config1 when functional component 1 is loaded, or loading configuration file config1 when all functional components are loaded. These implementations are all executed between running functional components, ensuring that when an access instruction from any functional component is received, verification can be performed based on the already loaded configuration file config1 without an additional loading process, thus guaranteeing the stability and timeliness of the security mechanism. Alternatively, configuration file config1 can be loaded when the management chip starts up, pre-loading the configuration file, which also ensures the stability and timeliness of the security mechanism.

[0082] In other embodiments, the configuration file is loaded only when the target function is executed, i.e., when a call to a preset interface occurs. This avoids putting pressure on the management chip. Specifically, step 602 includes executing the target function when any functional component's executable file reaches the target function, running the target executable code to load the first configuration file and perform verification based on it. In this case, there is no need to repeatedly load the configuration file; verification can be performed directly based on the already loaded functional component.

[0083] Step 604: The management chip receives access instruction 1 for functional component 1. Access instruction 1 instructs to call interface 1 of functional component 3 and run the target executable code located before function 1 to verify access instruction 1 based on configuration file config1. If the verification passes, function 1 is executed; if the verification fails, function 1 is not executed.

[0084] In some embodiments, the verification process includes: verifying the input parameters of access command 1 based on the input parameters allowed by interface 1. If the input parameters of access command 1 meet the requirements of the input parameters allowed by interface 1, the verification passes; otherwise, the verification fails. For example, for interface 1, if the allowed input parameter is file FileA, then if the input parameter of access command 1 is file FileB, the verification fails; if the input parameter of access command 1 is file FileA, the verification passes. It is understood that the allowed input parameters of the interface may include at least one parameter. The aforementioned failure means that if any input parameter of the access command does not meet the requirements of the allowed input parameters of the interface, then the input parameter of the access command does not meet the requirements of the allowed input parameters of the interface. In other embodiments, the verification process includes: verifying the input parameters of access command 1 based on the input parameters not allowed by interface 1. If the input parameters of access command 1 meet the requirements of the input parameters not allowed by interface 1, the verification fails; otherwise, the verification passes. The above verification conditions can be set based on the actual business situation set by the developers, and this application embodiment does not limit this.

[0085] Step 604 describes a scenario where one functional component calls another to perform a certain function. Suppose access instruction 1 is used to delete a file. Current security mechanisms typically restrict functional component 1's access permissions to that file, making it impossible to intercept such indirect calls. This allows functional component 1 to delete the file through the interface of another functional component 3. The security protection mechanism provided in this application determines security based on the allowed access scope of the interface. In the above steps, target executable code is inserted before function 1. When function 1 is executed, the target executable code first verifies the object actually accessed by access instruction 1 based on configuration file config1. If access instruction 1 attempts to access a specific file through interface 1, and that specific file is not allowed by the interface, then access instruction 1 is not responded to, meaning function 1 is not executed. By setting the interface of the functional component to a preset interface, it is possible to set which system resources are allowed and disallowed from the perspective of risky interfaces, regardless of the issuer of the access instruction. This avoids security vulnerabilities caused by indirect calls and thus protects system resources.

[0086] Step 605: The management chip receives access instruction 2 for functional component 2. The access instruction 2 instructs the call interface 2 to run the target executable code located before function 2 to verify the access instruction 2 based on the configuration file config1. If the verification passes, function 2 is executed; if the verification fails, function 2 is not executed.

[0087] In some embodiments, the verification process includes verifying the input parameters of the access command 2 based on the input parameters allowed by interface 2. If the input parameters of the access command 2 meet the input parameter requirements allowed by interface 2, the verification passes; otherwise, the verification fails.

[0088] Step 605 describes a scenario where a functional component calls the operating system's interface to perform a certain function. By setting the interface provided by the computer device's operating system as a preset interface, it is possible to set which system resources are allowed to be accessed and which are not allowed to be accessed from the perspective of the operating system's risk interface, thereby achieving the protection of system resources.

[0089] Additionally, it should be noted that during the loading process described above, the executable file of functional component 3 was not dynamically instrumented. That is, functional component 3 does not involve calling the preset interface (i.e., the risk interface). Therefore, the above verification process was not involved when accessing instruction 3 for functional component 3.

[0090] In some embodiments, the aforementioned dynamic instrumentation and verification process is implemented using a software development kit (SDK) or a functional component. That is, when the management chip loads the executable file of the functional component, the SDK is launched to perform dynamic instrumentation and subsequent verification. Alternatively, when the management chip loads the executable file of the functional component, the corresponding functional component on the management chip is launched to perform dynamic instrumentation and subsequent verification. This implementation is merely an example, and the embodiments of this application do not limit the scope of the application.

[0091] In the above, as Figure 5 and Figure 6 In the illustrated embodiment, security protection based on the first configuration file is used as an example for explanation. In another embodiment, the security protection mechanism can be further improved by restricting the interfaces accessible by the access command. That is, when the management chip starts up, a second configuration file can be loaded to restrict the range of system resources that can be accessed. Thus, during the operation of the functional components, the access command is verified from another dimension to verify whether the system resource to be accessed by the access command belongs to the range of system resources that can be accessed. If it belongs to the range of system resources that can be accessed, further verification is performed based on whether the interface called by the access command is a preset interface. If it does not belong to the range of system resources that can be accessed, it means that the access command is risky, and the access command is ignored or rejected, thereby avoiding security vulnerabilities.

[0092] The second configuration file is used to restrict the scope of allowed access to system resources from multiple different dimensions, thereby limiting the security permissions of functional components and reducing the impact of security vulnerabilities. For example, the second configuration file restricts the scope of allowed access to system resources from one or more combinations of the following dimensions, including but not limited to directories, files, system commands, processes and process-related resources, network resources, and system hardware resources.

[0093] I. File and directory isolation refers to setting access permissions for files and directories, such as read, write, and execute permissions, to determine which users or processes can perform corresponding operations. Correspondingly, the second configuration file configures the relationship between access permissions and directories or files, used to verify whether access commands access directories and files within the allowed scope. For example, if the second configuration file sets read permissions for a certain directory for users of class A, then for access commands from non-class A users, by detecting the access command and determining that the non-class A user does not have read permissions, the access command will be denied execution. This user-level file and directory isolation ensures file privacy and security.

[0094] II. System command control refers to a mechanism for managing, restricting, monitoring, and scheduling various executable commands in an operating system. Through this mechanism, system administrators or relevant security policies can determine which commands can be executed, by whom, and under what conditions, thereby ensuring system security, stability, and compliance with relevant operating procedures. Correspondingly, the second configuration file configures the relationship between access permissions and system commands, used to verify whether an access instruction accesses a system command within the permitted scope. For example, if a command is not executable according to the second configuration file, then if an access instruction is received that attempts to access a non-executable command as indicated in the configuration file, the access instruction will be rejected. This restriction based on commands or command initiators ensures the security of the operating system. System command control can also involve dividing users into different user groups, each with a corresponding permission level. Different permission levels have different access permissions for system commands. For example, a user group may have the highest permissions, applicable to all system commands; therefore, access instructions from this user group will be responded to. Conversely, a particular user group may only have permissions for system commands with specific access permissions, meaning it can only execute system commands within its permission scope to prevent unauthorized operations. It should be noted that the above is only an example to introduce the mechanism of system command control. This control mechanism can also be implemented in other forms, and the embodiments of this application do not limit it.

[0095] Third, process identifier (PID) isolation is a mechanism used to distinguish and restrict the mutual influence between different processes, ensuring the relative independence of the process's runtime environment. Accordingly, the second configuration file contains a list of processes within the allowed scope, as well as inter-process communication methods and sessions, used to verify whether access instructions access processes within the allowed scope. This isolates processes from each other, preventing them from directly accessing system resources such as the memory space of another process. For example, if the second configuration file allows access for process B, then when an access instruction is used to call process B, the access instruction will be responded to.

[0096] IV. Memory and CPU Limits: These limits restrict the system resources, such as CPU and memory, that access instructions are allowed to access. Accordingly, the second configuration file specifies the allowed range of CPU and memory addresses to verify whether an access instruction accesses system resources within that range. For example, if the second configuration file specifies allowed CPU and memory addresses, then if the memory address accessed by the instruction is outside the allowed range specified in the second configuration file, the access instruction will be rejected.

[0097] Fifth, network isolation is a network isolation mechanism. Accordingly, the second configuration file specifies the allowed network and hostname range to restrict the networks and hosts accessed by access commands. If the network accessed by the command is not within the allowed range of the second configuration file, the access command will be denied.

[0098] VI. Inter-process communication (IPC) control refers to a series of mechanisms and measures for managing, restricting, and regulating communication activities between different processes in an operating system, such as exchanging information, sharing data, and coordinating work. Accordingly, the second configuration file controls access permissions to pipes between processes, specifying which processes can perform operations, thus ensuring the security and privacy of communication. If the process executing the access command is not within the allowed process range, the access command will be refused.

[0099] VII. Unix Time-Sharing System (UTS) isolation refers to a combination of isolation mechanisms implemented in the operating system through the application of UTS namespace-related characteristics. The UTS namespace primarily involves the isolation of hostnames and domain names, ensuring that different process groups or container runtime environments are independent of each other in terms of UTS-related attributes. This guarantees that runtime environments do not interfere with each other and each has its own specific UTS identifier. Correspondingly, the second configuration file configures the allowed hostnames and domain names to restrict the system resources that access commands can access.

[0100] The above seven mechanisms are merely illustrative examples of security protection mechanisms implemented based on the second configuration file. For the second configuration file, multiple dimensions of verification can be configured to identify whether an access command is a normal business behavior. If any dimension of verification fails, the access command is not allowed or refused to be executed. If each dimension of verification passes for the access command, the access command can be further verified based on the interface called by the access command, thereby improving the security mechanism and providing security protection for the operation of computer devices.

[0101] Below, in conjunction with Figure 7 and Figure 8 The security protection process based on the first configuration file and the second configuration file described above is illustrated by example. Figure 7 An exemplary implementation environment for the management chip is provided, taking the management chip including functional component 4 as an example. Functional component 4 is an open source component. The executable file of functional component 4 includes function 4, which calls interface 4 to perform the corresponding function. Figure 8 This is an exemplary flowchart of the security protection method based on functional components, which includes the following steps.

[0102] Step 801: When the management chip starts up, it loads the configuration file config2.

[0103] The management chip loads configuration file config2, which is the second configuration file provided in this embodiment, at startup. This second configuration file indicates the range of system resources that are allowed to be accessed.

[0104] Step 802: The management chip loads the executable file of functional component 4 and inserts target executable code into the executable file of functional component 4. This target executable code is used to instruct the loading of configuration file config1 before executing function 4, and function 4 calls interface 4.

[0105] After startup, the management chip loads the functional component, specifically the executable file of functional component 4. In this embodiment, only one functional component is used as an example. For the management chip, the loading of its functional component can occur after startup or based on access instructions; this embodiment does not limit this. Furthermore, in this embodiment, functional component 4 is an open-source component. However, in some embodiments, for non-open-source functional components, the configuration file config2 can also be used for security protection, thereby achieving more comprehensive security protection on top of existing security mechanisms.

[0106] Step 803: The management chip receives access instruction 4 for functional component 4 and verifies the access instruction 4 based on the loaded configuration file config2.

[0107] In another embodiment, if the verification passes, step 804 is executed; if the verification fails, the response to access command 4 is rejected. For example, the directory accessed by access command 4 is verified. If the configuration file config2 indicates that access command 4 does not have access permissions to that directory, the response to access command 4 is rejected.

[0108] The verification can include multiple dimensions of verification as described in the above embodiments. The essence of the verification is to restrict the interfaces that the access command can access. That is, the settings of the configuration file config2 are used to restrict which interfaces can be accessed, thereby enabling access to system resources.

[0109] Step 804: If the access command 4 passes the verification based on the configuration file config2 and the access command 4 calls interface 4, the target executable code located before function 4 is executed to verify the access command 4 based on the configuration file config1. If the verification passes, the access command 4 is responded to; if the verification fails, function 4 is not executed.

[0110] The verification process is described in the above embodiment. For access commands, the first layer of security protection mechanism can determine whether the interface accessed by the access command is an allowed interface. After passing the verification of the first layer of security protection mechanism, a second layer of security protection mechanism is further provided, which is to restrict the system resources that are allowed to be accessed through the interface, to determine whether the system resources that the access command wants to access through this interface are allowed system resources. Thus, multiple verification dimensions are combined to achieve more refined security protection.

[0111] In some embodiments, the above-mentioned verification based on the first configuration file and the second configuration file is implemented through the SDK or functional components. For example, when the management chip starts, the SDK is started to load the second configuration file, and the SDK is used to perform dynamic instrumentation and subsequent verification processes when the management chip loads the executable file of the functional components. This application embodiment does not limit this.

[0112] This application also provides a security protection device based on functional components, which can be configured on a management chip running a first functional component. For example... Figure 9 As shown, Figure 9 This is a schematic diagram of the structure of a security protection device based on functional components provided in an embodiment of this application. For example... Figure 9 As shown, the device includes a receiving module 901 and a verification module 902.

[0113] Receiver module 901 is used to receive a first access instruction for a first functional component on the management chip;

[0114] The verification module 902 is used to verify the first access instruction based on the first configuration file if the first access instruction calls the preset interface. The first configuration file indicates the access range allowed by the preset interface. If the verification passes, the module responds to the first access instruction.

[0115] The receiving module 901 is also configured to receive a second access instruction to the first functional component;

[0116] The verification module 902 is also used to verify the second access command based on the first configuration file if the second access command calls the preset interface. If the verification fails, no response is given to the second access command.

[0117] In some embodiments, the first configuration file includes preset input parameters allowed by the interface.

[0118] The verification module 902 is used to verify the input parameters of the first access command based on the input parameters allowed by the preset interface.

[0119] The verification module 902 is also used to verify the input parameters of the second access command based on the input parameters allowed by the preset interface.

[0120] In some embodiments, the first configuration file includes input parameters that are not allowed by a preset interface.

[0121] The verification module 902 is used to verify the input parameters of the first access command based on input parameters that are not allowed by the preset interface.

[0122] The verification module 902 is also used to verify the input parameters of the second access command based on input parameters that are not allowed by the preset interface.

[0123] In some embodiments, the apparatus further includes:

[0124] An instrumentation module is used to insert target executable code into the executable file of the first functional component in response to loading the executable file of the first functional component. The executable code of the first functional component includes a target function. The target executable code is used to indicate that verification is performed based on a first configuration file before executing the target function. The target function is used to call a preset interface.

[0125] The verification module 902 is used to run the target executable code if the executable file of the first functional component executes to the target function, so as to perform verification based on the first configuration file.

[0126] In some embodiments, the apparatus further includes a loading module for performing any of the following:

[0127] When loading the executable file of the first functional component, the first configuration file is loaded; or, if the executable file of the first functional component executes to the target function, the target executable code is run to load the first configuration file and perform verification based on the first configuration file.

[0128] In some embodiments, the preset interfaces include: an interface for managing the operating system on the chip, an interface for managing the second functional components running on the chip, and an interface managed by the chip.

[0129] In some embodiments, the receiving module 901 is further configured to receive a third access instruction to the first functional component;

[0130] The verification module 902 is also used to verify the third access instruction based on the second configuration file, which indicates the range of system resources that are allowed to be accessed;

[0131] The verification module 902 is also used to verify the third access instruction based on the first configuration file if the verification of the third access instruction based on the second configuration file passes and the third access instruction calls the preset interface, and to respond to the third access instruction if the verification passes.

[0132] In some embodiments, the receiving module 901 is further configured to receive a fourth access instruction to the first functional component;

[0133] The verification module 902 is also used to verify the fourth access command based on the second configuration file. If the verification fails, it responds to the fourth access command.

[0134] In some embodiments, the verification module 902 is configured to perform any one or a combination of the following verifications:

[0135] Verify that the access command has access permissions to the corresponding directory; verify that the access command has access permissions to the corresponding file; verify that the access command has the permission to call the corresponding system command; verify that the access command has access permissions to the corresponding process; verify that the access command has access permissions to the resources related to the corresponding process; verify that the access command has access permissions to the corresponding network resources; verify that the access command has access permissions to the corresponding system hardware resources.

[0136] In some embodiments, the above-described component-based security protection device is also used to collaboratively implement other steps executed by the management chip in the foregoing embodiments. It should be understood that the device provided in the above embodiments, when performing component-based security protection, is only illustrated by the division of the above-described functional units. In practical applications, the above functions can be assigned to different functional units as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the component-based security protection device and the component-based security protection method embodiments provided in the above embodiments belong to the same concept; their specific implementation process is detailed in the method embodiments and will not be repeated here.

[0137] This application provides a computer-readable storage medium for storing at least one piece of program code, which is used to implement the above-described security protection method based on functional components.

[0138] This application provides a computer program product for implementing the above-described security protection method based on functional components.

[0139] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items that have substantially the same function and purpose. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor does it limit the quantity or execution order. It should also be understood that although the following description uses the terms "first," "second," etc., to describe various elements, these elements should not be limited by the terms. These terms are merely used to distinguish one element from another. For example, without departing from the various examples described, a first key can be referred to as a second key, and similarly, a second key can be referred to as a first key. Both the first key and the second key can be keys, and in some cases, they can be separate and different keys.

[0140] In this application, the term "at least one" means one or more, and the term "multiple" means two or more. For example, multiple keys means two or more keys.

[0141] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0142] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, in the form of program structure information. This program structure information includes one or more program instructions. When these program instructions are loaded and executed on a computing device, the processes or functions according to the embodiments of this application are generated, in whole or in part.

[0143] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0144] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A security protection method based on functional components, applied to a management chip, wherein the management chip has a first functional component running on it, characterized in that, The method includes: Receive a first access instruction for a first functional component on the management chip; If the first access instruction calls a preset interface, the first access instruction is verified based on the first configuration file, which indicates the access range allowed by the preset interface. If the verification passes, the first access instruction is responded to. Receive a second access instruction to the first functional component; If the second access instruction calls the preset interface, the second access instruction is verified based on the first configuration file. If the verification fails, no response is given to the second access instruction.

2. The method according to claim 1, characterized in that, The first configuration file includes the input parameters allowed by the preset interface. The step of verifying the first access command based on the first configuration file includes: Based on the input parameters allowed by the preset interface, the input parameters of the first access command are validated; Verification of the second access command based on the first configuration file includes: The input parameters of the second access command are validated based on the input parameters allowed by the preset interface.

3. The method according to claim 1, characterized in that, The first configuration file includes input parameters that are not allowed by the preset interface. The step of verifying the first access command based on the first configuration file includes: Based on the input parameters that are not allowed by the preset interface, the input parameters of the first access command are validated. Verification of the second access command based on the first configuration file includes: The input parameters of the second access command are validated based on the input parameters that are not allowed by the preset interface.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: In response to loading the executable file of the first functional component, target executable code is inserted into the executable file of the first functional component. The executable code of the first functional component includes a target function. The target executable code is used to indicate that verification is performed based on the first configuration file before executing the target function. The target function is used to call the preset interface. The method further includes: If the executable file of the first functional component executes to the target function, the target executable code is run to perform verification based on the first configuration file.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes any of the following: When loading the executable file of the first functional component, the first configuration file is loaded; or, if the executable file of the first functional component executes to the target function, the target executable code is run to load the first configuration file and perform verification based on the first configuration file.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Receive a third access instruction for the first functional component; The third access instruction is verified based on the second configuration file, which indicates the range of system resources that are allowed to be accessed. If the third access instruction passes the verification based on the second configuration file and the third access instruction calls a preset interface, the third access instruction is verified based on the first configuration file. If the verification passes, a response is given to the third access instruction.

7. The method according to claim 6, characterized in that, The method further includes: Receive a fourth access instruction for the first functional component; Based on the second configuration file, the fourth access command is verified. If the verification fails, a response is given to the fourth access command.

8. The method according to claim 6 or 7, characterized in that, The verification based on the second configuration file includes one or more of the following verifications: Verify whether the access command has access permissions to the corresponding directory; Verify whether the access command has the corresponding file access permission; Verify whether the access command has the authority to call the corresponding system command; Verify whether the access command has the access permission of the corresponding process; Verify whether the access command has access permissions to the resources related to the corresponding process; Verify whether the access command has the corresponding network resource access permission; Verify whether the access command has the corresponding access permission for the system hardware resources.

9. The method according to any one of claims 1 to 8, characterized in that, The preset interfaces include: the interface of the operating system on the management chip, the interface of the second functional component running on the management chip, and the interface managed by the management chip.

10. A security protection device based on functional components, applied to a management chip, the management chip having a first functional component running on it, the device comprising: The receiving module is configured to receive a first access instruction for a first functional component on the management chip; The verification module is used to verify the first access instruction based on the first configuration file if the first access instruction calls the preset interface. The first configuration file indicates the access range allowed by the preset interface. If the verification passes, the module responds to the first access instruction. The receiving module is further configured to receive a second access instruction to the first functional component; The verification module is further configured to verify the second access instruction based on the first configuration file if the second access instruction calls the preset interface, and not respond to the second access instruction if the verification fails.

11. A management chip, characterized in that, The management chip includes a processing unit, a storage unit, and multiple interfaces. The multiple interfaces are used to communicate with external hardware components. The processing unit is used to implement the security protection method based on functional components as described in any one of claims 1 to 9.

12. A computer device, characterized in that, The computer device includes a processor, a memory, and a management chip. The processor is connected to the memory, and the processor and the memory are respectively connected to the management chip. The computer device is used to implement the security protection method based on functional components as described in any one of claims 1 to 9.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store at least one piece of program code, which is used to implement the security protection method based on functional components as described in any one of claims 1 to 9.

14. A computer program product, characterized in that, The computer program product is used to implement the security protection method based on functional components as described in any one of claims 1 to 9.

Images