Project 1 – Adding a System Call

Due: TBA

This assignment should be done in groups of 2 or 3 people.

Assignment Goals

• To understand the relationship between OS command interpreters (shells), system calls, and the kernel.
• To design and implement an extremely simple system call and run it in your shell.

The Assignment

Part 1: Add a new system call

There are four system calls in Linux related to creating new processes: fork, vfork, execve, and clone.  (The man pages will describe for you the differences among them.)  Instrument the kernel to keep track of the number of times each of these four system calls has been invoked and write a user-level C program that will print counts of the number of times each of them has been invoked (by any process on the system).

To do this requires three things:

Modify the kernel to keep track of this information.

Design and implement a new system call that will get this data back to the user application.

Write the user application.

We'd also like to be able to reset these statistics periodically. So we need a way to clear the request information we've tracked so far. This requires either parameterizing the above system call to add a clear option, or adding another system call.

There are several different ways to approach this problem. It is your job to analyze them from an engineering point-of-view, determine the trade-offs, and to explain the implementation you select.

Warning 1: Remember that the Linux kernel should be allowed to access any memory location, while the calling application should be prevented from causing the kernel to unwittingly read/write addresses other than those in its own address space. Details about this are here.

Warning 2 (Hint 0): Remember that it's inconceivable that this problem (warning 1) has never before been confronted in the existing kernel.

Warning 3: Remember that the kernel must never, ever trust the application to know what it's talking about when it makes a request, particularly with respect to parameters passed in from the application to the kernel.

Warning 4: Remember that you must be sure not to create security holes in the kernel with your code.

Warning 5: Remember that the kernel should not leak memory.

SOME HINTS (Read Carefully)

You should be using the C language whenever you alter or add to the Linux kernel.

You can't just make system calls directly from C. Instead, you need to use the syscall function and pass it the number of your new system call. The following code fragment show you how to do that:

/* 
* Set the features included by the linux libc to have the BSD extensions 
*/

#ifndef _BSD_SOURCE 
#define _BSD_SOURCE 1 
#endif

#define _NR_execcounts something

#include <unistd.h>
...
int ret = syscall(__NR_execcounts, ...);

Recommended Procedure

Here’s a suggested set of incremental steps for completing this assignment:

1. If you've never compiled the kernel, go back through the lab information page. It should not take longer than an hour and it will make sure you’re up to speed on Xen.

Now implement a parameter-less system call, whose body is just a printk() call.  Write a user-level routine that invokes it.  Check to make sure it was invoked.

Now write the full implementation.

Part 2: Integrate the system call into the shell

Now that you have a working shell (from assignment 1) and an implementation of your new system call, it's time to integrate them; this should be very simple. Add a new internal command to your shell, called execcounts. The execcounts command should invoke the system call that you build in Part 2, and print out:

• The number of invocations of each of the four "process creation" Linux system calls that have occurred since the last invocation of execcounts.
• The fraction of all such calls that each of the four types represents.

Part 3: Some additional questions

Answer these additional questions and include them with your write-up:

1) What is "asmlinkage" as it occurs in the Linux kernel source, what does it do (give a short description)?

2) What is the difference between the "clone" and "fork" system calls?

3) How long does your new system call take (time it using gettimeofday and give an approximate answer)?  Explain your timing methodology.

What to Turn In

You should turn in the following:

1. The names of all of the Linux kernel source files that you modified in order to add your new system call, and a written description of what you did to them and why you needed to do it (i.e. why was it necessary to modify this particular file).
2. The interface to the new system call (i.e., a miniature man page for the system call itself, not for the shell command). A text file is fine.
3. The complete source code of the routine that implements the new system call in the kernel (i.e., just the new code you wrote, not the source code that was already in the kernel that got control to your new routine).
4. To attempt to achieve some sort of uniformity in results for the new system call, hand in the results obtained from the following:
• Invoke your shell
• Use your shell to reset the system call counts to zero
• Run the following command exactly as given:
  /usr/bin/find /etc -type f -exec touch t ;
  Note: to try that command in most "real" shells, use the following:
  /usr/bin/find /etc -type f -exec touch ~/t \;
• Invoke execcounts and report these results
5. A brief write-up (about a page) with the answers to the following questions.

Describe how you found the information needed to complete this project. Did it have the information you needed? Did you consult with any humans? If so, what did you try first and who did you consult with?

Explain the calling sequence that makes your system call work. First, a user program calls <.....>. Then, <.....> calls <.....>. ... and so on. You can explain this using either text or a rough (less than 15 minutes) diagram.

Why do you think the designers of Linux implemented system calls the way they did? What were they trying to achieve? What were they trying to avoid?

Give (in 1-2 sentences) an alternative idea for implementing system calls. State one way your idea would be better or worse than the way it is currently done.

Do not underestimate the importance of the write-up. Your project grade depends significantly on how well you understood what you were doing, and the write-up is the best way for you to demonstrate that understanding.

Submission instructions: We will be using the submit program.

1. Get all of your files (including the writeup) together on the CS machines.  You may want to create one tar file of all the code.
2. Run submit_cps110 lab2 <filename₁> <filename₂> ... <filename_n>