[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241030232207.GA31382@openwall.com>
Date: Thu, 31 Oct 2024 00:22:07 +0100
From: Solar Designer <solar@...nwall.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: LKRG in the Linux OS mainline
Hi,
On Tue, Oct 29, 2024 at 12:56:49PM +0100, Yann Loisel wrote:
> Is there any reason for not having LKRG in the Linux kernel mainline ?
Yes, a few reasons:
The current LKRG coding style is unsuitable for submission to mainline.
We need to switch to using the Linux kernel coding style. This is
something we already agreed we'd like to do regardless, it's just not
done yet and we have no specific plans to do it. We're all busy with
something else.
The current LKRG implementation is a hack, as it has to be when it's
out-of-tree. It feels unlikely that a hack that hooks internal kernel
functions via profiling probes will be accepted into the tree as-is
(unless maybe we justify that by other reasons, such as that way of
hooking being harder for exploits/rootkits to undo undetected compared
to LSM function pointer based hooks?)
Submitting to mainline is time-consuming, with no clear outcome until
multiple revisions are made in response to reviewer feedback, and then
some of those revisions may not be in a direction we'd like. OTOH, some
of them may actually help us identify issues and improve the project.
If hypothetically accepted into mainline, further development (at least
of the accepted fork) will be limited to what other kernel developers
find acceptable (or/and we need to also maintain an out-of-tree fork).
One of the concepts implemented by LKRG is "security through diversity".
We'll (partially) lose that if LKRG becomes standard (although it may
not always be enabled, and there may remain an out-of-tree extension or
fork, which could restore this concept and more).
We're planning to make it harder for exploits to find LKRG in memory.
Getting LKRG into the kernel itself goes against that. (A related minor
issue is what pieces of kernel code LKRG reuses. For example, it was
recently suggested that we start using the kernel's SipHash
implementation where available, which we could do easily, but a reason
not to is that it'd become easier for attackers to intercept the SipHash
key, especially after we'd have improved LKRG's hiding abilities, so
it's a change we could end up wanting to revert.)
There are also reasons for getting LKRG into mainline. Some are already
mentioned above, and one additional major reason is that the interfaces
that we use will become official rather than hacks that upstream may and
often does break (to which we currently have to adapt shortly after such
breakage, sometimes with more hacks). Another obvious reason is that
we'd probably gain way more users, and that means more testing and more
feedback and more contributions.
Overall, we currently do not plan to even try getting LKRG into mainline.
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.
