[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200502175111.GA26837@openwall.com>
Date: Sat, 2 May 2020 19:51:11 +0200
From: Solar Designer <solar@...nwall.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: fake alert (?)
On Sat, May 02, 2020 at 01:54:22PM +0200, Solar Designer wrote:
> On Sat, May 02, 2020 at 11:41:17AM +0300, Nikolay Zorin wrote:
> > and also: I tried the last commit of the SRC, where didn't work on
> > CentOS 6.10, on VmWare 6.7 and CentOS 7.4 - work, no warn\error
> >
> > I update src from git (commit
> > 'c8e18884a6bb18b4ddcccfd9c2776e4c3472392f', from 'Date: Fri May 1
> > 21:59:28 2020 -0400') and.. and on KVM CentOS 6.10 (version KVM is
> > 0.12.1.2-2.491) kernel with this module work,
>
> I find the above confusing. First you say that "the last commit of the
> SRC" didn't work on CentOS 6.10, then you say "I update src from git"
> and it works "on KVM CentOS 6.10". What has changed between these two?
> Different hypervisors? Anything else?
>
> When you list CentOS versions, are those always the guest kernels?
Nikolay explained this to me off-list and in Russian. I'll summarize:
The various CentOS versions, etc. were in all cases run on the hosts.
Ultimately, the choice of host OS and hypervisor did not matter.
The guest system (with LKRG) was in all cases the one Nikolay mentioned
in his very first message in here:
---
# uname -a
Linux auto 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1.swm.3 (2020-04-27) x86_64 GNU/Linux
standard Debian + 'AppArmor' and remove IPv6 (himself rebuild)
---
Nikolay built LKRG into that Debian kernel image, not loading LKRG as a
module, which took him some Makefile changes to do. Then the kernel
would lock up on bootup. Nikolay further solved that by changing our
module_init to late_initcall_sync (he also says simple late_initcall
didn't help), so that LKRG initialization is postponed. Then the system
booted and started producing those JUMP_LABEL update warnings (which are
OK). Overall, that's an interesting accomplishment and could be useful
to us or to other LKRG users who might want LKRG linked into the kernel.
My understanding is that Nikolay got LKRG working properly (even if in a
way different from how we intended it), and doesn't currently need any
help from us. Except maybe:
This also reminds us that ideally we should release some "vulnerable"
kernel modules and "exploits" against those just sufficient for testing
of LKRG's protections, which is (even more) important for users to do
when they've modified LKRG or installed it in ways different from how we
test it.
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.
