KEDR 0.6: can I monitor ioctls called from UM to KM using this?

[Jinay Patel]

Hello,

I recently was trying out some stuffs where I can monitor each ioctl calls made from UM to my KM and try introduce fault in this before it get passed to the KM.

I have read lots of customization stuffs for KM calling system calls, but is this tool is capable for other system calls which Linux Kernel provides to be called from UM as well??

I have other question as well, I was wondering that How KEDR is different than kmemleak?

Thanks,
Jinay

[Evgenii Shatokhin]

Hi,

On 14.09.2016 16:36, Jinay Patel wrote:
> Hello,
>
> I recently was trying out some stuffs where I can monitor each ioctl
> calls made from UM to my KM and try introduce fault in this before it
> get passed to the KM.
>
> I have read lots of customization stuffs for KM calling system calls,
> but is this tool is capable for other system calls which Linux Kernel
> provides to be called from UM as well??

If I understand it correctly, you need a tool that could make the ioctl
calls fail before they get passed to your kernel module. ioctl() syscall
is processed by VFS layer first and VFS should dispatch it to the
appropriate kernel module.

So, the failure could be injected either into the "ioctl" system call
itself or somewhere into the VFS.

I think, this is not doable with KEDR. At the moment, KEDR can only
operate on the modules but both the syscalls and the VFS layer are in
the kernel proper rather than in a module.

>
> I have other question as well, I was wondering that How KEDR is
> different than kmemleak?

The differences stem from the fact that these tools monitor the kernel
from the different points of view:

* Kmemleak is integrated into the memory allocation system;
* LeakCheck tool from KEDR looks which functions a particular kernel
module calls.

Here are some of the differences:

* Kmemleak monitors the whole kernel (and incurs the corresponding
overhead). KEDR LeakCheck monitors the given module only and the
performance overhead is for that module only.

* Kmemleak may detect more slab allocations than KEDR LeakCheck in some
cases but it cannot track page allocations (e.g., alloc_pages_*()).
KEDR LeakCheck tracks page allocations well.

* To enable Kmemleak, you may need to rebuild the kernel. For KEDR,
rebuilding the kernel is usually not needed.

Another difference is that KEDR is currently for x86 only while Kmemleak
is also supported on arm, etc.

>
> Thanks,
> Jinay

Regards,
Evgenii