[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191113081754.GA29628@pi3.com.pl>
Date: Wed, 13 Nov 2019 09:17:54 +0100
From: Adam Zabrocki <pi3@....com.pl>
To: lkrg-users@...ts.openwall.com
Subject: Re: module loading / systemd bug report / suggestion
Hi,
On Sun, Nov 10, 2019 at 04:45:00PM +0000, Patrick Schleizer wrote:
> # systemd unit install script
>
> scripts/bootup/systemd/lkrg-systemd.sh 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
/usr/lib/systemd/system
[pi3@...alhost ~]$
Debian 10:
pi3@...ian:~$ pkg-config systemd --variable=systemdsystemunitdir
-bash: pkg-config: command not found
pi3@...ian:~$
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\=
rootprefix=/usr
[pi3@...alhost ~]$ cat "/usr/share/pkgconfig/systemd.pc"|grep systemdsystemunitdir\=
systemdsystemunitdir=${rootprefix}/lib/systemd/system
[pi3@...alhost ~]$
Debian 10:
pi3@...ian:~$ cat "/usr/share/pkgconfig/systemd.pc"|grep rootprefix\=
pi3@...ian:~$ cat "/usr/share/pkgconfig/systemd.pc"|grep systemdsystemunitdir\=
systemdsystemunitdir=/lib/systemd/system
pi3@...ian:~$
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
caveats:
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]
> WantedBy=multi-user.target
>
> I am not sure that should be WantedBy=sysinit.target.
>
My knowledge of 'systemd' service is limited. If I understand it correctly, you
are suggesting to load LKRG at the ealier stage, correct?
Thanks,
Adam
> Kind regards,
> Patrick
--
pi3 (pi3ki31ny) - pi3 (at) itsec pl
http://pi3.com.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.
