Is it possible to determinate which functions a kernel module calls?

Question

Trusting kernel drivers is bad. Is there something we can do to have at least an idea about what it does?

For example, let's suppose an armv8a linux kernel. I'd search for all the syscalls, which according to https://stackoverflow.com/a/12951533, are the SVC commands. They should contain the number of the syscalls and I could find which functions of the kernel are being called. But this is for syscalls only.

However, a kernel module can use other symbols, which I don't know how to find.

Also, I don't know if it's possible to do this in armv8a, but couldn't the kernel module code generate a binary data in RAM and branch to it, and this block could contain a syscall by itself? This wouldn't appear in a static analysis of the kernel module, because it happens in runtime.

I'm trying to get into this world of binary analysis and I'm a little lost.

Answer 1

Trusting kernel drivers is bad.

Oh? Why? Almost everybody does this. Whether it is a Windows kernel driver or a Linux driver doesn't matter. Furthermore: they are an extension of the kernel, and if you don't trust device drivers, why trust the rest of the kernel?

In general, we trust the OS we get. We take some precautions to make sure it is correct (for example: we download from a trusted source, buy it from Microsoft/RedHat/Apple/... etcetera). The kernel drivers are part of this. Of course, if you need specific hardware (e.g. graphics cards), you may need to use a driver from the hardware manufacturer. If you do not trust him (f.e. you fear that there may be NSA/Chinese/Russian/... backdoors in it), don't use that hardware.

The example you gave is, as you said, for system calls. On Linux, some additional info can be found in man 2 syscall.

In general, it is far easier to look at the source code, if it is available, than to look at the binary. Disassembly or decompiling may seem a viable option, but (for example if you're on Windows) check your license.

The kernel drivers in general run in privileged mode. That means that almost everything is possible.

Answer 2

It's pointless to look for system calls in the code of a kernel driver. Kernel code is what system calls call.

A kernel module has exactly the same privileges as the part of the kernel that's loaded at boot time. There is no memory protection inside the kernel. The Linux kernel contains some protection against accidental errors in kernel modules: for example a null pointer dereference inside a module won't crash the whole kernel, and the source code of a module can't refer to functions of other modules or of the main part of the kernel that aren't declared as exported. But this only makes the system more stable if a driver is buggy. It is not intended as a security countermeasure.

Kernel code can call privileged instructions. Kernel code can write new code to RAM and execute it, or can modify already-loaded kernel code. This doesn't augment what the kernel code can do: dynamically generated code would have the same privileges as the code stored in the disk file for the kernel module. All that a malware writer would gain by generating code dynamically would be to make reverse engineering of the binary more difficult. But if you're worried about malicious kernel code, don't run it in the first place: even without dynamic code generation, it's easy to hide a backdoor, especially if the driver is controlling hardware that you don't know inside and out.

If you don't trust kernel code, don't run it. If you want to analyze code that's potentially malware, run it in a virtual machine that's running on airgapped hardware, or on airgapped hardware with a hardware debugger (because the malware might detect the virtual machine and remain dormant).