Operating System Laboratory Final Project Specification Sharif University of Technology Summer 2008 1. Introduction Please consider following notes in doing your assignment: • You should do this assignment with your group members. • You can find NachOS source code and some other documents in the course’s website. • This assignment has been used in some other universities before, and you may find some useful information about it in the Web. • Send your reports and source codes to [email protected] or [email protected]. • Deadline: 1387/06/08 (Friday), 12:00 PM ‐ Delivery day: 1387/06/10 (Sunday), 14:00. • We have no final exam. Your grades will be calculated from the presentation and the assignment. 2. System Calls In this programming assignment you have to implement the system calls of NachOS. System calls are the usual way users request services from the kernel. In order to protect the users and the kernel form sharks, it is important to consider some basic security issues. If a user is only allowed to use predefined system calls, he can only harm the kernel by passing invalid arguments or extremely oversized parameters1. Therefore, do never forget to check the parameters before using them and limit their size. A description of what the calls mentioned below should do and which parameters are passed and/or returned can be found in the corresponding interface in code/userprog/syscall.h. You are not allowed to modify these definitions, but feel free to add new system calls as you like. If no special return values are mentioned below, you should stick to the return value scheme proposed by syscall.h: return 1 if the call succeeded and a negative return value using the predefined error numbers in all other cases. To complete this assignment, the all the calls must be implemented. 2.1 File System Calls A good point to start with is the filesystem related system calls. These system calls provide basic file management support to each user program. For now, it is sufficient to pass the system calls to the host OS. You do not have to implement a complete file system yet. This is subject to a later assignment. The code/filesys/ directory is already prepared to pass the system calls on. In detail, you have to implement the following system calls: int Create(char *name); Creates a new NachOS file named “name”, but does not open it. int Remove(char *name); Removes a NachOS file named “name”. OpenFileId Open(char *name, int mode); Opens the file called “name” and returns an ID that can be used to read from and to write to a file. Mode specifies the requested access mode to this file (RO=1, RW=2, APPEND=3). int Write(char *buffer, int size, OpenFileId id); Writes “size” bytes from “buffer” to the open file. 1
buffer-overow attacks
1 int Read(char *buffer, int size, OpenFileId id); Reads “size” bytes from the open file into “buffer”. Returns the number of bytes actually read, which does not always have to equal the number of bytes requested. int Seek(int position, OpenFileId id); Set the current position within the open file called “id”. int Close(OpenFileId id); Releases a file after it is not needed anymore. All of these calls are already defined on the user level side. You “only” have to implement the kernel level parts. Before you start to implement, you should spend some thoughts on design issues. Why are the Open() and Close() calls needed? Who should be allowed to open the files? How is an open file represented within an user program? Always remember to test your system calls by writing small application programs. 2.3 Thread Management Calls The next step is to implement multi threading in a user level application. Therefore the following system calls are needed: void ThreadYield(); Yields the CPU to another runnable thread. ThreadId ThreadFork(void (*func)()); Forks a thread to run a procedure 'func' in the same address space as the current thread. int ThreadJoin(ThreadId id); ThreadJoin() Blocks the current thread until a certain local thread ThreadID exits with ThreadExit(). This call returns the ExitCode of the thred ‘id’. void ThreadExit(int ExitCode); Deletes the current thread and returns ExitCode to every waiting local thread. ThreadId getThreadID(); Returns ThreadId of current thread. Remember that each thread needs its own stack. You will have to implement something within your address space to allocate different stacks. If you do not know how threads are implemented and used in NachOS you might want to look at the source code in the code/threads/ directory of the NachOS source code. To implement ThreadJoin() and ThreadExit() you will need to use the synchronization primitives provided by NachOS. They can be found in the code/threads/ directory, too. Hint: In the current implementation of NachOS an example of how ThreadFork should work is already implemented. Take a closer look at the main method of NachOS in code/threads/main.cc. 2.3 Multiprogramming Calls The probably most diffcult part of this assignment has to be implemented in this part. To provide multiprogramming, the following system calls are needed. SpaceId getSpaceID(); getSpaceID() returns address spaces' ID. 2 SpaceId Exec(char* exec name); Starts the executable called 'exec name' in a new address space. SpaceId ExecV(int argc, char* argv[]); Starts the executable executable called 'argv[0]' in a new address space with parameters 'argv[1...argc‐1]'. int Join(SpaceId id); Returns to the user program only after Task 'id' has exited via Exit(). The return value is the ExitCode of Task (id). void Exit(int status); Ends a task and signals the termination as well as the exit status to waiting tasks. A '0' means normal termination here. As no task structure has been defined in NachOS yet, it is up to you to fix that before starting to implement the multiprogramming system calls. Remember that code/userproc/addrspace.cc assumes to be the only address space in the whole main memory at the moment. Of course this needs to be fixed, too. The creation of a new task is not as trivial as it may look on the first view. You have to create a new address space, elf‐load the executable file into this space and set up the initial thread. If you hate to pass parameters to the new task you have to think of a way to get these parameters into the target space, too. As Join () and Exit () rely on globally unique IDs you have to find a way to guarantee that. 3. Testing and Documentation To test your changes, write program(s) which needs the implemented system calls. You need to have some logging mechanism to show that your implementation is correct. This is very crucial in your delivery day. Please provide a simple document containing information about the changes you have made, the test program you have written, and etc. ‐‐‐ End ‐‐‐ 3