A testing method for the kernel-mode driver interface of a PCIe cryptographic card

Abstract

The present invention discloses a test method for the kernel-mode driver interface of a PCIe cryptographic card. This method realizes the call of the standard interface in the kernel mode through the crypto engine driver module. The crypto engine driver module supports custom ioctl commands and implements test cases for the kernel-mode driver interface of the PCIe cryptographic card through the ioctl operation interface. A structure for interaction is defined. The test program realizes the test of the PCIe cryptographic card by calling the interface provided by the crypto engine driver module, including device operation function test, performance test, and function test. The present invention realizes the call of the kernel-mode algorithm in the crypto engine driver, passes the test instructions of the user layer through ioctl, and completes the performance and function tests of the driver kernel-mode interface, reducing the workload of users or testers and improving the test efficiency at the same time.

Description

Technical Field

[0001] The present invention relates to the field of PCIe cryptographic card testing, and specifically to a testing method for the kernel-mode driver interface of a PCIe cryptographic card. Background Art

[0002] Many cryptographic algorithms are implemented in the Linux system kernel module. These algorithms are classified according to the type of cryptographic algorithm into: symmetric cryptographic algorithms, digital digest algorithms, random number algorithms, authenticated encryption algorithms, asymmetric cryptographic algorithms, etc., and a unified operation interface is provided at the Kernel (kernel) layer for other kernel modules to call. Some algorithms are further encapsulated into the network layer and exposed to Userspace (user space). There are currently several ways to implement cryptographic operations in the kernel module: the ARM-CE or NEON instructions in the ARM chip can perform aes / hash / md5 operations, there is also a similar cryptocell encryption chip in the security IP of ARM, soft algorithms are implemented through the C programming language, and there are also dedicated cryptographic algorithm chips provided by SOC manufacturers. Undoubtedly, among these several methods, the most efficient one is the dedicated cryptographic algorithm chip provided by SOC manufacturers, such as PCIe cryptographic cards.

[0003] Currently, most PCIe cryptographic cards on the market support the kernel-mode algorithm interface, and register the algorithm into the kernel system through interfaces such as crypto_register_xxx() provided by the kernel module. It is mainly implemented through the crypto engine (the kernel-mode algorithm interface driver, hereinafter referred to as the algorithm driver). By customizing the implementation of the crypto engine by the manufacturer, it is possible to replace the original algorithm implementation in the kernel algorithm framework or add new algorithm implementations, achieving the flexibility of the kernel algorithm and greatly improving the computing performance and efficiency of the cryptographic algorithm. However, as a part registered into the kernel module, the stability of the crypto engine driver is related to the stability of the entire system. In addition, PCIe cryptographic cards are usually deployed on servers. If the driver module is unstable and causes the system to crash, the losses will be immeasurable. Therefore, how to test the kernel-mode algorithm interface is the key problem to be solved in this solution. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide a testing method for the kernel-mode driver interface of a PCIe cryptographic card, design test cases in the crypto engine driver and expose them to the UserSpace user space through the ioctl interface, and pass the test parameters to the driver through the ioctl in the user space to implement the performance and function testing of the cryptographic algorithm.

[0005] To solve the above technical problems, the technical solution adopted by the present invention is: a test method for the kernel-mode driver interface of a PCIe cryptographic card, comprising the following steps:

[0006] S01) Design a crypto engine driver module. The crypto engine driver module implements standard interface calls in the kernel mode. The call interfaces conform to the standards of the Linux kernel cryptographic module framework and are used for other kernel modules to directly call the cryptographic operation functions provided by the PCIe cryptographic card;

[0007] The crypto engine driver module supports custom ioctl commands and implements test cases for the kernel-mode driver interface of the PCIe cryptographic card through the ioctl operation interface. The test cases cover performance and function tests of the kernel-mode driver interface of the PCIe cryptographic card;

[0008] S02) Define a structure for interaction. The structure is used to transfer test parameters, and the operation result is read through the read device interface implemented in the crypto engine driver module;

[0009] S03) The test program realizes the test of the PCIe cryptographic card by calling the interfaces provided by the crypto engine driver module, including device operation function test, performance test, and function test.

