[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200604211513.GA25352@openwall.com>
Date: Thu, 4 Jun 2020 23:15:13 +0200
From: Solar Designer <solar@...nwall.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: Support for 5.7 linux kernel?
On Thu, Jun 04, 2020 at 04:27:29PM +0200, Adam Zabrocki wrote:
> On Thu, Jun 04, 2020 at 12:37:21PM +0200, Solar Designer wrote:
> > Maybe we need to support LKRG build without CONFIG_MODULE_UNLOAD, by
> > conditionally excluding the corresponding functionality from LKRG as
> > well. Adam, what do you think?
>
> In theory we can, however I haven't seen any kernel in the production which
> allows to dynamically load kernel module but disabled CONFIG_MODULE_UNLOAD.
> There are significant side effects of having kernel like this and the way how
> kernel enumerates such modules is also slightly different.
Do I understand you correctly that LKRG's logic where it verifies
integrity of the loaded module list would have to be different in builds
without CONFIG_MODULE_UNLOAD? If so, yes, it might not be worth the
added complexity to support this rare kernel configuration. We could
exclude the module list checking from such builds of LKRG, which is
probably easy, but it's also probably unexpected that LKRG would be in
any way weaker when CONFIG_MODULE_UNLOAD is disabled.
> I think we should add to the code verification if specific CONFIG_* options are
> enabled. In such case, people would immediately see which options they are
> missing. I might create patch for that.
Right. Thanks!
Alexander
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.
