Kernel symbol table and system call

 

1.During driver developmentKernel symbol tableAndSyscallI don't know how you understand these two concepts. Here I will list my understanding of them as follows for your reference:

Kernel symbol tableIs a part of the reference provided by the Linux kernel to the kernel code. It refers to "kernel code", including kernel and driver programs running in the kernel memory space. "Reference" includes references to variables, function reference. The most common kernel symbol reference is printk printing output. Generally, a kernel symbol is an interface provided by some kernel code to other kernel code to access its internal data. In the driver, if the driver contains a part called by other kernel code, you can use export_symbol to export it to the kernel symbol table.

In a multi-layer driver model such as USB, SCSI, or file system, the underlying driver needs to export its function to the kernel symbol table and call it to the upper-layer driver.

System CallIt is a function call interface provided by the basic kernel. It refers to a kernel that does not include drivers and cannot be streamlined at will. The interface called by the system can be called not only for codes running in the kernel space, but also for programs in the user space. The initial purpose of a system call is to provide the user program with an interface to access the operating system. The most common system calls include open, close, read, and write.

When a user application uses open ("/dev/null") to open a device, what functions does the system call complete? Simply put, an application notifies the operating system that the/dev/null device needs to be enabled. After successful, the operating system returns the device handle. For details about what the operating system has done to enable the device, refer to the implementation of sys_open in the kernel code.

The content in the kernel symbol table can only be accessed by the kernel space program. system calls are not subject to this restriction. System calling is the most basic kernel-provided code that cannot be added or removed at will, and kernel symbols can be exported as needed.

It is worth noting that when a system call occurs in the kernel code such as a driver, the System Call code runs in the user space of the process. In this case, it is a bit vague, and the example is clear.

Process test, virtual device/dev/readfiledriver named readfile.o, and file name.txt.

In Test. c:

Open ("/devreadfile "...)

In the driver of readfile. c:

Open(domainname.txt "...)

Name OPEN1, and OPEN2. OPEN1 system calls run in the memory zone of the test process, and readfile. o module code runs in the kernel space. When the system calls OPEN2, OPEN2 actually runs in the memory zone of the test process. The Test memory zone is the user space, which is very important. We do not recommend using system calls in the driver code to prevent deadlocks.

2.Any operating system will have some functions built in the core. These functions can
The components that come into contact with the underlying computer are actually the core functions of the operating system. Although they are few,
It is relatively simple, but can complete any operation on the entire system.

-- This type of function in Linux is called "system call ".

System calling is a bridge between users and core spaces that transmits information. For example
For example, fopen, which is common in C language, is explained by sys_open system calls in the core space. So, I
Which system calls are provided by our systems? In linux, there is such a file/usr/include/s.
Ys/syscall. h, which lists all system calls. For example, my syscall. h file looks like this.
:

# Ifndef _ sys_syscall_h
# DEFINE _ sys_syscall_h

# Define sys_setup 0
# Define sys_exit 1
# Define sys_fork 2
# Define sys_read 3
....
# Define sys_setresuid 164
# Define sys_getresuid 165
# Define sys_vm86 166
# Define sys_query_module 167
# Define sys_poll 168
# Define sys_syscall_poll sys_poll

# Endif

From the above file, we can see that each system call corresponds to a predefined digital code (see the table above)
), This code is used to represent each system call.

At the core of Linux, there is a special structure: sys_call_table [] array, digital code, and system calling.
The ing relationships are stored in this array. When the system calls a system function
Array to find the corresponding system call code, and then execute the real system function through 0x80 interruption according to the code
.

OK. Now that we have mastered the above knowledge, we can continue to learn. The following table lists
Some of the most interesting and commonly used system calls, and provide a brief description of the features. However, if you really want to write some
If you use LKM, You can carefully understand the call process.

System Call: int sys_brk (unsigned long new_brk );
Function: change the size of a DS (data segment ).

System Call: int sys_fork (struct pt_regs regs );
Function: it has the same function as the fork () function of the user space.

System Call: int sys_getuid () int sys_setuid (uid_t uid )...
Function: Manage System calls of user IDs.