[0010] Furthermore, the crypto engine driver module is divided into three layers. The bottom layer is the hardware access module, which directly accesses the algorithm core of the PCIe cryptographic card; the second layer is the encapsulated standard kernel-mode interface. When the system loads the driver, it registers the cryptographic algorithm with the kernel encryption framework; the top layer is the implemented cryptographic algorithm test cases. When the driver module receives an ioctl instruction, it calls the corresponding test case according to the corresponding instruction code and test parameters.

[0011] Furthermore, the implementation process of the crypto engine driver module is as follows:

[0012] S11) When initializing the driver module, register a character device for system devices to operate the PCIe cryptographic device;

[0013] S12) Complete device initialization, open the PCIe device and return the device handle, which is used for subsequent interface access operations on the device;

[0014] S13) Register the cryptographic interface and register the cryptographic algorithm with the kernel encryption framework by calling crypto_register_xxx;

[0015] S14): Add a character device class to the driver module, and initialize and register the methods that can be implemented by the character device through cdev. The implemented methods include opening the device, ioctl operation, closing the device, reading the device interface, and writing the device interface.

[0016] Furthermore, there are two structures, namely ioctl_param_t and read_param_t;

[0017] The ioctl_param_t structure contains the following parameters: algorithm type, algorithm mode, data length, synchronous / asynchronous mode, performance test algorithm type, number of loops, test result, standard / non-standard mode, test start time, test end time, test duration, and algorithm support flag; the ioctl_param_t structure is used for the user space, that is, the test program, to transfer test parameters to the crypto engine driver module;

[0018] The read_param_t structure contains the following parameters: original data, original data length, output data, output data length, key data, key length, IV data, IV length, hash data, hash data length, hash result, hash result length, permission key, and permission key length; the read_param_t structure is used for the crypto engine driver module to transfer test results to the user space, that is, the test program.

[0019] Furthermore, the interaction process between the crypto engine driver module and the test program is as follows: when the system loads the driver program, there is a character device descriptor corresponding to the PCIe cryptographic card in the / dev directory. The test program calls the open interface to open the device, and then it can access the PCIe cryptographic card. Through the control code of the ioctl interface, tests are performed. When calling the corresponding control code of ioctl, the test instructions and test data are interacted through the structure agreed upon with the crypto engine driver module; when the test program transfers data to the crypto engine driver module, the crypto engine driver module calls copy_from_user to obtain the test instructions and data passed by the test program from the user space; when the crypto engine driver module finishes execution, it passes the test results and test data to the user space through copy_to_user, and the test program reads the test results and parses them for subsequent processing.

[0020] Further, the implementation process of the performance test is as follows: After the test program opens the PCIe cryptographic card device, according to the test instructions input by the user, it fills the test parameters into the ioctl_param_t structure, sets the data packet length, the number of loops, and the type of algorithm to be tested; after receiving the ioctl instruction, the driver module parses the test instructions through the ioctl_param_t structure and starts a test thread to perform the corresponding performance test. After the test is completed, it returns the test metrics to the test program through the ioctl_param_t structure, and the test program calculates the performance metrics based on the test results.

[0021] Further, the implementation process of the function test is as follows: The test program fills the test parameters into the ioctl_param_t structure according to the test instructions passed in by the user and executes the ioctl function test. After the driver module receives the corresponding test instructions, it executes the corresponding test and transfers the test data to the user space through copy_to_user. The test program reads the data of the read_param_t structure from the driver through the read interface and calls openssl to calculate the correctness of the structure data. If the data is consistent, it indicates that the algorithm interface in the kernel state is executed correctly; if the data is inconsistent, it indicates that there is an error in the algorithm interface in the kernel state.

[0022] The beneficial effects of the present invention: Although the linux kernel also provides a method for the user space to access the underlying algorithms of the kernel, that is, the user space (Userspace) can call the underlying algorithms of the kernel through the netlink interface (PF_ALG), in the user space, it is necessary to specify the socket interface PF_ALG, the algorithm name (such as xxcipher), and the specific algorithm implementation to be called (such as aes-cbc), and transfer the user layer commands to the Kernel layer. According to these parameter information, it jumps to the corresponding algorithm implementation layer (i.e., the kernel algorithm framework interface). Obviously, this test method is too cumbersome, with a large workload and low efficiency. In addition, the user space cannot call the asymmetric cryptographic algorithms in the kernel layer. Through the test method proposed by the present invention, that is, implementing the call to the kernel state algorithms in the crypto engine driver, passing the test instructions of the user layer through ioctl, and completing the performance and function tests of the driver kernel state interface, it reduces the workload of users or testers and improves the test efficiency at the same time. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 It is a schematic diagram of the crypto engine driver module;

