COMP3000 Operating Systems W25: Tutorial 7 - Revision history

Lianyingzhao: Created page with "In this tutorial you'll be learning about 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. You can also have a better understanding of special files by doing so. ==General Instructions (same for all tutorials)==
Click on Expand to view.

2025-03-03T03:12:54Z

Created page with "In this tutorial you'll be learning about 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. You can also have a better understanding of special files by doing so. ==General Instructions (same for all tutorials)== <div class="mw-collapsible mw-collapsed"> Click on Expand to view. <div class="mw-..."

New page
In this tutorial you'll be learning about 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. You can also have a better understanding of special files by doing so.

==General Instructions (same for all tutorials)==

<div class="mw-collapsible mw-collapsed">
Click on Expand to view.
<div class="mw-collapsible-content">
Tutorials are graded based on participation and effort ('''so no need to struggle to have the “correct” answers — what matters is the attempts and sufficient thinking reflected in your answers'''). Submit your answers on Brightspace as a single text file named "<username>-comp3000-t<n>.txt" (where username is your MyCarletonOne username and n is the tutorial number). The first four lines of this file should be "COMP 3000 Tutorial <n>", your name, student number, and the date of submission. Your submitted answers must at least respond to all the items in the '''Tasks/Questions''' section and include your thinking and exploration (or even confusion) for each question.

The deadline is usually four days after the tutorial date (see the actual deadline on the submission entry under Tools -> Assignments). 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. 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.

Read through the instructions before starting your work to get an overall picture. When source files are needed, you can download them by clicking on the hyperlink.
</div>
</div>

==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 <tt>scp</tt> or <tt>sshfs</tt> 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 [[COMP3000 Operating Systems W25: Tutorial 7 Not Using SCS OpenStack | 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===
# 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 <tt>/dev/urandom</tt>? Remember you can get output from <tt>/dev/urandom</tt> using <tt>cat</tt> or <tt>dd</tt>. If you use <tt>cat</tt>, make sure to pipe it to <tt>less</tt>!
#* <tt>cp /dev/urandom f1</tt> (hit Ctrl+C right away to avoid a huge file)
#* <tt>sudo cp -a /dev/urandom f2</tt>
#* <tt>sudo mknod f3 c 1 9</tt>
#: 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.
# Make named pipes using <tt>mknod</tt> and <tt>mkfifo</tt>. Use them to simulate <tt>ls | wc</tt> using just the '>' and '<' operators.
# Use <tt>mknod</tt> to make a copy of your current terminal's tty - <tt>/dev/tty</tt> (Hint: consider how you did something similar with <tt>/dev/urandom</tt> above). You can name it <tt>mytty</tt>. Examine its characteristics using <tt>stty --file=mytty</tt>. Do the same for the original tty.
# Run <tt>stty --help</tt> 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 <tt>task_struct</tt>'s in the Linux kernel, what kind of information is stored in a task struct, and how to access the <tt>task_struct</tt> of a process.

===Tasks part B: A simple kernel module===
Download the source for this [https://people.scs.carleton.ca/~lianyingzhao/comp3000/w25/tut7/simple.tar.gz simple module], unpack, and build it by typing "<tt>make</tt>". You can safely ignore the warning of "Skipping BTF generation..." if encountered.
# Install the module using "<tt>sudo insmod simple.ko</tt>". The hello message is recorded in the kernel logs. How do you view the kernel logs? How many ways are there to view them?
# Check to see that the module has been loaded. How do you do this?
# Remove the module from the kernel. What did you do?

===Tasks part C: A character device kernel module (driver)===
Download the source for [https://people.scs.carleton.ca/~lianyingzhao/comp3000/w25/tut7/ones.tar.gz ones], a kernel module implementing a character device that outputs an unbounded string of "1"'s. Build, compile, and run it as before.
# What kernel messages does the module generate? Does it create any new files (other than <tt>/dev/ones</tt>)? If so, where? (Hint: search in <tt>/sys</tt>)
# What happens when you "cat" the device <tt>/dev/ones</tt>? How can you limit the output in more than one way?
# Add more <tt>printk()</tt>’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 [https://people.scs.carleton.ca/~lianyingzhao/comp3000/w25/tut7/newgetpid.tar.gz 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
# What type is "<tt>current</tt>"? <u>How</u> can you figure this out?
# Modify newgetpid.c so that it creates a device file <tt>/dev/describe</tt> rather than <tt>/dev/newgetpid</tt>.
# Make <tt>/dev/describe</tt> output the calling process's parent ID (ppid), user ID (uid), group ID (gid), effective user ID (euid), and effective group ID (egid).

==Using <tt>bpftrace</tt> 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 [https://people.scs.carleton.ca/~lianyingzhao/comp3000/w25/tut7/kmsnoop.bt kmsnoop.bt] and make it executable with <tt>chmod 755 kmsnoop.bt</tt>.

Now, you can open a separate SSH session and run it with <tt>sudo ./kmsnoop.bt</tt>. 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 <tt>tmux</tt> (which we learned in Tutorial 1).

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