Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 13 Nov 2019 09:17:54 +0100
From: Adam Zabrocki <>
Subject: Re: module loading / systemd bug report / suggestion


On Sun, Nov 10, 2019 at 04:45:00PM +0000, Patrick Schleizer wrote:
> # systemd unit install script
> scripts/bootup/systemd/ does not work out of the box for
> me in Debian 10 / buster.
> user@...ian-buster-standalone:~/lkrg-0.7$ systemctl show -p UnitPath |
> cut -d " " -f5
> /run/systemd/system
> user@...ian-buster-standalone:~/lkrg-0.7$ sudo systemctl show -p
> UnitPath | cut -d " " -f5
> /run/systemd/system
> Location /run/systemd/system is non-persistent. Hence, this won't work
> after reboot.
> sudo systemctl --no-pager show -p UnitPath
> UnitPath=/etc/systemd/system.control /run/systemd/system.control
> /run/systemd/transient /etc/systemd/system /run/systemd/system
> /run/systemd/generator /lib/systemd/system /run/systemd/generator.late
> What however did work for me what the following:
> sudo cp scripts/bootup/systemd/lkrg.service /lib/systemd/system/
> sudo systemctl daemon-reload
> sudo sysetmctl enable lkrg.service
> sudo systemctl start lkrg.service

Right, that was a desired path. Some distros are using "prefix" for the default 
systemd unitpath (e.g. RedHat'ish). However, it looks like that newer distros 
add more possible UnitPath which makes current logic not accurante on such 
environment. I've seen the same behaviour on a newer Ubuntu (18+).

One of the solution which I can see now is to use "pkg-config" to extract 
appropiate path. However, it is not always installed:

Fedora 31:
    [pi3@...alhost ~]$ pkg-config systemd --variable=systemdsystemunitdir
    [pi3@...alhost ~]$

Debian 10:
    pi3@...ian:~$ pkg-config systemd --variable=systemdsystemunitdir
    -bash: pkg-config: command not found

I would prefer to avoid having script depended on package which might not 
always be installed.

Nevertheless, "pkg-config" is just extracting / parsing configuration file. I 
might try to update script with the following logic:

Fedora 31:
    [pi3@...alhost ~]$ cat "/usr/share/pkgconfig/systemd.pc"|grep rootprefix\=
    [pi3@...alhost ~]$ cat "/usr/share/pkgconfig/systemd.pc"|grep systemdsystemunitdir\=
    [pi3@...alhost ~]$

Debian 10:
    pi3@...ian:~$ cat "/usr/share/pkgconfig/systemd.pc"|grep rootprefix\=
    pi3@...ian:~$ cat "/usr/share/pkgconfig/systemd.pc"|grep systemdsystemunitdir\=

It should be fine in most environment. What do you think?

> # module loading
> Another approach would be to not use a systemd unit file but instead
> system'd /usr/lib/modules-load.d mechanism.
> A drop-in configuration file snippet in folder /usr/lib/modules-load.d
> i.e. /usr/lib/modules-load.d/p_lkrg with contents:
> p_lkrg
> Works for me on Debian 10, buster. I think that way the module gets
> loaded even earlier, which should be even better.
> I am considering to use that mechanism for the Debian packaging that I
> am planning. Unless there is a reason not to use this approach.

Interesting. I was not aware about that feature. However, I can see a few 

 1. You should probably provide argument to the LKRG module to change default 
log level (1) to be 0. During the boot, kernel might generate a lot of events 
which forces LKRG doing verification and you might receive a lot of "System is 
clean!" messages. It can be configured via p_init_log_level argument.
 2. I believe you would still want to have systemd service file which could (in 
the later phase of booting) reconfigure LKRG via sysctl interface (like it is 
doin now).

> # module unloading
> scripts/bootup/systemd/lkrg.service uses "ExecStop=/sbin/rmmod p_lkrg".
> Why unload the kernel module at shutdown? Perhaps malware could
> specifically target to run after that moment? Any reason to unload?
> Could just keep the module?

The reason why we have "ExecStop" is to provide convinient way of managing LKRG 
via 'service' interface. E.g. if you want to update LKRG to the newer version, 
you can execute from the LKRG folder just the following commands:

make uninstall
make install

under-the-hood old LKRG will be unloaded (via 'systemctl stop lkrg.service' + 
'systemctl disable lkrg.service' command).

You might also want to stop LKRG for some reasons and reenable it again later. 
This is an easy way of doing it.

Of course you are right that it is not ideal. The best would be to not have 
unloading feature at all (which is possible to achieve from the simple 
source-code modification) and at the same time set LKRG to the 'hiding mode'.

> # install section
> [Install]
> I am not sure that should be

My knowledge of 'systemd' service is limited. If I understand it correctly, you 
are suggesting to load LKRG at the ealier stage, correct?


> Kind regards,
> Patrick

pi3 (pi3ki31ny) - pi3 (at) itsec pl

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.