[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180730202623.GA24767@pi3.com.pl>
Date: Mon, 30 Jul 2018 22:26:23 +0200
From: Adam Zabrocki <pi3@....com.pl>
To: lkrg-users@...ts.openwall.com,
krzysztof ciechanowski <krzysztofci@...il.com>,
Krzysztof Kulesza <krzysztof@...esza.eu>
Subject: Re: LKRG 0.3: ERROR: No buffer space available
Hello,
I would like once again to point out that any emails sent to this mailing
list MUST be in English. This is an official mailing list for the LKRG
project and many subscribers are international (don't speak and understand
Polish).
I have reproduced your environment (Slackware 14.2) and I've tested following
slackware precompiled kernels:
- 4.4.14
- 4.14.56
Both of them are problematic and reproduce your problem. The root of the
problem can be summarized via following LKRG message:
[ 530.104889] [p_lkrg] [kretprobe] register_kretprobe() failed! [err=-38]
[ 530.104889] [p_lkrg] ERROR: Can't hook execve syscall :(
register_kretprobe() functions returns -38 code which is:
/*
* This error code is special: arch syscall entry code will return
* -ENOSYS if users try to call a syscall that doesn't exist. To keep
* failures of syscalls that really do exist distinguishable from
* failures due to attempts to use a nonexistent syscall, syscall
* implementations should refrain from returning -ENOSYS.
*/
#define ENOSYS 38 /* Invalid system call number */
This can only be possible if KPROBES are not compiled in the kernel (LKRG is
heavily depended on KPROBES):
#ifdef CONFIG_KRETPROBES
...
#else /* CONFIG_KRETPROBES */
int register_kretprobe(struct kretprobe *rp)
{
return -ENOSYS;
}
EXPORT_SYMBOL_GPL(register_kretprobe);
...
#endif /* CONFIG_KRETPROBES */
Both of the slackware precompiled kernels do not configure this option:
root@pi3:/boot# cat /etc/slackware-version
Slackware 14.2
root@pi3:/boot# uname -a
Linux pi3 4.14.56 #1 SMP Wed Jul 18 00:08:10 CDT 2018 x86_64 Intel(R)
Core(TM) i5-7300U CPU @ 2.60GHz GenuineIntel GNU/Linux
root@pi3:/boot# cat config-huge-4.14.56.x64 |grep CONFIG_KRETPROBES
root@pi3:/boot# cat config-huge-4.14.56.x64 |grep CONFIG_KPROBES
# CONFIG_KPROBES is not set
root@pi3:/boot# cat config-huge-4.4.14 |grep CONFIG_KRETPROBES
root@pi3:/boot# cat config-huge-4.4.14 |grep CONFIG_KPROBES
# CONFIG_KPROBES is not set
root@pi3:/boot#
Moreover, both of the kernels are not compiled with JUMP_LABEL option:
root@pi3:/boot# cat config-huge-4.14.56.x64 |grep JUMP_LABEL|head -1
# CONFIG_JUMP_LABEL is not set
root@pi3:/boot# cat config-huge-4.4.14 |grep JUMP_LABEL|head -1
# CONFIG_JUMP_LABEL is not set
root@pi3:/boot#
which has 2 side effects:
- kernel .text section is static and is not self-modified (as opposite to
all distro kernels which I'm aware of)
- these kernels do not support dynamic kernel tracing, neither debug/probing:
root@pi3:/boot# ls -al /sys/kernel/debug/
total 0
dr-xr-xr-x 2 root root 0 Jul 22 19:42 ./
drwxr-xr-x 12 root root 0 Jul 22 07:37 ../
root@pi3:/boot#
In short, LKRG can't run on the kernels without CONFIG_KPROBES /
CONFIG_KRETPROBES.
Thanks,
Adam
On
Thu, Jul 19, 2018 at 11:37:58AM +0200, Adam Zabrocki wrote:
> Hello,
>
> Thanks for your emails and reporting these issues, but I would like to point
> out that any emails sent to this mailing list MUST be in English. This is an
> official mailing list for the LKRG project and many subscribers are
> international (don't speak and understand Polish).
>
> Both of your problems might be completely different (but don't need to be), but
> to be able to better understand them I need more information:
>
> 1) Are you using custom compiled kernel or default one from the distro package?
> 2) What is exact kernel version which you use?
> a) Krzysztof Kulesza is using Linux 4.14.55 - did you copy Slackware 14.2
> kernel configuration by hand and manually recompile / compile the kernel or did
> you use standard kernel package?
> b) Krzysztof Ciechanowski is using 4.17.7-041707-generic SMP but is it custom
> compilation? If not which distro kernel are you using?
>
> LKRG module has a parameter p_init_log_level (which looks like you are aware
> of) which defines default log_level which is going to be used during
> initialization. You can read more about log_level option (and in general about
> communication channel) here:
>
> http://openwall.info/wiki/p_lkrg/Examples#Communication-channel
>
> In short it might be a number between 0-4 or 0-6 (if debugging compilation was
> used). As far as I see you've been using number 3, can you please use at least
> number 4? It will give more information about the root of the problem. If debug
> option is enabled number 5 and 6 is also available but you need to be carefully
> using it to not spam the kernel with too many logs.
>
> If you try to load kernel with log_level at least 4, can you forward me what
> kernel logs says so I could find out what is the place of failing
> initialization process?
> a) Krzysztof Kulesza - in you case it looks like LKRG can find an "execve"
> syscall:
> [p_lkrg] [kretprobe] register_kretprobe() failed! [err=-38]
> [351270.013461] [p_lkrg] ERROR: Can't hook execve syscall :(
> [351270.013537] [p_lkrg] Can't initialize exploit detection features!
> Exiting...
>
> If you see in the logs failure like that (can't hook specific syscall), can
> you please run the following command:
>
> # cat /proc/kallsyms | grep
> <name_of_the_function_which_faild_during_init_process>
>
> so in your case would be:
>
> # cat /proc/kallsyms | grep execve
>
>
> I would be happy to take a look what's going on.
>
> <-- in Polish -->
> Witam,
>
> Jezeli angielski jest problematyczny na tyle ze uniemozliwa komunikacje, bylbym
> wdzieczny jesli maile po polsku nie bylyby wysylane na oficjalna liste
> mailingowa projektu - prosze uzyc mojego prywatnego maila.
> Mam nadzieje ze moja odpowiedz po angielsku jest zrozumiala i bedziecie mogli
> dostarczy dodatkowych informacji, ktore potrzebuje ;)
> <-- Done -->
>
> Thanks,
> Adam
>
>
> On Wed, Jul 18, 2018 at 10:20:13AM +0200, Krzysztof Kulesza wrote:
> > W dniu 18.07.2018 o 02:06, krzysztof ciechanowski pisze:
> > > Witam, pierwszy raz na grupie, mój angielski nie jest najwyższym
> > > poziomie więc nie będę silić się na jego używanie. proszę więc o
> > > wyrozumiałość.
> > > Mam problem z zainstalowaniem LKRG zarówno w wersji 0.3 jak i 0.2.
> > > Instalacji próbowałem dokonać zarówno za pomocą gita jak i za pomocą
> > > udostępnionych na stronie projektu paczek.
> > > Niestety efekt za każdym razem jest podobny, mianowicie LKRG się
> > > kompiluje jednak próba jego zainstalowanie kończy się błedem jak w
> > > temacie.
> > >
> > > /~/Pobrane/lkrg-0.3 $ *modinfo output/p_lkrg.ko*/
> > > /filename: /home/krzysztof/Pobrane/lkrg-0.3/output/p_lkrg.ko/
> > > /license: GPL v2/
> > > /description: pi3's Linux kernel Runtime Guard/
> > > /author: Adam 'pi3' Zabrocki (http://pi3.com.pl)/
> > > /srcversion: 7A8F37A00C10B94C369A1D1/
> > > /depends: /
> > > /retpoline: Y/
> > > /name: p_lkrg/
> > > /vermagic: 4.17.7-041707-generic SMP mod_unload /
> > > /parm: p_init_log_level:Logging level init value [1 (alive)
> > > is default] (uint)/
> > > /
> > > /
> > > /~/Pobrane/lkrg-0.3 $//*sudo insmod output/p_lkrg.ko p_init_log_level=3*/
> > > /insmod: ERROR: could not insert module output/p_lkrg.ko: No buffer
> > > space available/
> > >
> > > Instalacji próbowałem dokonać z różnymi wersjami kernela, niestety bez
> > > zmian. Sam komunikat błędu niewiele mi mówi, google tez niewiele pomaga.
> > > Proszę o pomoc w rozwiązaniu problemu.
> >
> > Witam
> > Mam taki sam błąd.
> > Kernel 4.14.55 na Slackware 14.2 (domyślny konfig ze Slackware)
> >
> > Linux 4.14.55 #1 SMP Wed Jul 11 19:33:43 CDT 2018 x86_64 Intel(R)
> > Xeon(R) CPU E3-1230 V2 @ 3.30GHz GenuineIntel GNU/Linux
> >
> > # modprobe p_lkrg p_init_log_level=3
> > modprobe: ERROR: could not insert 'p_lkrg': No buffer space available
> >
> > # dmesg [351270.009351] [p_lkrg] Loading LKRG... [351270.013460]
> > [p_lkrg] [kretprobe] register_kretprobe() failed! [err=-38]
> > [351270.013461] [p_lkrg] ERROR: Can't hook execve syscall :(
> > [351270.013537] [p_lkrg] Can't initialize exploit detection features!
> > Exiting...
> >
> > --
> > Krzysztof Kulesza
> >
>
>
>
> --
> pi3 (pi3ki31ny) - pi3 (at) itsec pl
> http://pi3.com.pl
--
pi3 (pi3ki31ny) - pi3 (at) itsec pl
http://pi3.com.pl
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.
