Information processing method, apparatus and electronic device
By introducing a security system into electronic devices to verify the legitimacy of hardware access requests, the risk of malicious attacks caused by electronic devices passing through standard communication buses is resolved, bus isolation is achieved, and the security of the system and the security of hardware use are improved.
Patent Information
- Application Number
- CN202210294029.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-03-24
- Publication Date
- 2026-02-27
- Estimated Expiration
- 2042-03-24
AI Technical Summary
In the existing technology, the security devices of electronic devices communicate directly with the operating system through a standard communication bus, which makes the risk of malicious attacks unavoidable and increases the system complexity and cost in the hardware design.
Introducing a security system into electronic devices involves using preset hardware access verification rules to validate the legitimacy of hardware access requests from the operating system. This ensures that only legitimate requests are executed, achieving bus isolation and reducing the risk of attacks.
Without altering the hardware design, a secure system verifies hardware access requests, filters potential security risks, and improves system and hardware security.
Smart Images

Figure CN114611098B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application mainly relates to the field of secure hardware applications, and more particularly to an information processing method and device and electronic equipment. BACKGROUND
[0002] ARM (Advanced RISC Machines) is a 32-bit RISC (Reduced Instruction Set Computer) processor architecture, which is widely used in embedded systems. Due to its low power consumption and high processing efficiency, it has been applied to electronic devices such as mobile computers, multimedia players, computers, computer peripherals, etc., to meet the application requirements of electronic devices.
[0003] Among them, for some secure devices mounted on electronic devices (i.e., electronic devices with security use requirements), they are usually connected in communication with the standard communication bus (such as I2C, USB, etc.) of the electronic device. The operating system of the electronic device can directly access and process the data of the secure hardware through the bus driver, which cannot avoid the malicious attack risk brought by the secure device. SUMMARY
[0004] Therefore, the present application provides an information processing method for running in a secure system of an electronic device, which comprises:
[0005] Obtaining a hardware access request; the hardware access request is sent by an operating system of the electronic device;
[0006] Verifying the legality of the hardware access request based on a preset hardware access verification rule;
[0007] If the hardware access request is verified to be legal, executing the hardware access request;
[0008] Feeding back the execution result of the hardware access request to the operating system.
[0009] Optionally, the obtaining of the hardware access request comprises:
[0010] Starting a secure application running under the secure system of the electronic device;
[0011] Calling a secure driver in the secure system to receive a hardware access request forwarded by any hardware driver configured in the operating system.
[0012] Optionally, the verifying of the legality of the hardware access request based on the preset hardware access verification rule comprises:
[0013] based on the hardware access request or the hardware driver identifier, calling a preset hardware access verification rule matched with the hardware access request; the hardware driver identifier represents a hardware driver of the operating system forwarding the hardware access request to the security system;
[0014] based on the preset hardware access verification rule, obtaining to-be-verified information of the hardware access request; the to-be-verified information includes one or more combined information of a request content and a request attribute of the hardware access request, an object attribute of an access object generating the hardware access request in the operating system, driver configuration information of the hardware driver, and communication attribute information, hardware configuration information and access authorization information of an accessed hardware of the hardware access request;
[0015] verifying whether the to-be-verified information meets the preset hardware access verification rule.
[0016] Optionally, the method further comprises:
[0017] verifying that the hardware access request is illegal, rejecting to execute the hardware access request, and / or feeding back prompt information of hardware access failure to an access object; the access object refers to an object generating the hardware access request in the operating system;
[0018] and / or,
[0019] obtaining a hardware state;
[0020] based on the hardware state and the hardware driver configuration information, determining that, in each hardware driver configured in the operating system, there is a target hardware driver matched with any hardware assembled or accessed by the electronic device, and sending a control instruction for the target hardware driver to the operating system;
[0021] wherein, the control instruction is used to trigger the target hardware driver to display a corresponding driver calling interface to the operating system, so that the operating system can generate a hardware access request for a hardware matched with the target hardware driver based on the driver calling interface.
[0022] The application further provides an information processing method, which is used for running in an operating system of an electronic device, and comprises the following steps:
[0023] in response to a trigger signal of any hardware of the electronic device, generating a corresponding hardware access request;
[0024] sending the hardware access request to a security system of the electronic device for legality verification;
[0025] receiving an execution result of the hardware access request fed back by the security system;
[0026] The execution result of the hardware access request is that the security system verifies that the hardware access request is legal based on a preset hardware access verification rule, and the hardware access request is executed.
[0027] Optionally, the method further comprises:
[0028] Filtering the hardware access request based on a preset request filtering rule;
[0029] Determining that the hardware access request meets the preset request filtering rule, and sending the hardware access request to a security system of the electronic device for legality verification;
[0030] Determining that the hardware access request does not meet the preset request filtering rule, and rejecting to send the hardware access request to the security system, and / or feeding back an interception prompt information to an access object; the access object refers to an object in the operating system that generates the hardware access request, and the interception prompt information is used to indicate the content that the hardware access request does not meet the preset request filtering rule.
[0031] Optionally, the filtering the hardware access request based on the preset request filtering rule comprises:
[0032] Based on the hardware access request, obtaining a request content and a request attribute of the hardware access request, and a hardware identifier of the accessed hardware;
[0033] Based on one or more combinations of the request content, the request attribute, and the hardware identifier, calling a matching preset request filtering rule;
[0034] Verifying the to-be-verified filtering information corresponding to the hardware access request according to the preset request filtering rule;
[0035] The verifying the to-be-verified filtering information corresponding to the hardware access request according to the preset request filtering rule comprises at least one of the following implementation manners:
[0036] Determining whether the request content meets a hardware access data integrity requirement;
[0037] Determining whether the object attribute meets a hardware access request format requirement;
[0038] Determining whether the device identifier matches a hardware driver that receives the hardware access request;
[0039] Calling access authorization information associated with the device identifier, and determining whether the access object has an access right of the accessed hardware according to the access authorization information.
[0040] The application further provides an information processing device for running in a security system of an electronic device, the device comprising:
[0041] a hardware access request obtaining module for obtaining a hardware access request, wherein the hardware access request is sent by an operating system of the electronic device;
[0042] a verification module for verifying the legality of the hardware access request based on preset hardware access verification rules;
[0043] a hardware access request executing module for verifying the legality of the hardware access request and executing the hardware access request;
[0044] an execution result feedback module for feeding back the execution result of the hardware access request to the operating system.
[0045] The application further provides an information processing device for running in an operating system of an electronic device, the device comprising:
[0046] a hardware access request generating module for generating a corresponding hardware access request in response to a trigger signal for any hardware of the electronic device;
[0047] a hardware access request sending module for sending the hardware access request to a security system of the electronic device for legality verification;
[0048] an execution result receiving module for receiving the execution result of the hardware access request fed back by the security system;
[0049] wherein the execution result of the hardware access request is obtained by verifying the legality of the hardware access request and executing the hardware access request based on preset hardware access verification rules.
[0050] The application further provides an electronic device, wherein the electronic device runs an operating system and a security system, and comprises:
[0051] a memory for storing a first program for implementing the information processing method of the security system and a second program for implementing the information processing method of the operating system;
[0052] a first processor for loading and executing the first program, running in the security system and implementing the information processing method of the security system;
[0053] a second processor for loading and executing the second program, running in the operating system and implementing the information processing method of the operating system.
[0054] It can be seen that the information processing method, device and electronic equipment provided by the application generate a hardware access request for the operating system of the electronic equipment, and first send the hardware access request to the security system running on the electronic equipment. The security system verifies the legality of the hardware access request based on a preset hardware access verification rule. After verification, the security system executes the hardware access request, and feeds back the execution result to the operating system. Compared with the information processing method in which the operating system directly executes any hardware access request generated by the operating system, the processing method proposed in the application sends the hardware access request to the security system for security verification, and then determines whether to execute the hardware access request, so as to achieve the effect of bus isolation, filter potential security risks and attacks, and improve the security of the system without the need to redesign the hardware system. BRIEF DESCRIPTION OF DRAWINGS
[0055] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the drawings needed to be used in the embodiments or the prior art description will be briefly introduced. Obviously, the drawings in the following description are only embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of the provided drawings.
[0056] Figure 1 A hardware structure diagram of an optional example of an electronic device suitable for the information processing method proposed in the application;
[0057] Figure 2 A structure diagram of an optional example of an electronic device suitable for the information processing method proposed in the application;
[0058] Figure 3 A flow diagram of an optional example of the information processing method proposed in the application;
[0059] Figure 4 A flow diagram of another optional example of the information processing method proposed in the application;
[0060] Figure 5 A signaling flow diagram of another optional example of the information processing method proposed in the application;
[0061] Figure 6 A flow diagram of another optional example of the information processing method proposed in the application;
[0062] Figure 7 A flow diagram of another optional example of the information processing method proposed in the application;
[0063] Figure 8 A structure diagram of an optional example of the information processing device proposed in the application;
[0064] Figure 9 Structure diagram of another optional example of the information processing device proposed in the present application;
[0065] Figure 10 Structure diagram of another optional example of the information processing device proposed in the present application. DETAILED DESCRIPTION
[0066] For the description in the background section, in order to improve the security of the hardware equipped or accessed by the electronic device, and reduce the risk of malicious attacks in the process of using the hardware through the standard bus such as I2C and USB, a private bus is proposed for the hardware design to avoid, but this will increase the complexity of the system design of the electronic device, and increase the hardware overhead and cost.
[0067] In order to further improve the above problems, the present application disconnects the communication connection between the general driver (such as the above-mentioned I2C, USB, etc.) of the standard bus used by the operating system and the hardware layer, so that the hardware driver of the operating system determines the hardware that the operating system can access through the security system running on the electronic device, that is, the security system verifies the legality of the hardware access request according to the preset hardware access verification rule configured by the security system, and executes the hardware access request after verifying that the hardware access request is legal. In this way, it can avoid executing illegal hardware access requests, that is, filtering potential security risks and attacks, and ensuring the security of hardware use.
[0068] The technical solutions in the embodiments of the present application will be described clearly and completely in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.
[0069] Reference Figure 1 The hardware structure diagram of an optional example of the electronic device suitable for the information processing method proposed in the present application can include but is not limited to smart phones, tablet computers, wearable devices, augmented reality (AR) devices, virtual reality (VR) devices, vehicle-mounted devices, robots, smart medical devices, smart traffic devices, desktop computers and other terminals; It can also include servers such as physical servers and / or cloud servers supporting cloud computing technology, etc. The type of electronic device used can be determined according to the scene requirements, including but not limited to the electronic device product types listed in the present embodiment.
[0070] In order to implement the information processing method proposed in the present application, such as Figure 1As shown, the electronic device provided in the present application can run an operating system and a security system, and the electronic device can include at least one memory 11, a first processor 12 and a second processor 13, wherein:
[0071] The memory 11 can be used to store a first program for implementing the information processing method executed by the security system and a second program for implementing the information processing method executed by the operating system. The first processor 12 can load the first program and run on the security system to implement the information processing method executed by the security system. The second processor 13 can load the second program and run on the operating system to implement the information processing method executed by the operating system. The implementation process can refer to the implementation process described in the corresponding side of the method embodiments below, and the embodiments of the present application will not be described in detail here.
[0072] In the embodiments of the present application, the memory 11 can include a high-speed random access memory and can also include a non-volatile memory, such as at least one magnetic disk storage device or other volatile solid-state storage device. The first processor 12 can include an ARM (Advanced RISC Machine) processor and the like, which can support the running of the security system; and the second processor 13 can be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a digital signal processor (DSP), a dedicated integrated circuit (ASIC), a ready-to-program gate array (FPGA) or other programmable logic device, and the like. The structure and model of the above-mentioned memory 11, first processor 12 and second processor 13 are not limited in the present application, and can be flexibly adjusted according to actual needs.
[0073] In some embodiments, for the security system running on the electronic device, it can be implemented by the ARM TrustZone architecture support, which can build a security architecture for consumer electronic devices to resist various possible attacks, such as external hanging hardware security processing of the electronic device, and security processing of the integrated hardware inside the electronic device, etc. Among them, the TrustZone architecture can conceptually divide the hardware resources and software resources of the SoC (System on Chip) of the electronic device into two worlds of secure (Secure World) and non-secure (Normal World), and the secure world can constitute the security system of the application, and the non-secure world can constitute the operating system of the electronic device. From the processing architecture, as described above, the first processor and the second processor under the TrustZone architecture run the instruction code of the corresponding system to implement the information processing method proposed in the application. The structure and operation principle of the TrustZone architecture are not described in detail in the application.
[0074] It should be noted that for the security system architecture of the electronic device running the information processing method of the application, it includes but is not limited to the Secure World under the ARM TrustZone architecture described above, and can be configured according to the security processing requirements of the application. The application does not make detailed examples.
[0075] In addition, in actual application, the electronic device can also include a hardware layer composed of various hardware, such as various sensors, at least one communication module, power supply, power management module, antenna and other integrated hardware assembled inside the electronic device, and various external storage devices (such as U disk, etc.), external display devices, various external service processing devices and other external hardware, which can be configured and adjusted according to the business requirements, and the application does not limit this.
[0076] Based on the above analysis, referring to Figure 2The architecture diagram of another optional example of the electronic device implementing the information processing method provided in the present application is shown. According to different security management requirements of the hardware layer, the present application can configure corresponding hardware drivers for different categories of hardware, and in the security system configured in the electronic device, configure a security application and a security driver (i.e., a bus driver) for implementing the security verification in the information processing method provided in the present application, so that each hardware driver in the operating system can communicate with the hardware layer through the security driver. In this way, the hardware access request sent by each application program in the operating system to the hardware driver will be forwarded to the security driver of the security system for legality verification. After verification, the security application executes the hardware access request to implement access processing on the corresponding hardware. Conversely, the hardware driver feeds back the prompt information of rejecting or ignoring the hardware access request to the request sender, implements security isolation of the general-purpose bus, and reduces the risk of illegal attacks on the hardware.
[0077] In the hardware access processing, the operating system usually needs to obtain a hardware calling interface, i.e., a driver calling interface exposed by the hardware driver configured for the hardware, and then the access processing on the hardware can be implemented. If the electronic device does not configure a hardware driver for a certain hardware or a category of hardware, the electronic device cannot detect the hardware when the hardware is externally connected, and thus cannot perform access processing on the hardware. Therefore, the present application can flexibly implement configuration management of the hardware driver according to the hardware business processing requirement, and the configuration implementation method of the hardware driver is not described in detail in the present application. As analyzed above, each hardware driver can correspond to one or more hardware, and based on the hardware access management requirement, the logic code of the corresponding hardware access filtering rule is configured in the hardware driver to implement filtering processing on the received hardware access request. The implementation process is not described in detail in the present application.
[0078] It can be seen that, compared with the access processing on any externally connected or integrated hardware based on the general-purpose driver, the hardware driver configured for the hardware in the present application enables the access processing on the hardware through the security driver of the security system, eliminates the access processing on the hardware without a special hardware driver and the verification of illegal hardware, achieves security isolation of the communication bus such as I2C, UART or USB, and improves the security of hardware use.
[0079] It should be understood that, Figure 1 The structure of the electronic device shown does not constitute a limitation on the computer device in the embodiments of the present application. In actual applications, the electronic device can include more components than those shown, or some components can be combined, which are not listed one by one in the present application. Figure 1 The structure of the electronic device shown does not constitute a limitation on the computer device in the embodiments of the present application. In actual applications, the electronic device can include more components than those shown, or some components can be combined, which are not listed one by one in the present application.
[0080] Reference Figure 3As shown in FIG. 1, the information processing method of an optional example of the present application can be executed by an electronic device. The present embodiment can describe the information processing method of the present application from the perspective of a security system running on the electronic device. The architecture of the security system can refer to, but is not limited to, the description of the corresponding part of the above embodiment. The present embodiment will not be described in detail here. Figure 3 As shown in FIG. 1, the information processing method executed by the security system can include, but is not limited to:
[0081] Step S31, obtaining a hardware access request;
[0082] According to the above description of the technical solutions of the present application, for any hardware equipped or accessed by the electronic device, the operating system can detect the hardware when the operating system is configured with the corresponding hardware driver. Thus, according to the actual business requirements, the hardware access request for the hardware can be generated, such as the application scenario in which any application in the application layer of the operating system needs to use the data of the hardware, or needs to process the data stored by the hardware, or needs to adjust the hardware configuration. The corresponding hardware access request can be generated to complete the business requirements in the application scenario.
[0083] As can be seen, the content of the hardware access request obtained by the electronic device is often different for different business requirements, which will not be enumerated one by one in the present embodiment. However, for each hardware access request, it is usually generated by the operating system of the electronic device and sent to the corresponding hardware driver. The communication mode between the access object of the hardware access request (such as each application program in the application layer, the operating system, etc.) and the hardware driver is not limited by the present application, and can be determined as appropriate.
[0084] Step S32, verifying the legality of the hardware access request based on a preset hardware access verification rule;
[0085] In the present embodiment, the preset hardware access verification rule can indicate which information related to the hardware access request is verified and how to verify these information, etc. The hardware access verification rule can be configured according to the communication security requirements of the corresponding hardware, the communication configuration information of the electronic device, or even combined with the communication requirements of different hardware access requests, etc. The logic code for implementing the hardware access verification rule can be obtained.
[0086] The preset hardware access verification rule can be universal and applicable to the legality verification of hardware access requests of various hardware. Alternatively, the preset hardware access verification rule can be configured in a targeted manner, that is, for different or different types of hardware or different hardware drivers, the corresponding preset hardware access verification rule can be configured and stored, and the correspondence between the two can be stored, so that the required hardware access verification rule can be called based on the correspondence. The configuration method, content, storage method, and the like of the preset hardware access verification rule are not limited in the present application and can be determined as appropriate.
[0087] In this way, after the security system of the electronic device obtains any hardware access request, the preset hardware access verification rule matched with the hardware access request can be called to determine the to-be-verified information of the hardware access request, so that the legality of the to-be-verified information is verified according to the preset hardware access verification rule, and whether the hardware access request is legal is determined. The implementation method of the legality verification is not limited in the present application.
[0088] It can be understood that the implementation process of step S32 can be different for different preset hardware access verification rules and different hardware access requests, which will not be exemplified and described in detail in the present application.
[0089] In step S33, it is verified that the hardware access request is legal, and the hardware access request is executed.
[0090] In step S34, the execution result of the hardware access request is fed back to the operating system.
[0091] After the legality verification, it is determined that the request object of the hardware access request can access the hardware to be accessed, and the security system can execute the obtained hardware access request, such as a security application in the security system, to access the corresponding hardware in the hardware layer of the electronic device, and the implementation process can be determined according to the request content of the hardware access request, which will not be described in detail in the present application.
[0092] After the security system executes the hardware access request, the execution result obtained, such as access data of the hardware to be accessed, response information of the successfully accessed hardware, processing result of the hardware to be accessed, and the like, can be fed back to the access object that initiates the hardware access request in the operating system, so that the access object can execute subsequent steps, such as data access processing of the hardware to be accessed, based on the execution result. The execution result of the hardware access request and the feedback implementation method thereof are not limited in the present application and can be determined as appropriate.
[0093] In summary, for the operating system of the electronic device to generate a hardware access request, the hardware access request is first sent to the security system running on the electronic device, and the security system verifies the legality of the hardware access request based on a preset hardware access verification rule. After verification, the security system will execute the hardware access request, and the execution result will be fed back to the operating system. Compared with the information processing mode in which the operating system directly executes any hardware access request generated by the operating system, the processing mode proposed in the present application sends the hardware access request to the security system for security verification, and then decides whether to execute it, which achieves the effect of bus isolation to filter potential security risks and attacks, and improves the security of the system without the need to redesign the hardware system.
[0094] Referring to Figure 4 For the flowchart of another optional example of the information processing method proposed in the present application, the present embodiment can still describe an optional detailed implementation method of the information processing method executed by the security system running on the electronic device, but is not limited to the detailed implementation method described in the present embodiment. As shown in Figure 4 The detailed implementation method can include:
[0095] Step S41, starting the security application under the security system of the electronic device;
[0096] Step S42, calling the security driver in the security system to receive the hardware access request forwarded by any hardware driver configured in the operating system;
[0097] In combination with the system architecture of the security system described in the above embodiments, the present embodiment takes the security system based on the ARM TrustZone architecture (i.e. the Trusted Execution Environment (TEE) of the Secure World under the TrustZone architecture) as an example for description. A dedicated hardware driver (such as an Inter-Process Communication (IPC) driver) can be developed and deployed to the REE (Rich Execution Environment) in the TrustZone, a dedicated security bus driver (i.e. the security driver of the present application) can be developed and deployed to the TEE in the TrustZone Solution, and a security application (Trusted Application) running in the security system and a Client Application running in the operating system can be developed to process the access processing requirements of the hardware in the hardware layer of the electronic device and filter any potential security risks and attacks.
[0098] In order to achieve the above-mentioned purpose, during the boot process and / or the running process after the boot of the electronic device, the security application under the security system can be started to run, so that it can call the security driver under the security system to execute the solution on the trusted operating system (Solution on Trusted OS). The configuration implementation method of the security driver is not limited in the present application.
[0099] Therefore, after the operating system generates any hardware access request (such as the corresponding hardware access request generated by the access object of the client application based on the business requirement, or the hardware access request generated by the access object of other non-client application of the operating system to request the start or shutdown of the microphone, camera and other hardware of the electronic device), it can be sent to the matching hardware driver. At this time, the hardware driver will not directly execute the hardware access request and directly access the accessed hardware, but will forward the hardware access request to the security driver of the security system, and the security driver will determine whether to execute the hardware access request, so as to achieve the bus isolation effect and reduce the risk of illegal attack on the hardware.
[0100] Among them, the communication connection mode between the hardware driver in the operating system and the security driver in the security system, and the control mode of the hardware driver sending the hardware access request to the security driver, etc. can be determined according to the communication control method of the system architecture of the electronic device, such as the communication control between the non-security world (i.e. the operating system of the present application, such as REE) and the security world (such as TEE) under the ARM TrustZone architecture, which can be realized by the monitoring module under the security world, etc. The embodiments of the present application will not be described in detail.
[0101] Step S43, based on the hardware access request or the hardware driver identifier, the matching preset hardware access verification rule is called;
[0102] In the actual application of the present application, in order to improve the security verification reliability, the corresponding hardware access verification rule can be pre-configured according to different hardware or hardware driver or hardware processing requirement. Therefore, if the corresponding relationship / matching relationship between different hardware drivers and different hardware access verification rules is pre-stored, when the security driver of the security system receives the hardware access request forwarded by any hardware driver, it can determine the hardware driver identifier of the hardware driver, according to the matching relationship, call the preset hardware access verification rule matched with the hardware driver identifier, that is, the hardware access verification rule configured for the hardware driver with the hardware driver identifier or the corresponding hardware. The content of the hardware driver identifier is not limited in the present application, which can be determined as appropriate.
[0103] Optionally, if the security system is personalized in configuring the hardware access verification rule for different types of hardware processing needs or hardware implementation during the process of configuring the hardware access verification rule, the corresponding matching relationship is generated. In this way, after the security system receives any hardware access request, the security system can analyze the request content of the hardware access request, determine the requested hardware processing needs or the hardware identifier of the accessed hardware, and then according to the pre-stored matching relationship, call the matching preset hardware access verification rule.
[0104] It should be noted that since there is a certain correspondence between the hardware equipped or accessed by the electronic device and the configured hardware driver, which can be determined during the hardware driver configuration, when calling the preset hardware access verification rule, the present application can also determine the hardware access verification rule to be called according to various information such as the accessed hardware identifier, hardware driver identifier, request content of the hardware access request, etc. The present application does not limit the configuration method and content of the preset hardware access verification rule, which can be flexibly adjusted according to business needs and is not limited to the implementation methods listed in the context.
[0105] Step S44, based on the preset hardware access verification rule, obtaining the to-be-verified information for the hardware access request;
[0106] Step S45, verifying whether the to-be-verified information meets the preset hardware access verification rule, if yes, going to step S46; if no, executing step S47;
[0107] Step S46, executing the hardware access request, and feeding back the hardware access request execution result to the operating system;
[0108] Step S47, rejecting to execute the hardware access request.
[0109] In the foregoing description of the hardware access verification rule, for different content of the hardware access verification rule, the content to be verified and its verification rule are often different, therefore, after the security system calls the preset hardware access verification rule for legality verification of the hardware access request, the corresponding to-be-verified information can be determined, such as one or more combination information of the request content and request attribute (such as request type, request data packet format / packing format, etc.) of the hardware access request, the object attribute (such as object category / identifier, etc.) of the access object in the operating system generating the hardware access request, the driver configuration information of the hardware driver, and the communication attribute information, hardware configuration information and access authorization information of the accessed hardware of the hardware access request. The present application does not limit the content of the to-be-verified information, which can be determined as appropriate.
[0110] The drive configuration information of the hardware driver can include the hardware category / identification that the hardware driver can drive, the working parameters of the hardware driver, the interface parameters of the externally displayed drive calling interface, and the like. The communication attribute information of the accessed hardware can include the interface identification of the communication interface of the accessed hardware and the supported communication protocol, and the like. The hardware configuration information can include the hardware ID and the like of the accessed hardware, and the hardware working parameters and the like. The access authorization information can include the permission information for verifying whether the accessed hardware has access permission, such as a preset password and the like. The content of the above-mentioned various to-be-verified information is not limited in the present application, including but not limited to the information content listed above.
[0111] Then, the obtained to-be-verified information can be verified according to the preset hardware access verification rule, that is, whether the to-be-verified information meets the legal requirements indicated by the preset hardware access verification rule is determined. If yes, it is determined that the hardware access request obtained by the security system is legal, and the hardware access request can be continued to be executed. Otherwise, it is considered that the hardware access request is illegal and can threaten the use safety of the accessed hardware, and the hardware access request can be directly rejected to be executed. Compared with the processing mode that the general driver directly executes all received hardware access requests, the communication bus isolation is achieved and the system safety is improved without changing the system hardware design in the present application.
[0112] It can be understood that the verification process of the above-mentioned step S45 can be adjusted correspondingly for different contents of the to-be-verified information, such as whether the request format / packaging format of the hardware access request meets the corresponding preset format requirements, whether the request content of the hardware access request is complete based on the request content integrity requirement, whether the accessed object initiating the hardware access request belongs to the corresponding access object white list based on the access object white list for different hardware configurations, whether the hardware ID contained in the hardware access request is consistent with the hardware ID of the accessed hardware, and the like, which can be determined according to business requirements, and the embodiments of the present application will not be listed here.
[0113] In some embodiments of the present application, according to the legality verification method described above, when the security system verifies that the received hardware access request is illegal, the access object (that is, the object in the operating system generating the hardware access request) can be fed back the prompt information of the hardware access failure to notify the access object that the access request of the accessed hardware fails, so that the user can perform subsequent operations according to the prompt information output by the operating system. The prompt information can include the legality verification result of the hardware access failure, the reason causing the hardware access failure, the adjustment measures, and the like, and the content of the prompt information and the feedback output mode thereof are not limited in the present application and can be determined as required.
[0114] Reference Figure 5Fig. 2 is a signaling flow diagram of another optional example of the information processing method proposed in the present application, which can be executed by an electronic device, as shown in Fig. 1, and the method can include the following steps: Figure 5 As shown in Fig. 2, the method can include the following steps:
[0115] In step S51, the security system acquires the hardware state.
[0116] In combination with the above description of the security system and the operating system of the electronic device, in order to realize bus isolation, the hardware driver corresponding to each hardware configuration is utilized, and the security driver of the security system is utilized to realize the isolation of the hardware driver of the operating system. Therefore, in the scenario where the electronic device accesses hardware, such as an external U disk, a terminal, and other security devices, the security system can detect the state of the communication interface of the hardware access to determine whether the communication interface is accessed by hardware and determine the hardware access state. Similarly, when the hardware is disconnected from the electronic device, the state of the communication interface detected can be used to determine the hardware port connection state.
[0117] For the hardware integrated by the electronic device, the configuration data of the electronic device can be used to determine the hardware integrated by the electronic device, and the output / input operating parameters of the hardware, such as operating voltage and operating current, can be detected to determine the hardware state, such as whether the hardware operates normally. The method for acquiring the hardware state of the hardware integrated or connected to the electronic device is not limited in the present application and can be determined as appropriate.
[0118] In step S52, the security system determines, based on the hardware state and the hardware driver configuration information, that there is a target hardware driver matching any hardware assembled or accessed by the electronic device among the hardware drivers configured in the operating system, and generates a control instruction for the target hardware driver.
[0119] In step S53, the security system sends the control instruction to the operating system.
[0120] In the embodiment of the present application, the hardware driver configuration information can include the correspondence between different hardware drivers and different hardware. After the hardware accessed by the electronic device or the hardware integrated by the electronic device is determined based on the acquired hardware state, in order to enable subsequent access processing of the hardware, the corresponding hardware driver needs to be triggered to work. Therefore, the security system can query whether there is a target hardware driver matching the determined hardware from the hardware drivers configured in the operating system, and if there is, the security system can send a control instruction for the target hardware driver to the operating system. Otherwise, the operating system of the electronic device will not know the hardware and will not be able to access the hardware.
[0121] Based on this, for the hardware newly accessed (such as external or internal integrated access mode) by the electronic device, the electronic device needs to be configured with a matching hardware driver, and then the hardware can be used. Therefore, in some embodiments, when it is determined that the target hardware driver is not currently configured in the operating system of the electronic device according to the detection method described above, a configuration prompt information for the target hardware driver can be output to remind the user of the electronic device to configure the target hardware driver first, and then access the required hardware for processing. The content of the configuration prompt information and its output method, and the configuration implementation method of the target hardware driver are not described in detail.
[0122] In step S54, the operating system triggers the target hardware driver to display the corresponding driver calling interface to the operating system in response to the control instruction.
[0123] In step S55, the operating system generates a hardware access request for the hardware matched with the target hardware driver based on the driver calling interface.
[0124] In the case where it is determined that the target hardware driver is configured in the operating system of the electronic device, the target hardware driver can be triggered to externally display its driver calling interface, so that the operating system can call the driver calling interface to trigger the hardware driver to forward the hardware access request for the hardware matched with the target hardware driver to the security system for legality verification. The verification process can refer to the description of the corresponding part of the above embodiment, and the present embodiment will not be described in detail.
[0125] In summary, compared with the current configuration of the general bus driver in the operating system, so that any client application in the operating system can access and process any hardware in the hardware layer through the general bus driver, the present embodiment proposes to delete the general bus driver and configure a dedicated hardware driver, such as an IPC driver, for different hardware, so that the operating system can initiate a hardware access request for the hardware with a matching hardware driver, and the hardware access request needs to be sent to the security driver in the security system through the matching hardware driver for legality verification, and only based on the verification result, it is determined whether to perform access processing on the corresponding hardware, so as to achieve the security isolation of the general bus, and reduce the risk of illegal attack on the hardware.
[0126] In some other embodiments of the present application, the filtering processing method of the hardware access request can also be implemented by the security system, that is, after the security system receives the hardware access request forwarded by the hardware driver, it first filters the received hardware access request according to the preset request filtering rule, and then performs legality verification on the hardware access request that meets the preset request filtering rule, so as to reduce the calculation amount of the hardware driver. The implementation process can refer to the description of the corresponding part of the above embodiment, and the present embodiment will not be described in detail.
[0127] It should be noted that in actual application, when the operating system is configured with multiple hardware drivers, a general preset request filtering rule can be configured for the multiple hardware drivers, or a respective preset request filtering rule can be configured for different hardware drivers. In this case, for different preset request filtering rules, the execution can be selected by the corresponding hardware driver or the security driver of the security system. The execution mode can be determined according to actual conditions, and it is not required that the execution modes of all preset request filtering rules are consistent.
[0128] Referring to Figure 6 The flowchart of another optional example of the information processing method proposed in the present application can be described from the side of the operating system running on the electronic device to describe the implementation process of the information processing method. As shown in Figure 6 The method can include the following steps:
[0129] In step S61, a corresponding hardware access request is generated in response to a trigger signal for any hardware of the electronic device.
[0130] In step S62, the hardware access request is sent to the security system of the electronic device for legality verification.
[0131] In the embodiment of the present application, the trigger signal can be generated based on different business requirements. For example, during the running of a client application of the operating system, if a hardware needs to be accessed and processed, a trigger signal for the hardware can be automatically generated. For example, in a payment application, a trigger signal for a camera is generated before payment, a camera start request is generated to request the start of the camera, face authentication is implemented, and after the authentication is passed, the payment instruction is executed to ensure the security of user resources. Alternatively, the trigger signal can be directly generated in response to the operation of the user on the client application, or in response to the configuration operation of the user on the operating system of the electronic device, and the trigger signal for the required hardware is generated. The generation method of the trigger signal is not limited in the present application, and can be determined as appropriate.
[0132] For the access object of the generated hardware access request, the drive calling interface of the hardware driver corresponding to the accessed hardware can be called, the hardware access request is sent to the hardware driver, and the hardware access request received by the hardware driver is forwarded to the security driver for legality verification. The configuration implementation method of the hardware driver and the legality verification implementation method of the hardware access request by the security driver can be referred to but not limited to the description of the corresponding part of the above embodiment, and the embodiment will not be described in detail here.
[0133] In step S63, the execution result of the hardware access request fed back by the security system is received.
[0134] In combination with the information processing method described above from the security system side, after receiving the hardware access request, the security system can perform legality verification on the hardware access request based on the preset hardware access verification rule, execute the hardware access request after verifying that the hardware access request is legal, obtain the corresponding execution result, and the implementation process is not described in detail.
[0135] It can be seen that for the hardware access request generated by the operating system, it needs to be forwarded to the security system for legality verification, and whether to execute the hardware access request is determined by the security system. Compared with the operating system directly executing any hardware access request generated, the risk of illegal attack on the hardware is reduced.
[0136] Referring to Figure 7 For another optional example of the information processing method proposed in the present application, the method is still described from the operating system side of the electronic device, as shown in Figure 7 The method can include the following steps.
[0137] Step S71, in response to a trigger signal for any hardware of the electronic device, a corresponding hardware access request is generated;
[0138] For the implementation process of step S71, reference can be made to the description of the corresponding part of the above embodiment, and the present embodiment will not be described here.
[0139] Step S72, based on the hardware access request, obtaining the request content and request attribute of the hardware access request, and the hardware identifier of the accessed hardware;
[0140] Step S73, based on one or more combinations of the request content, the request attribute, and the hardware identifier, the matching preset request filtering rule is called;
[0141] In the present application, in order to further improve the security of the system, the operating system can first filter the generated hardware access request, and then send the hardware access request meeting the request filtering rule to the security system. The request filtering rule can be configured according to actual business requirements, and the present application does not limit the implementation method of filtering the hardware access request based on the preset request filtering rule, including but not limited to the implementation manner described in the present embodiment.
[0142] In some embodiments, the corresponding request filtering rules can be preconfigured for different types of hardware access requests of different hardware, so that the operating system generates hardware access requests, and sends the hardware access requests to the hardware driver matched with the accessed hardware. The hardware driver needs to filter the received hardware access requests. For this purpose, each received hardware access request can be parsed to determine the request content, request attribute, and hardware identifier of the accessed hardware, thereby determining which hardware is accessed by the access object and what processing is performed on the hardware.
[0143] It should be noted that, in the implementation process of step S72, the information used to configure the personalized preset request filtering rule based on the preset request filtering rule configuration can be one or more combinations of the request content, request attribute, and hardware identifier of the hardware access request, and is not limited to the implementation manner of step S72. Then, the hardware driver can retrieve the preset request filtering rule matched with one or more combinations of the actual obtained request content, request attribute, and hardware identifier from the preconfigured multiple preset request filtering rules.
[0144] The present application does not limit the content of the preset request filtering rule and the implementation method of the configuration, i.e., the representation and storage manner of the matching relationship between the pre-stored different preset request filtering rules and different bases (such as one or more combinations of the request content, request attribute, and hardware identifier).
[0145] Step S74: verifying the to-be-verified filtering information corresponding to the hardware access request according to the preset request filtering rule;
[0146] Since the preset request filtering rule can not only represent which information needs to be filtered, but also represent how to filter the information, the present application can determine the to-be-verified filtering information of the corresponding hardware access request based on the content of the retrieved preset request filtering rule, and then verify whether the to-be-verified filtering information meets the preset request filtering rule, so as to determine whether the hardware access request needs to be forwarded to the security system.
[0147] In actual applications, the implementation manner of step S74 can include but is not limited to: determining whether the request content of the hardware access request meets the hardware access data integrity requirement; determining whether the object attribute of the access object initiating the hardware access request meets the hardware access request format requirement; determining whether the device identifier of the accessed hardware matches the hardware driver receiving the hardware access request; retrieving the access authorization information associated with the device identifier, and determining whether the access object has the access permission of the accessed hardware according to the access authorization information.
[0148] It can be seen that for any hardware of the electronic device hardware layer, such as hardware integrated in the electronic device or an external hardware device, in order to improve the security of hardware use, the corresponding requirements can be configured in advance for various hardware access requests of the hardware, access objects capable of accessing the hardware, hardware drivers capable of driving the hardware, etc. For different hardware, the hardware access request format requirements such as the composition format and / or packaging format of the request packet of the hardware access request, the data integrity requirements of the request content, etc. The application does not limit the above-mentioned different aspects of requirements, which can be determined according to different business requirements, and the application does not make detailed description.
[0149] Among them, the access authorization information of the hardware indicates the authorization information possessed or provided by the access object having access authority to the hardware, such as access key, access address, security certificate, etc. Therefore, each access object can apply for access authority of different hardware in advance, obtain the authorization information of the hardware after obtaining the access authorization of the hardware, and thus realize the access processing of the hardware.
[0150] Optionally, for the hardware configured with a storage area partition, when configuring the corresponding request filtering rule, different request filtering rules can also be configured for different storage areas of the hardware, such as read-only area, read-write area, etc. For example, the hardware access request initiated to the read-only area of the hardware can not be forwarded to the security system by the hardware driver, or the management authority possessed by the access object is determined whether to be forwarded to the security system, etc. It can be configured according to application requirements.
[0151] Step S75, determining that the hardware access request meets the preset request filtering rule, and sending the hardware access request to the security system of the electronic device for legality verification;
[0152] Step S76, determining that the hardware access request does not meet the preset request filtering rule, refusing to send the hardware access request to the security system, and feeding back the interception prompt information to the access object.
[0153] For the filtering processing of the hardware driver on the received hardware access request, after the hardware access request meeting the preset request filtering rule is forwarded to the security system, the implementation method of the security system for the legality verification of the received hardware access request can refer to the description of the corresponding part of the above embodiment, and this embodiment will not be repeated here.
[0154] According to the filtering method of the hardware access request described above, the hardware access request that does not meet the preset request filtering rule does not need to be sent to the security system for legality verification, thereby reducing the resources consumed by the legality verification of the hardware access request and improving the timeliness of the hardware access request response. It should be noted that, in this case, the hardware access request can be directly rejected to be sent to the security system, or the interception prompt information can be directly fed back to the access object (i.e., the object generating the hardware access request in the operating system) to indicate that the hardware access request does not meet the content of the preset request filtering rule, and the feedback mode described in step S76 is not limited, and the content of the interception prompt information and the output mode thereof are not limited by the present application, and can be determined as appropriate.
[0155] With reference to Figure 8 An optional example of the information processing apparatus according to the present application is shown in the structure diagram. The apparatus can be applied to a security system running on an electronic device, as shown in Figure 8 The apparatus can include:
[0156] A hardware access request obtaining module 81 is configured to obtain a hardware access request; the hardware access request is sent by an operating system of the electronic device;
[0157] A verification module 82 is configured to perform legality verification on the hardware access request based on a preset hardware access verification rule;
[0158] A hardware access request execution module 83 is configured to execute the hardware access request when the hardware access request is verified to be legal;
[0159] An execution result feedback module 84 is configured to feed back an execution result of the hardware access request to the operating system.
[0160] In some embodiments, the hardware access request obtaining module 81 described above can include:
[0161] A security application starting unit is configured to start a security application running under a security system of the electronic device;
[0162] A hardware access request receiving unit is configured to call a security driver in the security system to receive a hardware access request forwarded by any hardware driver configured in the operating system.
[0163] In yet some embodiments, the verification module 82 described above can include:
[0164] A preset hardware access verification rule calling unit is configured to call a preset hardware access verification rule matched based on the hardware access request or a hardware driver identifier; the hardware driver identifier represents a hardware driver forwarding the hardware access request from the operating system to the security system;
[0165] a to-be-verified information obtaining unit, configured to obtain to-be-verified information of the hardware access request based on the preset hardware access verification rule;
[0166] The to-be-verified information can include, but is not limited to, one or more combinations of the request content and the request attribute of the hardware access request, the object attribute of an access object in the operating system that generates the hardware access request, the drive configuration information of the hardware driver, and the communication attribute information, the hardware configuration information and the access authorization information of the accessed hardware of the hardware access request.
[0167] a verification unit, configured to verify whether the to-be-verified information meets the preset hardware access verification rule.
[0168] According to the above embodiments, the apparatus can further include:
[0169] a rejection execution module, configured to verify that the hardware access request is illegal, and reject execution of the hardware access request; and / or,
[0170] an access failure feedback prompting module, configured to feed back prompt information of hardware access failure to an access object, wherein the access object refers to an object in the operating system that generates the hardware access request.
[0171] Optionally, the information processing apparatus according to the above embodiments can further include:
[0172] a hardware state obtaining module, configured to obtain a hardware state;
[0173] a target hardware driver control module, configured to determine, based on the hardware state and the hardware driver configuration information, that there is a target hardware driver that matches any hardware assembled or accessed by the electronic device among the hardware drivers configured in the operating system, and send a control instruction for the target hardware driver to the operating system;
[0174] The control instruction is used to trigger the target hardware driver to display a corresponding drive calling interface to the operating system, so that the operating system can generate a hardware access request for the hardware matched by the target hardware driver based on the drive calling interface.
[0175] It should be noted that the various modules, units, etc. in the above apparatus embodiments can be stored in the memory as program modules, and the first processor executes the above program modules stored in the memory to realize the corresponding functions. For the functions realized by the various program modules and their combinations, and the technical effects achieved, reference can be made to the descriptions of the corresponding parts of the above method embodiments executed from the security system side, and the present embodiment will not be described again.
[0176] Referring to Figure 9 , a structural schematic diagram of an optional example of an information processing device proposed in the present application, which can be applied to an operating system running on an electronic device, such as Figure 8 , the device can include:
[0177] A hardware access request generation module 91, configured to generate a corresponding hardware access request in response to a trigger signal for any hardware of the electronic device;
[0178] A hardware access request sending module 92, configured to send the hardware access request to a security system of the electronic device for legality verification;
[0179] An execution result receiving module 93, configured to receive an execution result of the hardware access request fed back by the security system;
[0180] The execution result of the hardware access request is obtained by the security system based on a preset hardware access verification rule, verifying that the hardware access request is legal.
[0181] In some embodiments proposed in the present application, as shown in Figure 10 , the above device can further include:
[0182] A request filtering module 94, configured to filter the hardware access request based on a preset request filtering rule, determine that the hardware access request meets the preset request filtering rule, and trigger the hardware access request sending module 92 to send the hardware access request to the security system of the electronic device for legality verification;
[0183] A request processing module 95, configured to determine that the hardware access request does not meet the preset request filtering rule, and refuse to send the hardware access request to the security system; and / or,
[0184] An interception prompt module 96, configured to feed back interception prompt information to an access object;
[0185] The above access object refers to an object in the operating system that generates the hardware access request, and the interception prompt information is used to indicate the content that the hardware access request does not meet the preset request filtering rule.
[0186] Optionally, as shown in Figure 10 , the above request filtering module 94 can include:
[0187] An information obtaining unit 941, configured to obtain request content and request attributes of the hardware access request, and a hardware identifier of the accessed hardware based on the hardware access request;
[0188] The preset request filtering rule calling unit 942 is configured to call a preset request filtering rule matched based on one or more combinations of the request content, the request attribute, and the hardware identifier;
[0189] The filtering verification unit 943 is configured to verify the to-be-verified filtering information corresponding to the hardware access request according to the preset request filtering rule.
[0190] In actual application, the filtering verification unit 943 can include at least one of the following determining units:
[0191] The first determining unit is configured to determine whether the request content meets the hardware access data integrity requirement.
[0192] The second determining unit is configured to determine whether the object attribute meets the hardware access request format requirement.
[0193] The third determining unit is configured to determine whether the device identifier matches the hardware driver receiving the hardware access request.
[0194] The fourth determining unit is configured to call the access authorization information associated with the device identifier, and determine whether the access object has the access right of the accessed hardware according to the access authorization information.
[0195] It should be noted that, as to various modules, units, etc. in the above-mentioned device embodiments, they can be stored in the memory as program modules, and the second processor executes the above-mentioned program modules stored in the memory to realize the corresponding functions. As to the functions realized by each program module and its combination, and the achieved technical effects, reference can be made to the description of the corresponding part of the above-mentioned method embodiments executed by the operating system. The present embodiment will not be described herein.
[0196] The present application also provides a computer readable storage medium, on which a computer program can be stored, the computer program can be called and loaded by a processor to realize each step of the information processing method described in the above-mentioned embodiments. The implementation process can refer to the description of the corresponding part of the above-mentioned method embodiments.
[0197] Finally, it should be noted that, as to each of the above-mentioned embodiments, unless the context clearly indicates otherwise, “one”, “a”, “an”, and / or “the” do not specifically refer to the singular, but also include the plural. Generally speaking, the terms “include” and “contain” only indicate the inclusion of the steps and elements clearly identified, and these steps and elements do not constitute an exclusive list. The method or device can also include other steps or elements. The element defined by the statement “including one” does not exclude the presence of another identical element in the process, method, product or device including the element.
[0198] In the description of the embodiments of the present application, unless otherwise specified, " / " represents the meaning of or, for example, A / B can represent A or B; "and / or" herein is only a description of the relationship between the associated objects, which means that there can be three relationships, for example, A and / or B, which can represent the three cases of A alone, A and B together, and B alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.
[0199] The terms such as "first", "second" and the like involved in the present application are only for the purpose of description, used to distinguish one operation, unit or module from another operation, unit or module, and do not necessarily require or imply any such actual relationship or sequence between the units, operations or modules. And it cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features, so the features with "first", "second" can explicitly or implicitly include one or more features.
[0200] In addition, each embodiment in the specification is described in a progressive or parallel manner, and each embodiment focuses on the difference from other embodiments, and the same or similar parts between each embodiment can be referred to each other. For the device and electronic equipment disclosed by the embodiment, since it corresponds to the method disclosed by the embodiment, the description is relatively simple, and the related parts can be referred to the method part.
[0201] The skilled person can further realize that the unit steps of each example described in combination with the embodiments disclosed herein can be realized in electronic hardware, computer software or a combination of both. In order to clearly show the interchangeability of hardware and software, the composition and steps of each example have been described in the above description. Whether the functions are executed in hardware or software depends on the specific application and design constraints of the technical solution. The skilled person can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.
[0202] The steps of the method described in combination with the embodiments disclosed herein can be directly implemented by hardware, software modules executed by a processor, or a combination of both. The software modules can be placed in random access memory (RAM), memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in the art.
[0203] The foregoing description of the disclosed embodiments enables a person skilled in the art to make or use the application. Modifications of these embodiments will occur to persons of skill in the art, and that the generic principles defined herein can be applied to other embodiments without departing from the spirit or scope of the application. Therefore, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. An information processing method for a security system running on an electronic device, the method comprising: obtaining a hardware access request; the hardware access request being sent by an operating system of the electronic device; verifying legality of the hardware access request based on a preset hardware access verification rule, the preset hardware access verification rule being related to at least one of an accessed hardware, a hardware driver, and a request content of the hardware access request; verifying that the hardware access request is legal, and performing the hardware access request to access a corresponding hardware in a hardware layer of the electronic device; and feeding back a result of the hardware access request to the operating system. 2.The method of claim 1, wherein the obtaining a hardware access request comprises: starting a security application under the security system of the electronic device; and calling a security driver in the security system to receive a hardware access request forwarded by any hardware driver configured in the operating system. 3.The method of claim 1, wherein the verifying legality of the hardware access request based on a preset hardware access verification rule comprises: calling a matching preset hardware access verification rule based on the hardware access request or a hardware driver identifier; the hardware driver identifier representing a hardware driver forwarding the hardware access request from the operating system to the security system; obtaining to-be-verified information for the hardware access request based on the preset hardware access verification rule; the to-be-verified information comprising one or more combinations of a request content and a request attribute of the hardware access request, an object attribute of an access object generating the hardware access request in the operating system, driver configuration information of the hardware driver, and communication attribute information, hardware configuration information, and access authorization information of an accessed hardware of the hardware access request; and verifying whether the to-be-verified information meets the preset hardware access verification rule. 4.The method of any one of claims 1-3, further comprising: verifying that the hardware access request is illegal, and rejecting to perform the hardware access request, and / or feeding back prompt information of hardware access failure to an access object; the access object being an object generating the hardware access request in the operating system; and / or obtaining a hardware state; determining, based on the hardware state and hardware driver configuration information, that there is a target hardware driver matching any hardware assembled or accessed by the electronic device among each hardware driver configured in the operating system, and sending a control instruction for the target hardware driver to the operating system; wherein the control instruction is used to trigger the target hardware driver to display a corresponding driver calling interface to the operating system, so that the operating system can generate a hardware access request for a hardware matching the target hardware driver based on the driver calling interface. 5.An information processing method for an operating system running on an electronic device, the method comprising: generating a corresponding hardware access request in response to a trigger signal for any hardware of the electronic device; and sending the hardware access request to a security system of the electronic device for legality verification. receive an execution result of the hardware access request of the security system feedback; wherein the execution result of the hardware access request is obtained by the security system based on a preset hardware access verification rule, verifying that the hardware access request is legal, executing the hardware access request, and accessing the corresponding hardware in the hardware layer of the electronic device, and the preset hardware access verification rule is at least related to the accessed hardware, the hardware driver, and the request content of the hardware access request.
6. The method of claim 5, further comprising: filtering the hardware access request based on a preset request filtering rule; determining that the hardware access request meets the preset request filtering rule, and sending the hardware access request to the security system of the electronic device for legality verification; determining that the hardware access request does not meet the preset request filtering rule, and refusing to send the hardware access request to the security system, and / or feeding back an interception prompt information to an access object; the access object refers to an object in the operating system that generates the hardware access request, and the interception prompt information is used to indicate the content of the hardware access request that does not meet the preset request filtering rule.
7. The method of claim 6, wherein filtering the hardware access request based on a preset request filtering rule comprises: obtaining the request content and request attribute of the hardware access request, and the hardware identifier of the accessed hardware based on the hardware access request; based on one or more combinations of the request content, the request attribute, and the hardware identifier, calling a matching preset request filtering rule; verifying the to-be-verified filtering information corresponding to the hardware access request according to the preset request filtering rule; wherein verifying the to-be-verified filtering information corresponding to the hardware access request according to the preset request filtering rule comprises at least one of the following implementation manners: determining whether the request content meets the hardware access data integrity requirement; determining whether the object attribute of the access object initiating the hardware access request meets the hardware access request format requirement; determining whether the device identifier of the accessed hardware matches the hardware driver that receives the hardware access request; calling the access authorization information associated with the device identifier, and determining whether the access object has the access right of the accessed hardware according to the access authorization information.
8. An information processing apparatus for running in a security system of an electronic device, the apparatus comprising: a hardware access request obtaining module for obtaining a hardware access request; the hardware access request is sent by an operating system of the electronic device; a verification module for verifying the legality of the hardware access request based on a preset hardware access verification rule, the preset hardware access verification rule being at least related to the accessed hardware, the hardware driver, and the request content of the hardware access request; a hardware access request execution module for verifying that the hardware access request is legal, executing the hardware access request, and accessing the corresponding hardware in the hardware layer of the electronic device. An execution result feedback module is configured to feed back an execution result of the hardware access request to the operating system. 9.An information processing apparatus for running on an operating system of an electronic device, the apparatus comprising: a hardware access request generation module configured to generate a corresponding hardware access request in response to a trigger signal for any hardware of the electronic device; a hardware access request sending module configured to send the hardware access request to a security system of the electronic device for legality verification; an execution result receiving module configured to receive an execution result of the hardware access request fed back by the security system; wherein the execution result of the hardware access request is obtained by the security system based on a preset hardware access verification rule, verifying the hardware access request to be legal, executing the hardware access request, and accessing and processing the corresponding hardware in the hardware layer of the electronic device, and the preset hardware access verification rule is at least related to the accessed hardware, hardware driver, and request content of the hardware access request. 10.An electronic device having an operating system and a security system running thereon, comprising: a memory configured to store a first program for implementing the information processing method of any one of claims 1-4, and a second program for implementing the information processing method of any one of claims 5-7; a first processor configured to load and execute the first program to run on the security system and implement the information processing method of any one of claims 1-4; a second processor configured to load and execute the second program to run on the operating system and implement the information processing method of any one of claims 5-7.
Citation Information
Patent Citations
A high-security trusted mobile terminal security architecture and security service method
CN109086100A
Operating system kernel mandatory access control method and system based on TEE extension
CN111400723A