CN-121980590-A - Device driver security binding method and device based on runtime type identification

Abstract

The invention belongs to the technical field of operating system kernels, in particular to a device driver safety binding method and device based on a runtime type identifier, the method comprises the steps of abstracting and packaging a device object, and establishing a unique runtime type identifier for the device object; after the primary matching of the drive and the equipment is successful, the controlled type conversion verification is executed based on the type identifier of the running time of the equipment object, the specific equipment object instance is successfully returned only when the expected equipment type of the drive is consistent with the actual type of the equipment, and finally, whether the binding is established or not is decided according to the downward transformation result. The present invention creates a secure translation channel from an abstract interface to a concrete instance by introducing a runtime type identification verification layer in the device driver architecture. The mechanism realizes the controlled access of the abstract object to the specific object while maintaining the decoupling design of the device and the driving interface, improves the safety and reliability of the device driving binding process, and has good expansibility.

Inventors

• He Xieen
• Zhang Mianbing

Assignees

• 泽天智航电子技术(四川)有限公司

Dates

Publication Date

20260505

Application Date

20260126

Claims (10)

1. 1. A device driver security binding method based on runtime type identification, comprising: s1, taking a device object into system management in a unified abstract interface form, distributing a first-level device type identifier for device classification for the device object, associating a second-level runtime type identifier for the device object, binding the second-level runtime type identifier with a corresponding device type, and uniquely identifying the actual type of the device object during runtime; s2, declaring supportable target equipment types in the driving object, and establishing a matching rule, wherein the matching rule comprises the steps of screening equipment types through first-stage equipment type identifiers, and carrying out accurate type matching through second-stage runtime type identifiers after screening; s3, after the driving object and the equipment object are successfully matched through the first-stage equipment type identifier, executing a safety downward transformation operation based on a runtime type identifier carried in the equipment object, verifying whether the actual type of the equipment object is consistent with the driving expected type or not in the runtime of the safety downward transformation operation, and if so, successfully operating and returning a corresponding specific equipment object instance; And S4, according to the execution result of the safe down-conversion operation, when the down-conversion operation is successful, establishing a binding relation between the equipment object and the driving object, and when the down-conversion operation fails, terminating the binding flow and preventing the driving object from accessing the corresponding equipment object through the abstract interface.
2. 2. The method of claim 1, wherein in S1, the unified abstract interface comprises a query interface for obtaining device type identification, a translation interface for obtaining a base interface reference supporting runtime type checking, and wherein the base interface provides secure down-conversion operations based on runtime type identification.
3. 3. The method of claim 1, wherein in S1, the first-level device type identifier is a character string type or a global enumeration value for device classification screening, and the second-level runtime type identifier is a unique identifier allocated to a specific device type at compile time, and the device type is accurately identified by the identifier at runtime.
4. 4. The method of claim 1, wherein in S2, the matching rule includes querying a first-level device type identifier of the device object through a unified abstract interface of the device object, performing a preliminary comparison with a target device type of the driver declaration, and performing accurate type matching verification through a second-level runtime type identifier after the preliminary comparison is passed.
5. 5. The method of claim 1, wherein in S3, the secure down-conversion operation is implemented by a down-conversion method provided by the base interface, which verifies type consistency based on runtime type identification at runtime, and performs secure conversion from abstract interface to specific device instance after verification passes.
6. 6. The method of claim 5, wherein the downward-turning method provided by the base interface completes runtime type identification verification and security type translation in a single call, wherein the method returns a null value or error code indicating failure when the runtime type identification of the device object is inconsistent with the drive expected type, and wherein the method returns a reference to securely access a particular device object instance when the identifications are consistent.
7. 7. The method of claim 1, wherein in S4, if the down-conversion fails, terminating the current binding flow and preventing the driver from accessing the device object through the abstract interface.
8. 8. The method of claim 1, wherein the method is performed in a device management framework that maintains a device registry containing all registered abstract device objects, and a driver registry containing all registered driver objects.
9. 9. The method of claim 8, wherein S3 and S4 comprise performing secure downconversion verification based on the second level runtime type identification for each pair of devices and drivers that are matched by the first level device type identification by traversing the device registry and the driver registry, and establishing a binding relationship or terminating a binding flow based on the verification result.
10. 10. A device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements a runtime type identification based device driver security binding method as claimed in any one of claims 1 to 9 when the computer program is executed.

Description

Device driver security binding method and device based on runtime type identification Technical Field The present invention relates to the field of operating system kernel technologies, and in particular, to a device driver security binding method and device based on a runtime type identifier. Background In the kernel of the operating system and the embedded system, the device driving framework generally adopts a unified abstract interface to manage different types of device objects so as to realize the general registration, unified scheduling and driving extensible support of the devices. By introducing abstract device objects, the system can mask specific hardware differences at the framework level, thereby simplifying device management logic and improving maintainability of the system. In the prior art, in order for a driver to perform initialization, configuration, or data interaction on a device, it is often necessary to establish a binding relationship between an abstract device object and its concrete implementation. Aiming at the requirement, the existing scheme adopts one of the following modes of binding a specific device type with a driving logic in a compiling stage through static type agreement or structure body nesting mode, converting an abstract object into the specific object by a driver in an operation stage through contracted pointer offset, private data pointer or type field, matching through device type character strings or enumeration values, and directly assuming that the object type is established by the driver and executing subsequent operation after the matching is successful. However, the scheme has the common defects that firstly, the consistency between the abstract device object and the specific device object usually depends on manual convention or implicit rule, a unified and verifiable type checking mechanism is lacking in a system layer, secondly, in an operation stage, a driver often acquires the specific device object in a forced type conversion or default assumption mode, once the device type is inconsistent with the driver expectation, illegal memory access, undefined behavior or system stability problem is easily caused, thirdly, as the device type and the number of the drivers are increased, the type is difficult to manage uniformly based on the convention conversion mode, and type errors are often only exposed in an abnormal or system fault mode in operation. Although some programming languages or runtime environments provide runtime type identification or type recognition capabilities, such mechanisms typically serve language-level object models, and a solution that can be combined with device driver binding procedures has not been formed for uniformly verifying and constraining the actual type identity of an abstract device prior to the driver's acquisition of a particular device object. Therefore, how to achieve secure acquisition of a specific device object in the device driver binding process on the premise of maintaining the unified abstract interface design is still an issue that has not been effectively solved in the prior art. Disclosure of Invention The invention provides a device driving safety binding method and device based on a runtime type identifier, which aim to solve the technical problems of undefined behavior, illegal memory access and system stability caused by forced type conversion or type assumption errors in the prior art. In a first aspect, an embodiment of the present invention provides a device driver security binding method based on a runtime type identifier, including: s1, taking a device object into system management in a unified abstract interface form, distributing a first-level device type identifier for device classification for the device object, associating a second-level runtime type identifier for the device object, binding the second-level runtime type identifier with a corresponding device type, and uniquely identifying the actual type of the device object during runtime; s2, declaring supportable target equipment types in the driving object, and establishing a matching rule, wherein the matching rule comprises the steps of screening equipment types through first-stage equipment type identifiers, and carrying out accurate type matching through second-stage runtime type identifiers after screening; s3, after the driving object and the equipment object are successfully matched through the first-stage equipment type identifier, executing a safety downward transformation operation based on a runtime type identifier carried in the equipment object, verifying whether the actual type of the equipment object is consistent with the driving expected type or not in the runtime of the safety downward transformation operation, and if so, successfully operating and returning a corresponding specific equipment object instance; And S4, according to the execution result of the safe down-conversion operation, when the down-conversion operation i