[0024] Figure 2 It is a schematic diagram of the data interaction between the driver module and the test program;

[0025] Figure 3 It is a flowchart for performance testing;

[0026] Figure 4 It is a flowchart for functional testing. Specific implementation manners

[0027] The present invention will be further described below in conjunction with the accompanying drawings and specific embodiments.

[0028] Embodiment 1

[0029] This embodiment discloses a test method for the kernel-mode driver interface of a PCIe cryptographic card. It is easy for those skilled in the art to think of accessing the driver through the ioctl method. However, the kernel-mode algorithm interface cannot be directly called through the ioctl method. The innovation of this embodiment lies in designing test cases in the crypto engine driver and exposing them to the UserSpace user space through the ioctl interface. In the user space, the test parameters are passed to the driver through ioctl to achieve performance and functional testing of the cryptographic algorithm.

[0030] Specifically, this method includes the following steps:

[0031] S01). Design a crypto engine driver module. The crypto engine driver module implements standard interface calls in the kernel mode. The call interfaces conform to the Linux kernel cryptographic module framework standard and are used for other kernel modules to directly call the cryptographic operation functions provided by the PCIe cryptographic card.

[0032] The IOCTL function is a standard API interface in the Linux system and is a device control interface function in the device driver. The PCIe used in this solution is a character device, and character device drivers usually implement functions such as device opening, closing, reading, and writing. In this embodiment, the crypto engine driver module supports custom ioctl commands and implements test cases for the kernel-mode driver interface of the PCIe cryptographic card through the ioctl operation interface. The test cases cover performance and functional testing of the kernel-mode driver interface of the PCIe cryptographic card.

[0033] S02). Define a structure for interaction. The structure is used to pass test parameters, and the operation result is read through the read device interface implemented in the crypto engine driver module;

[0034] S03) The test program mainly implements the following functions by calling the interfaces provided by the crypto engine driver module: device operation functions, i.e., opening / closing the device; calling ioctl to pass performance test parameters to implement performance testing; calling ioctl to pass function test parameters to implement function testing.

[0035] As Figure 1 shown, the crypto engine driver module is divided into three layers. The bottom layer is the hardware access module that directly accesses the algorithm core (PCIe registers) of the PCIe cryptographic card; the second layer is the encapsulated standard kernel-mode interface that registers cryptographic algorithms with the kernel encryption framework when the system loads the driver; the top layer is the implemented cryptographic algorithm test cases. When the driver module receives an ioctl instruction, it calls the corresponding test cases according to the corresponding instruction code and test parameters.

[0036] In this embodiment, the implementation process of the crypto engine driver module is as follows:

[0037] S11) When initializing the driver module (driver_init), register a character device for system devices and operate the PCIe cryptographic device;

[0038] S12) Complete device initialization (device_init), open the PCIe device and return a device handle, which is used for subsequent interface access operations on the device;

[0039] S13) Register the cryptographic interface (register_algo), and register the cryptographic algorithm with the kernel encryption framework by calling crypto_register_xxx;

[0040] S14) Add a character device class to the driver module. Assume the device name is "pci-kci-drv". Initialize and register the methods that the character device can implement through cdev. The methods implemented in this embodiment include opening the device (kci_dev_open), ioctl operation (kci_dev_ioctl), closing the device (kci_dev_close), reading the device interface (kci_dev_read), and writing the device interface (kci_dev_write).

[0041] In this embodiment, the structure is the intermediary for the interaction between the test program and the driver module. There are two structures, namely ioctl_param_t and read_param_t;

