1. Kernel module & Syscall Hijacking
Jeremy Fields

2. Intro Ubuntu 14.04 in Hyper-V Linux-lts-vivid-3.19.0-69
Compile vanilla kernel & load
Create basic module for learning

3. Kernel Module First line: load module 2: View printk line enter
4: remove module
5: view prinkt line exit
Src code
Simple learning exercise

4. Kernel Module
Let’s do some statistics on speed in kernel space vs user space
Right off the bat, almost 2x faster in kernel space for simple “hello world”, but far from a good picture

5. Kernel module How about something a little more complex?
Matrix multiplication + printing result each iteration
Same program in user vs kernel space, doing same work
Kernel space grow pretty consistently (linear) while user space grows faster.
9-10: 10x increase in complexity, 22x increase in time difference

6. Kernel Module
Graph is logarithmic. Graph is showing –difference- in time

7. Kernel Module Far from full picture
Different I/O test would have been nice, but no kernel library for read/writing to FS
Non trivial to write from scratch – out of scope for project
Difference primarily caused by printing result. Basic math (shouldn’t) be impacted by user vs kernel space.
Printing == IO, which requires going from user  kernel space (overhead) and back
When done in kernel space, this is avoided

8. Syscall Hijack Hijacked the sys_open syscall
Responsible for opening files
Rewrites all attempts to open any *.jpg files, to open only 1 specific jpg given as arg when loading module
For learning
Worked off of others work

9. Syscall hijack
To be possible, must compile kernel with CONFIG_DEBUG_RODATA disabled
This disables write protection on kernel protected data structures (i.e. syscall table)
This would module would likely never work in real world scenario

10. SYSCALL Hijack

11. Syscall Hijack

12. Result

13. Summary Kernel space is typically faster than user space
Most userspace programs end up being transferred to kernel space for various common calls anyways
Running code in kernel space avoids this, but in real world should typically never be done due to various concerns
security, kernel performance, stability, etc.
Should only be done in uncommon situation (i.e. custom hardware or driver) and only if fully understanding the risks
Can write module to hijack syscall for amusing effect
Not practical in real world without unpatched vulnerability, or somebody purposefully disabling write protection on kernel data structures
Can hijack any file type
Must be careful when messing with sys_open, as if broken, would not be able to “open” the shutdown program

14. References https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel