COMP3000 Operating Systems F23: Tutorial 7

From Soma-notes
Revision as of 01:43, 25 October 2023 by Abdou (talk | contribs)

In this tutorial you'll be learning about special files and Linux kernel modules, part of which are device drivers. You’ll create several kernel modules and see how to interact with device drivers using special files (e.g., character device) and their file operations as an interface.

Important Tips

  • There is a chance your VM will crash or your ssh session will become unresponsive when messing with the kernel. To recover, you can reboot your VM from the OpenStack web console.
  • Definitely do not under any circumstances attempt this on your own system. This is your last warning.
  • Remember to recompile and insert your module after making changes.
  • Work incrementally and be prepared for your system to crash.
  • It might be wise to code on your own computer and use scp or sshfs to transfer the files to your VM.
  • https://elixir.bootlin.com/linux/latest/source is a great resource for learning about kernel functions and data structures.

Note: although it's highly recommended that you use the openstack instance, if you cannot for a reason, or if you encounter other issues, check out these instructions to see if they help.

Special Files

Before you start, review what you have learned about special files and think about the following questions (no need to answer them): 1) What does a special file represent and what backs it up? 2) Can you have multiple special files that are somehow "the same"? What does it mean to "copy" a special file? 3) How are named pipes different from unnamed pipes and what are their similarities? Take this opportunity to deepen your understanding of special files to prepare you for working with device drivers that support such special files.

Tasks part A: Understanding special files

  1. Try the following commands as a non-privileged user. What does each do? How do the files f1-f3 compare? How do they compare to /dev/urandom? Remember you can get output from /dev/urandom using cat or dd. If you use cat, make sure to pipe it to less!
    • cp /dev/urandom f1 (hit Ctrl+C right away to avoid a huge file)
    • sudo cp -a /dev/urandom f2
    • sudo mknod f3 c 1 9
    Note: If you see any command running for more than a few seconds, hit Ctrl+C right away, check the produced file (often it’s very large) and delete it if not needed.
  2. Make named pipes using mknod and mkfifo. Use them to simulate ls | wc using just the '>' and '<' operators.
  3. Use mknod to make a copy of your current terminal's tty - /dev/tty (Hint: consider how you did something similar with /dev/urandom above). You can name it mytty. Examine its characteristics using stty --file=mytty. Do the same for the original tty.
  4. Run stty --help to see what you can do with stty. Try disabling local echo. How does the shell behave with echo disabled? How can you restore echo without logging out and back in? Recall we did this in the class.

Kernel Modules

In this part of the tutorial you will be building and installing kernel modules. You will need root access to install kernel modules.

It is highly recommended that you use a comp3000 openstack instance for the exercises below for two reasons. First, you may have difficulties compiling kernel modules on other systems. Second, these operations are potentially dangerous, and mistakes could destroy all data on the Linux system. Consider yourself warned!

Before you start, review what you have learned about kernel modules and device drivers, and think about the following questions (no need to answer them): 1) How does the source of kernel modules differ from C programs? 2) How does building kernel modules differ from building userspace C programs? 3) How does invoking the file operations (e.g., read/write) of a special file trigger corresponding functions in a device driver?

You will learn how you can access and manipulate kernel data structures and call kernel functions in a kernel module. You will also understand how processes are represented by task_struct's in the Linux kernel, what kind of information is stored in a task struct, and how to access the task_struct of a process.

Tasks part B: A simple kernel module

Download the source for this simple module, unpack, and build it by typing "make". You can safely ignore the warning of "Skipping BTF generation...".

  1. Install the module using "sudo insmod simple.ko". The hello message is recorded in the kernel logs. How do you view the kernel logs? How many ways are there to view them?
  2. Check to see that the module has been loaded. How do you do this?
  3. Remove the module from the kernel. What did you do?

Tasks part C: A character device kernel module (driver)

Download the source for ones, a kernel module implementing a character device that outputs an unbounded string of "1"'s. Build, compile, and run it as before.

  1. What kernel messages does the module generate? Does it create any new files (other than /dev/ones)? If so, where? (Hint: search in /sys)
  2. What happens when you "cat" the device /dev/ones? How can you limit the output in more than one way?
  3. Add more printk()’s (where you see needed) to find out at which point which functions in ones.c are called and for which purpose.

Tasks part D: Getting process information from a module

Download the source newgetpid.c. Build and run it as before. Hints for the questions below:

https://elixir.bootlin.com/linux/latest/source/include/linux/sched.h, https://elixir.bootlin.com/linux/latest/source/arch/x86/include/asm/current.h, https://elixir.bootlin.com/linux/latest/source/include/linux/cred.h

  1. What type is "current"? How can you figure this out?
  2. Modify newgetpid.c so that it creates a device file /dev/describe rather than /dev/newgetpid.
  3. Make /dev/describe output the calling process's parent ID (ppid), user ID (uid), group ID (gid), effective user ID (euid), and effective group ID (egid).

Using bpftrace to monitor kernel module events

Note: you are not required to write about your experience for this part in the submitted work, but you should still do it, which can help you understand eBPF better (see how simple but still powerful an eBPF program can be).

If you see an error like "Could not resolve symbol" when using bpftrace, you need to apply a fix by installing the dbgsym package of bpftrace: Just wget this file, and run it with 

 sudo apt update
 source install-bpftrace-dbgsym

Download this tiny code kmsnoop.bt and make it executable with chmod 755 kmsnoop.bt.

Now, you can open a separate SSH session and run it with sudo ./kmsnoop.bt. It will wait for events. When you do any "insmod" or "rmmod" in the other session, you will see it outputs a line of message.

If you want to avoid opening another SSH window, you can use tmux (a terminal multiplexer) by just typing tmux and hit enter.

To create a new session: press Ctrl-B and C

To move between sessions: press Ctrl-B and N (or P)

How could this save you from doing any printk's in your kernel module code? You can also sudo bpftrace -l | grep for your needed kernel functions (e.g.,printk) to hook to.

Retrieved from "https://homeostasis.scs.carleton.ca/wiki/index.php?title=COMP3000_Operating_Systems_F23:_Tutorial_7&oldid=24573"