[0042] The ioctl_param_t structure contains the following parameters: algorithm type, algorithm mode, data length, synchronous / asynchronous mode, performance test algorithm type, number of loops, test result, standard / non-standard mode, test start time, test end time, test duration, and algorithm support flag; the ioctl_param_t structure is used for the test program in user space to pass test parameters to the crypto engine driver module;

[0043] The read_param_t structure contains the following parameters: original data, original data length, output data, output data length, key data, key length, IV data, IV length, hash data, hash data length, hash result, hash result length, permission key, and permission key length; the read_param_t structure is used for the crypto engine driver module to pass test results to the test program in user space.

[0044] As Figure 2 shown, the interaction process between the crypto engine driver module and the test program is as follows: when the system loads the driver program, there is a character device descriptor corresponding to the PCIe cryptographic card in the / dev directory. The test program calls the open interface to open the device, and then it can access the PCIe cryptographic card. Through the control code of the ioctl interface, tests are conducted. When calling the corresponding control code of ioctl, the test instructions and test data are interacted through the structure agreed upon with the crypto engine driver module; when the test program transmits data to the crypto engine driver module, the crypto engine driver module calls copy_from_user to obtain the test instructions and data passed by the test program from user space; after the crypto engine driver module finishes execution, it passes the test results and test data to user space through copy_to_user, and the test program reads the test results and parses them for subsequent processing.

[0045] As Figure 3 shown, the implementation process of the performance test is as follows:

[0046] After the test program opens the device, according to the test instructions input by the user, it fills the test parameters into the ioctl_param_t structure, sets the data packet length, number of loops, and the algorithm type of the test; after receiving the ioctl instruction, the driver module parses the test instructions through the ioctl_param_t structure and starts a test thread to conduct the corresponding performance test. After the test ends, it returns the test metrics to the test program through the ioctl_param_t structure, and the test program calculates the performance metrics based on the test results.

[0047] AsFigure 4 As shown, the implementation process of the functional test is as follows:

[0048] Based on the test instructions passed in by the user, the test program fills the test parameters into the ioctl_param_t structure and executes the ioctl functional test. After receiving the corresponding test instructions, the driver module executes the corresponding test and transfers the test data to the user space through copy_to_user. The test program reads the data of the read_param_t structure from the driver through the read interface and calculates the correctness of the data in the structure by calling openssl. If the data is consistent, it indicates that the algorithm interface in the kernel state is executed correctly; if the data is inconsistent, it indicates that there is an error in the algorithm interface in the kernel state.

[0049] During the functional test, the data to be tested is passed to the driver module. After the driver performs algorithm operations, the test program reads the operation results generated by the driver through the read interface and conducts an algorithm correctness test on the operation results. If the test data is accurate, the test case passes. Taking the SM4 symmetric algorithm as an example, the data to be tested (plaintext, key) is passed to the driver module. After the driver module finishes the operation, the operation result (ciphertext) is read through the read interface. The ciphertext and the key are decrypted through the soft algorithm provided by openssl to obtain the plaintext result, which is compared with the original data to be tested. If the data is consistent, it indicates that the algorithm is correct.

[0050] The present invention realizes the call of the kernel-state algorithm in the crypto engine driver, passes the test instructions of the user layer through ioctl, and completes the performance and function tests of the driver kernel-state interface, reducing the workload of users or testers and improving the test efficiency at the same time.

[0051] The above only describes the basic principles and preferred embodiments of the present invention. The improvements and replacements made by those skilled in the art based on the present invention fall within the protection scope of the present invention.

Claims

1. A test method for the kernel-mode driver interface of a PCIe cryptographic card, characterized in that: It includes the following steps: S01). Design a crypto engine driver module. The crypto engine driver module realizes the standard interface call in the kernel state. The call interface conforms to the Linux kernel cryptographic module framework standard and is used for other kernel modules to directly call the cryptographic operation functions provided by the PCIe cryptographic card; The crypto engine driver module supports custom ioctl commands and implements test cases for the PCIe cryptographic card kernel state driver interface through the ioctl operation interface. The test cases cover the performance and function tests of the PCIe cryptographic card kernel state driver interface; S02). Define a structure for interaction. The structure is used to pass test parameters and read the operation results through the read device interface implemented in the crypto engine driver module; S03). The test program realizes the test of the PCIe cryptographic card by calling the interface provided by the crypto engine driver module, including device operation function test, performance test and function test.

