Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 21 Jun 2020 17:31:45 +0200
From: Mikhail Morfikov <>
Subject: Re: The lkrg.service for systemd

On 21/06/2020 14:58, Solar Designer wrote:
> There's yet another issue, though: LKRG may take a little while to
> initialize before it's fully monitoring for attacks and enforcing its
> configured policies, yet the boot process may concurrently proceed
> further and e.g. start crond and an exploit from there.
> Do you have suggestions on how to make system boot process wait before
> advancing to a phase where user code may run until LKRG is ready?

The would take care of holding the system boot till 
the LKRG module finish loading. The regular services, like cron, are started 
after the is reached (which is after So 
basically this dependency would do the job with ease.

> What would you suggest we put into the documentation for those wanting
> to use other init systems?  

I don't really know other init systems -- I use Debian on all of my machines,
and this distro (like many others) defaults to systemd, and this move has
been made some years ago. If there are any people who use some other inits, I 
would suggest that they speak about the proper support here, like I do with 

> With the 0.8 release being (hopefully) just around the corner, I think
> switching to /etc/modules-load.d/99-lkrg.conf is too invasive a change
> right now, but perhaps we can change the Before/After lines for now and
> plan on making further changes for 0.9.
>> I would suggest something like:
>>   After=systemd-modules-load.service  # to make sure all other modules are loaded
>>               # to load LKRG as fast a possible
> Can you please test this suggestion of yours and confirm that it works?

I tested, and I had to completely rewrite the systemd.service . Here's how it
looks now:

Description=Linux Kernel Runtime Guard

ExecStart=/sbin/modprobe -v p_lkrg
#ExecStop=/sbin/modprobe -v -r p_lkrg


The *DefaultDependencies* has to be used, since this is early boot service. When
you use it, you have to take care of stopping the service, i.e. to add 
** and ** dependencies. I'm not 
sure what would happen in this case when the two are omitted because there's no 
real service that has to be stopped when system reboots/shutdowns. Anyway, after 
adding them, when system reboots/shutdowns the *ExecStop* command will be 
executed. So I commented it out because removing the module before system reboot
is pointless. Using *After=systemd-modules-load.service* will make sure that 
LKRG will load after any other module does, *Before=systemd-sysctl.service* is 
for sysctl config to work, so if you block module loading via 
*lkrg.block_modules*, it will work. The ** is redundant, 
but I keep it just to explicitly show where the LKRG service is assigned to. I 
also use *modprobe* for *ExecStart* and *ExecStop* commands (the -v flag can be 
removed). I changed the *Type* from *Simple* to *Oneshot as it better fits in 
this case, especially with *RemainAfterExit=yes*. Also *WantedBy* changed from 
** to **.

Here's you can see how it works[1]. This is very beginning of the boot phase, 
and you have first the systemd-modules-load.service , when it finishes, 
lkrg-dkms starts and the module loads for ~1,5s. When it finishes, then 
systemd-sysctl.service is launched and the rest of boot continues as ususal.


Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

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.