CS380L: Advanced Operating Systems

Lab #0

The goal of this assignment is to be able to compile and boot the Linux kernel on the KVM-qemu virtual machine.  If you have never built or installed a kernel before then please start this assignment early. We will use the Ubuntu distribution of Linux.

There are three parts to this system: the KVM-qemu virtual machine, the virtual machine's disk image, and your own build of the Linux kernel. Modern versions of Linux allow you to boot another version of Linux inside a virtual machine. In order to boot Linux you need something that looks like a disk that has all of the programs and the file system that Linux needs in order to run. Finally, we want to play with the kernel, so we want to compile it ourselves.

Unfortunately, the CS machines do not support KVM, so you will need to find a machine that does. If you can't find one, let us know.

Getting a VM running in KVM

• Get a VM with a copy of the latest LTS release of Ubuntu running in KVM on your machine
• The easiest way to create a virtual machine is to use VMBuilder (documentation available online). Make sure you include the openssh-client package if you build a VM yourself.
• If you don't want to go through the process of creating your own VM, you can use one that we have pre-made for you. (Details available on Piazza.)

You should be able to get your VM running inside KVM by specifying the location of the VM with -drive. You may want to append --snapshot after the file name of your VM. This ensures that no changes are made to your image during an execution so you can do something dangerous and have the original image file preserved.

Once you've been able to get your VM running inside KVM, try installing a package using aptitude to verify your VM has network access.

Obtaining and building the kernel

Download the latest Linux kernel release from kernel.org.

• Extract the source into <kernel dir>. (<kernel dir> is an absolute path)
• Create a separate build directory <kbuild>. (You can build the kernel in its source directory, but it is a bit more wieldy to use a separate build directory.)
• In <kbuild>, run

  yes "" | make -C <kernel dir> O=$(pwd) config

• This makes a configuration file with the default options selected.
• Make sure in your config file that CONFIG_SATA_AHCI=y. This builds the SATA disk driver into the kernel, it is not built as a module. That will allow your kernel to boot off a (virtual) SATA drive without having to load a module to do it.
• Next build the kernel by running make in <kbuild>. (Consider researching and using the -j option to speed this up if you have more than 1 core on your machine.)

Installing and Copying Kernel Modules

• Create a separate <install_mod_dir> directory (perhaps a sibling of <kbuild>) that will contain the built kernel modules
• In <kbuild>, execute

  make INSTALL_MOD_PATH=<install_mod_dir> modules_install 

• In <install_mod_dir> you should see one directory-- lib
• Next create a directly on your local file system (<mount_point>) onto which you will mount your VM
• Mount your VM to <mount_point> using guestmount
• cd to <mount_point> and view the contents on your VM's disk to verify that you have mounted it correctly
• Copy all the kernel modules from <install_mod_dir>/lib/modules to <mount_point>/lib/modules
• Now unmount your VM from <mount_point> using fusermount

You can also use nbd to mount a qcow2 image, though I have found it terribly slow.

My favorite trick is to convert the qcow2 to a raw disk image qemu-img convert -O raw test.qcow2 test.raw, and then do a loopback mount mount -o loop,offset=32256 /path/to/image.img /mnt/mountpoint. Loopback mounts are fast.

Here is a good reference on qemu images.

Booting KVM with your new Kernel

• You will need to add -kernel "<kbuild>/arch/x86/boot/bzImage" and -append "root=/dev/sda1 console=ttyS0,115200n8" to the parameters you pass to KVM. (The root parameter specifies where the root partition of the hard disk is and the console parameter adds a serial console at boot so you can see boot messages.)
• If you have trouble booting your VM, you might want to explore some of the other command line options to KVM such as -serial.
• Once the VM has booted completely, you should be able to login and try installing another package from aptitude.

Your writeup

Please complete a short writeup that you will print out and bring to class.

Identify completely your hardware and software.

Explain any changes you made to the kernel build process and why.

Report your qemu command line.

Booting, kernel modules, and discovering devices

Boot the Kernel, and run dmesg to capture the kernel output from the boot. In your writeup, report the wall clock time for your boot, and compare that with the time reported by the kernel. Are they the same? Why or why not?

For each device, quote the parts of the dmesg output that show the kernel discovering that device, and then report what kind of device it is, and how you made your determination. You may also use lspci.Please only quote a maximum of 3 lines.

Tracing the kernel

• Compile the following code, transfer the program to your simulated disk and run the program.

            #include<unistd.h>
            #include<fcntl.h>
            int main()
            {
                int fd = open("/dev/urandom", O_RDONLY);
                char data[4096];
                read(fd, &data, 4096);
                close(fd);
                fd = open("/dev/null", O_WRONLY);
                write(fd, &data, 4096);
                close(fd);
            } 

• Attach gdb to the kernel.
• Set a conditional breakpoint in spin_lock in kernel code that will only stop execution if the above process is running
• To find the PID of the currently executing process from GDB, you will need to inspect (condition on) the value stored in the current_task struct. The current_task struct is accessible at **((struct task_struct**)%GS:current_task).
• You can determine the value of GS by switching to the qemu console (ctrl+alt+shift+2) and executing 'info registers' (you can switch out of the console by using ctrl+alt+shift+1). The kernel has a single value in GS per CPU for its entire execution. In this lab, we only use a single CPU, so the value of GS is a constant.
• You can find out the address of current_task by printing its address from GDB.
• Find three instances of spin_lock being called from three substantially different contexts in the kernel, where you define substantially different. Report exactly how you set the breakpoints, in what functions, how you made sure your process was running, etc. For each of the three calls to spin_lock that you choose, put the minimum number of lines of the kernel backtrace into your report and then summarize what is going on in the kernel in AT MOST two sentences.
• In your write up, briefly explain the difference between /dev/random and /dev/urandom.

Comments

Please think of your report like the papers we are reading for the class. Organize the information that you gathered and present it logically. For example, early in your report specify your experimental platform, including the hardware, the OS, whether you are running qemu or a hypervisor, etc. Include anything relevent to understand the results, but keep your description concise. Of course balancing completeness and concision is difficult, but that balance is generally well accomplished by the (modern) papers we read.

Please report how much time you spent on the lab.