2. The test method for the PCIe cryptographic card kernel-mode driver interface according to claim 1, characterized in that: The cryptoengine driver module is divided into three layers. The bottom layer is the hardware access module, which directly accesses the algorithm core of the PCIe cryptographic card; the second layer is the encapsulated standard kernel state interface. When the system loads the driver, it registers the cryptographic algorithm with the kernel encryption framework; the top layer is the implemented cryptographic algorithm test cases. When the driver module receives an ioctl instruction, it calls the corresponding test case according to the corresponding instruction code and test parameters.

3. The test method for the PCIe cryptographic card kernel-mode driver interface according to claim 1 or 2, characterized in that: The implementation process of the crypto engine driver module is as follows: S11). When the driver module is initialized, register a character device for system devices and operate the PCIe cryptographic device; S12). Complete device initialization, open the PCIe device and return the device handle, which is used for subsequent interfaces to access the device; S13). Register the cryptographic interface and register the cryptographic algorithm with the kernel encryption framework by calling crypto_register_xxx; S14). Add a character device class to the driver module and implement the methods that can be realized by the registered character device through cdev initialization. The implemented methods include opening the device, ioctl operation, closing the device, read device interface, and write device interface.

4. The test method for the PCIe cryptographic card kernel-mode driver interface according to claim 1, characterized in that: There are two structures, namely ioctl_param_t and read_param_t; The ioctl_param_t structure contains the following parameters: algorithm type, algorithm mode, data length, synchronous / asynchronous mode, performance test algorithm type, number of loops, test result, standard / non-standard mode, test start time, test end time, test duration, and algorithm support flag. The ioctl_param_t structure is used for the user space, that is, the test program, to pass test parameters to the cryptoengine driver module; The read_param_t structure contains the following parameters: raw data, raw data length, output data, output data length, key data, key length, IV data, IV length, hash data, hash data length, hash result, hash result length, permission key, and permission key length; the read_param_t structure is used for the crypto engine driver module to pass test results to the user space, i.e., the test program.

5. The test method for the PCIe cryptographic card kernel-mode driver interface according to claim 1, characterized in that: The interaction process between the cryptoengine driver module and the test program is as follows: When the system loads the driver program, there is a character device descriptor corresponding to the PCIe cryptographic card in the / dev directory. The test program calls the open interface to open the device, and then it can access the PCIe cryptographic card. Through the control code of the ioctl interface, tests are conducted. When calling the corresponding control code of ioctl, the test instructions and test data are interacted through the structure agreed upon by the cryptoengine driver module; when the test program transmits data to the cryptoengine driver module, the crypto engine driver module calls copy_from_user to obtain the test instructions and data passed by the test program from the user space; after the crypto engine driver module finishes execution, it passes the test results and test data to the user space through copy_to_user, and the test program reads the test results and parses them for subsequent processing.

6. The test method for the PCIe cryptographic card kernel-mode driver interface according to claim 1, wherein: The implementation process of the performance test is as follows: After the test program opens the PCIe cryptographic card device, according to the test instructions input by the user, it fills the test parameters into the ioctl_param_t structure, sets the data packet length, number of loops, and the type of algorithm to be tested; after receiving the ioctl instruction, the driver module parses the test instructions through the ioctl_param_t structure and starts a test thread to conduct the corresponding performance test. After the test ends, it returns the test metrics to the test program through the ioctl_param_t structure, and the test program calculates the performance metrics based on the test results.

7. The test method for the PCIe cryptographic card kernel-mode driver interface according to claim 1, characterized in that: The implementation process of the function test is as follows: The test program fills the test parameters into the ioctl_param_t structure according to the test instructions passed in by the user and executes the ioctl function test. After receiving the corresponding test instructions, the driver module executes the corresponding test and passes the test data to the user space through copy_to_user. The test program reads the data of the read_param_t structure from the driver through the read interface and calls openssl to calculate the correctness of the structure data. If the data is consistent, it means that the algorithm interface in the kernel state is executed correctly; if the data is inconsistent, it means that there is an error in the algorithm interface in the kernel state.

Images