COMP3000 Operating Systems W22: Tutorial 7

From Soma-notes
Jump to navigation Jump to search

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

Tutorials are graded based on participation and effort (so no need to try to have the “correct” answers — what matters is the process), but you should still turn in your work. Even if you have no idea about certain tasks or disagree about something, still make sure to document your confusions/opinions that reflect your thinking about that task. Submit your answers on Brightspace as a single text file named "<username>-comp3000-t7.txt" (where username is your MyCarletonOne username). The first four lines of this file should be "COMP 3000 Tutorial 7", your name, student number, and the date of submission.

The deadline is usually four days after the tutorial date (see the actual due date and time on the submission entry). Note that the submission entry is enforced by the system, so you may fail to get the effort marks even if it is one minute past the deadline.

You should also check in with your assigned TA online (by responding to the poll in the Teams channel tutorials-public or the private channel). Your TA will be your first point of contact when you have questions or encounter any issues during the tutorial session.

You get 1.5 marks for submitting answers that shows your effort and 0.5 for checking in, making this tutorial worth 2 points total.

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.
  • 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, 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:,,

  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).

Download this tiny code and make it executable with chmod 755

Now, you can open a separate SSH session and run it with sudo ./ 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.