System Call: int sys_get_kernel_sysms (struct kernel_sym * table)
Function: access the core system table. See I .3

System Call: int sys_sethostname (char * name, int len );
Int sys_gethostname (char * name, int len );
Function: Set the Host Name and query the host name.

System Call: int sys_chdir (const char * path );
Int sys_fchdir (unsigned int fd );
Function: both are used to set the current directory. (Cd... command)

System Call: int sys_chmod (const char * filename, mode_t mode );
Int sys_chown (const char * filename, mode_t mode );
Int sys_fchmod (unsigned int fildes, mode_t mode );
Int sys_fchown (unsigned int fildes, mode_t mode );
Function: manage user permissions.

System Call: int sys_chroot (const char * filename );
Function: sets the root directory of the call process.

System Call: int sys_execve (struct pt_regs regs );
Function: Important! This is the system call of the execution file, and pt_regs is the register stack.

System Call: long sys_fcntl (unsigned int fd, unsigned int cmd, unsigned long
Arg );
Function: changes the attributes of the file description sub-statement.

System Call: int sys_link (const char * oldname, const char * newname );
Int sym_link (const char * oldname, const char * newname );
Int sys_unlink (const char * name );
Function: Manage hard/soft links.

System Call: int sys_rename (const char * oldname, const char * newname );
Function: rename a file.

System Call: int sys_rmdir (const char * name );
Int sys_mkdir (const * char filename, int mode );
System Call: function: Create and delete directories.

System Call: int sys_open (const char * filename, int mode );
Int sys_close (unsigned int fd );
Function: open or close a file.

System Call: int sys_read (unsigned int fd, char * buf, unsigned int count );
Int sys_write (unsigned int fd, char * buf, unsigned int count );
Function: read and write files.

System Call: int sys_getdents (unsigned int fd, struct dirent * dirent, unsigne
D int count );
Function: query the file list (that is, the ls... command ).

System Call: int sys_readlink (const char * path, char * buf, int bufsize );
Function: Read symbolic links.

System Call: int sys_selectt (int n, fd_set * indium, fd_set * outp, fd_set * exp, s
Truct timeval * tvp );
Function: IO compound operation.

System Call: sys_socketcall (INT call, unsigned long ARGs );
Function: socket function.

System Call: Unsigned long sys_create_module (char * Name, unsigned Long SIZE)
;
Int sys_delete_module (char * Name );
Int sys_query_module (const char * Name, int which, void * Buf, size_t bufs
Ize, size_t * RET );
Function: load/uninstall and query lkm programs.

From the perspective of hackers, the above system calls are the most interesting part, of course, maybe in your cool System
Some special calls are also required. However, for common hackers, the above list is sufficient.
. In the following sections, we will learn how to use these calls.

So what is the kernel symbol table?

In the/proc/ksyms file, various kernel symbols are clearly displayed.
Each line indicates an allocated kernel symbol (and there is no secret), so our lkm can be light
Easy to read these core symbols. Why do we need to access lkm here? You can take a closer look at this article.
Oh, I dare to make a ticket. The more you see it, the more interesting you will feel. Not only can you see some very sensitive functions,
We can even find our own lkm functions, because this public field is not confidential and all of them are made public.

However, since we can see lkm from here, the system administrator must be able
Seeing, maybe the administrator just wiped out our LKM in an instant, which is not very interesting. So
What are the best solutions to hide LKM? We will discuss a variety of topics later.
But here we need to talk about the simplest, most effective, and most brilliant method. :)

In fact, we do not need to use any illegal means or use system defects to prevent our
KM output to this public kernel symbol table, the only thing we need to do is to create another internal
Core symbol table, so that the kernel symbols output by LKM can be included in our own kernel table! How can this problem be solved? Simple:

Static struct symbol_table module_syms = {
# Include
...
};
Register_symtab (& module_syms );

Because we do not need to output any symbols to a public location, we use the following code to initialize our LKM
:

Register_symtab (NULL );

Note: This line of code must be written in the init_module () function, which indicates that we do not use the default symbol table.