[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 23 Aug 2022 21:27:38 +0200
From: Solar Designer <solar@...nwall.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: how to guard a kernel module
Hi,
On Tue, Aug 23, 2022 at 10:20:13AM +0800, ??????(??????) wrote:
> I have a security related module , which is compiled as CONFIG_XYZ=m. And I want to monitor and guard it with LKRG, just as that LKRG guards SELinux and Seccomp.
> I added some codes to LKRG , and wrapped them by #ifdef CONFIG_XYZ ... #endif, but this seemed to not work.
If you integrated your module into the kernel tree and are building LKRG
against kernel headers from that configured tree, it should work.
Otherwise, it should not. Your "seemed to not work" is non-specific -
does the code within the #ifdef CONFIG_XYZ ... #endif get compiled at
all? You can test by temporarily introducing a #error in there.
> I also tried if(!strcmp(CONFIG_XYZ, "m")), but error occurred
Of course. This shouldn't work.
> as "error: 'CONFIG_XYZ' undeclared (first use in this function);".
While the above was very wrong and shouldn't have worked anyway, the
specific error message tells us that CONFIG_XYZ was also not defined as
a preprocessor macro, which it should have been. (If it were, the error
or maybe warning message here would have been different.)
My best guess is you're not building LKRG against the right kernel
headers, or they're from a non-configured kernel tree.
> Maybe this issue has little to do with LKRG, and I am sorry if bothering you.
Yes, the above has almost nothing to do with LKRG.
> Any suggestion is very appreciated.
LKRG protects other modules' code and read-only data on its own. As to
also protecting your module's global variables - which you seem to want,
given your examples - you could instead introduce a usually-read-only
page within your module, similar to LKRG's "p_ro". Then your module can
protect it to the same extent that LKRG protects its. However, you
might find implementing a usually-read-only page like that, and doing it
right, too difficult. So this is just to give you an alternative.
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.
