The basic experiment of information security system design

Beijing Institute of Electronic Technology (BESTI)

Real Inspection report

Course: Information Security system Design Basic class: 1352 classes

Name: (by contribution size) Malmqvist, Yi Silam, Silver snow Pure

Number: (Ranked by contribution size) 20135235, 20135239, 20125221

Score: Instructor: Lou Jia Peng Experimental Date: 2015.12.1

Experiment level: Preview degree: Experiment time: 15:30-18:00

Instrument Group: Compulsory/Elective: compulsory Test number: four

Experiment Name: Introduction to Kernel-driven design-module-driven experiment

Experimental purposes and requirements:

1. Learn the principle of driving design under LINUX.

2, master the use of modular approach to drive development and debugging process.

Experimental instrument:

Name	Model	Number
Computer		1
Embedded development Platform	Up-netarm2410-cl	1

First, the contents of the experiment

Write a simple virtual hardware driver on the PC and debug it, experiment-driven interface function implementation, analyze and understand the interaction between the driver and the application process.

Second, the principle of experiment

Linux driver design is a very important part of embedded Linux development, it requires the developer not only familiar with the kernel mechanism of Linux, driver and user-level application interface, consider the system in the concurrency of the device and so on, but also very familiar with the working principle of the developed hardware. This is a high demand for driver developers, this experiment is mainly to provide you with a simple introduction to the drive design an example, do not need to provide too much hardware-related content, this should be done by carefully read the information provided by the chip manufacturers to solve.

The role of the driver is an intermediate software layer between the application and the hardware, and the driver should expose all the functionality of the hardware to the application, should not impose other constraints, and the permissions and restrictions on the use of the hardware should be controlled by the application layer. However, sometimes the driver design is related to the development of the project, it is possible to add some application-related design considerations in the drive layer, mainly because the drive layer is more efficient than the application layer, and for the purpose of the project may only strengthen or optimize a certain function of the hardware, and weaken or turn off some other functions In the end, it is up to the developer to show what features of the hardware are needed. Drivers are sometimes used by multiple processes at the same time, we need to consider how to deal with concurrency problems, it is necessary to call some kernel functions using mutex and lock mechanism.

Drivers need to consider the following three aspects: to provide as many options as possible to the user, improve the speed and efficiency of the driver, as far as possible to make the driver simple, make it easy to maintain.

Linux Driver Development Debugging There are two ways, one is to directly compile to the kernel, then run the new kernel to test, and the other is to compile the form of the module, load run debugging separately. The first method is inefficient, but in some cases it is the only way. Module mode is very efficient, it uses the Insmod tool to plug the compiled module directly into the kernel, if there is a failure, you can use Rmmod to unload the module from the kernel. There is no need to restart the kernel, which makes the drive debugging much more efficient. Our experiments can be run on both PC and Up-tech s2410/p270 DVP, and compile with different compilers.

Third, the experimental steps

1. Read and understand the source code

Go to/arm2410cl/exp/drivers/01_demo and read the source code using the VI editor or other editor.

2. Compile driver module and test program

There are two ways to compile in Makefile, you can use GCC on this computer, or you can use a cross-compiler to compile, here we only describe the results of compiling with the cross compiler.

Note: If there is a problem at compile time, it is possible that a Linux connection is not established under /usr/src , you can use the following command:

[Email protected] 01_demo]# cd/usr/src/

[Email protected] src]# LN-SF linux-2.4.20-8 Linux

[[email protected] src]# ls

Debug Linux linux-2.4 linux-2.4.20-8 redhat

3. Test driver

If you compile with GCC, you need to set up the device node with the following command, and if you use a cross-compiler, you do not need to establish a device node.

#mknod/dev/demo C 254 0

The first step is to insert the driver module DEMO.O, then you can use the Lsmod command to see if the module has been inserted, you can also use the Rmmod command to unload the module when you do not use it.

[Email protected] 01_demo]# Insmod demo.o

Warning:loading DEMO.O would taint the Kernel:no license

See http://www.tux.org/lkml/#export-tainted For information about tainted modules

Module Demo loaded with warnings

The following tests are performed using the test program, following the success of the previous steps, as shown below:

[Email protected] 01_demo]#./test_demo

Write bytes Data To/dev/demo

0:0 1 2 3

1:4 5 6 7

2:8 9 10 11

3:12 13 14 15

4:16 17 18 19

5:20 21 22 23

6:24 25 26 27

7:28 29 30 31

*****************************************************

Read bytes Data From/dev/demo

0:31 30 29 28

1:27 26 25 24

2:23 22 21 11

3:12 13 14 15

4:16 17 18 19

5:20 10 9 8

6:7 6 5 4

7:3 2 1 0

*****************************************************

If the module is not successfully inserted, the following situation occurs:

[Email protected] 01_demo]#./test_demo

# # # #DEMO Device Open fail####

After the driver module is successfully inserted, a device file called demo is created under/dev and we can also use the Cat command to directly invoke the Read function to test the reading process.

[Email protected] demo]# cat/dev/demo/0

Device Open success!

Iv. Experience of Experiment

1, the problems encountered in the experiment and solutions

Incorrect kernel address causes debug unsuccessful, using the command "Whereis" to find the kernel address:/usr/src/linux-headers-3.2.0-29-generic-pae/kernel #/lib/modules/$ (Shell UNAME-R)/build/

2. Experience

This experiment is driven by the module mode, because this experiment does not require writing code, only requires reading code and debugging it, so it is relatively smooth. Although some problems during the debugging process, but with the help of students to solve the problem smoothly. The study of the Code of this experiment is not particularly in-depth, but in the future study, will be in-depth understanding.

The basic experiment of information security system design