This is an old revision of the document!
(Click here to return to main LKRG page)
LKRG is free and Open Source project distributed primarily in source code form. You can download it and prepare custom build by yourself. However, if you would rather use a commercial product tailored for your specific operating system, please consider LKRG Pro, which is distributed primarily in the form of “native” packages for the target operating systems and in general is meant to be easier to install and use while delivering optimal performance. Additionally, you will help in development of the project (economically). LKRG Pro is available <here>.
After successfull compilation of the project, “output” directory is created with the following files:
This is the core of the project. Module itself accepts one parameter which determines the default logging level. By default, it is “active” level (levels will be described in details in the next section). Each level of logging is represented by numbers. By providing numbers between 0-4 or 0-6 (if compiled with debugging option) LKRG will immediately use this level even during installation in the kernel memory. It is a very useful option for debugging purpose when LKRG encounters a problem during installation in the system:
Installation of LKRG is exactly the same as loading normal kernel module. As soon as system is installed it starts the work. If default logging level is used, LKRG produces one short sentence saying that system is clean unless corruptions are detected. Otherwise LKRG informs where corruption happened, e.g.:
If system is started with more detailed log level, more information will be visible, e.g.:
(this is not the latest version of the project so might not have acquired all information)
If debugging compilation is available, it may produce enormous amount of information regarding the running system (including every function name where LKRG is entering and leaving, etc.). Sometimes even default “active” log level might be too noisy (every time when LKRG checks the system, one-line status information will be produced in case the system is clean). That’s why “none” log level option was introduced. System at that log level is quiet until abnormal situation is detected by LKRG. In that case only alerting logs will be produced.
The project has built in a sysctl interface which enables the interaction between the administrator and LKRG. By default 4 different options are available:
root@pi3-ubuntu:~/p_lkrg-main# sysctl -a|grep lkrg lkrg.block_modules = 0 lkrg.clean_message = 1 lkrg.force_run = 0 lkrg.log_level = 1 lkrg.timestamp = 15
Here is an example of how to use the blocking module functionality:
root@pi3-ubuntu:~/p_lkrg-main# sysctl lkrg.block_modules=1 lkrg.block_modules = 1 root@pi3-ubuntu:~/p_lkrg-main# rmmod btrfs rmmod: ERROR: Module btrfs is not currently loaded root@pi3-ubuntu:~/p_lkrg-main# modprobe btrfs modprobe: ERROR: could not insert 'btrfs': Operation not permitted root@pi3-ubuntu:~/p_lkrg-main# modprobe btrfs modprobe: ERROR: could not insert 'btrfs': Operation not permitted root@pi3-ubuntu:~/p_lkrg-main# modprobe btrfs modprobe: ERROR: could not insert 'btrfs': Operation not permitted root@pi3-ubuntu:~/p_lkrg-main# sysctl lkrg.block_modules=0 lkrg.block_modules = 0 root@pi3-ubuntu:~/p_lkrg-main# modprobe btrfs root@pi3-ubuntu:~/p_lkrg-main# rmmod p_lkrg
It is possible to compile LKRG project with “hiding” feature. In that case LKRG exports an extra option via sysctl interface to hide itself in the system:
Unhiding functionality is a bit of complex operation if module was previously hidden. LKRG module object is synthetically created (which implies some referenced values are incorrect) and it is linked again in proper linked lists. After all, you can safely unload LKRG but you must use ”–force” option. Example:
root@pi3-ubuntu:~/p_lkrg-main# sysctl -a |grep lkrg lkrg.block_modules = 0 lkrg.force_run = 0 lkrg.log_level = 1 lkrg.timestamp = 15 lkrg.hide = 0 root@pi3-ubuntu:~/p_lkrg-main# lsmod|grep p_ p_lkrg 94208 0 root@pi3-ubuntu:~/p_lkrg-main# sysctl lkrg.hide=1 lkrg.hide = 0 root@pi3-ubuntu:~/p_lkrg-main# lsmod|grep p_ root@pi3-ubuntu:~/p_lkrg-main# sysctl lkrg.hide=0 lkrg.hide = 1 root@pi3-ubuntu:~/p_lkrg-main# lsmod|grep p_ p_lkrg 94208 -2 root@pi3-ubuntu:~/p_lkrg-main# rmmod --force p_lkrg root@pi3-ubuntu:~/p_lkrg-main#
Linux boots UP kernel as long as the system has only 1 (V)CPU with 1 core. However, if hot-plugging (V)CPU is supported, OS during run-time might decide to boot SMP kernel without restarting the entire OS when a new (V)CPU or core appears. This is very critical situation from the LKRG point of view – mainly because hashes from the most sections will change. Some of the functionalities are different for UP and for SMP. LKGP takes this into account and correctly rebuilds internal database as soon as this situation happens. It can be seen as follows:
Let’s add 1 more VCPU:
New CPU was correctly added but it is still in offline state:
We must change cpu1 status to online to make it work and initialize. If we do it, we can see following:
As soon as 2nd CPU became online, kernel switched to SMP code, and boot itself on SMP configuration via “smpboot” process. This operation also forced some modules to be reloaded and since LKRG was configured with enabled “blocking modules” feature, it blocked these operations. Additionally, LKRG added new CPU’s critical metadata to the database for individual protection. It will send now IPI to each CPU individually, forcing them to run checking routine. If we enable debugging option (doesn’t need to be strong debug), we can see in logs it is really happening (LKRG logs):
LKRG also correctly handles hot-unplugging CPUs or making them offline:
LKRG logs:
Again, if we enable the debug logs we can see offline CPU is present but not active and metadata only from 1 CPU is protected (but offline CPU’s state is still protected):