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.