COMPUTER SCIENCES DEPARTMENTUNIVERSITY OF WISCONSIN-MADISONCS 736 Bart MillerFall 1988Project List(Brief Description Due: Wednesday,October 26)(Midway Interview: Friday,November 18)(Final Report Due: Thursday,December 15)General CommentsThe projects are intended to give you an opportunity to study a particular area related to operating sys-tems. Your project may require a test implementation, measurement study,simulation, literature search,paper design, or some combination of these.The project suggestions beloware briefly stated. Theyare intended to guide you into particular areasand you are expected to expand these suggestions into a full project descriptions. This givesyou more free-dom in selecting an area and more burden in defining your own project. There may be more issues listedfor a project than you can cover. Ifyou have a topic of your own that is not listed below, you should comeand talk with me so we can work out a reasonable project description.Youwill write a paper that reports on your project. This paper will structured as if you were going tosubmit it to a conference. Iwill provide more details on the project report later in the semester.Youcan work in teams of twopeople on the project and report.Projects(1) Operating System Utility ProgramReliability − The Fuzz Generator: The goal of this project is toevaluate the robustness of various UNIX utility programs, givenanunpredictable input stream. Thisproject has twoparts. First, you will build a fuzz generator.This is a program that will output a ran-dom character stream. Second, you will takethe fuzz generator and use it to attack as manyUNIXutilities as possible, with the goal of trying to break them. Forthe utilities that break, you will try todetermine what type of input cause the break.The fuzz generator will generate an output stream of random characters. It will need several optionsto give you flexibility to test different programs. Belowisthe start for a list of options for featuresthat fuzz will support. It is important when writing this program to use good C and UNIX style, andgood structure, as we hope to distribute this program to others.-p only the printable ASCII characters-a all ASCII characters-0 include the null (0 byte) character-l generate random length lines (\n terminated strings)-f name record characters in file ‘‘name’’-d nnn delay nnn seconds following each character-r name replay characters in file ‘‘name’’tooutputThe fuzz program should be used to test various UNIX utilities. These utilities include programs likevi, mail, cc, make, sed, awk, sort, etc. The goal is to first see if the program will break and second tounderstand what type of input is responsible for the break.(2) Security in a Workstation CPU Server: The Condor system allows users to automatically run theirprograms on anyofacollection of idle workstations. It automatically chooses an idle workstation,checkpoints the program, and can move the program to another workstation when the owner returns.This system was developed in our Computer Sciences Department.While Condor is an effective system for load distribution and providing free cycles to the user com-munity,ithas only briefly addressed security issues. If you own a workstation, you would liketobeconfident that the guest programs that are running cannot access or damage your resources (processes,files, devices, etc.). The goal of this project is to study the existing Condor features, evaluate theUNIX security facilities, and then design and implement security modifications to Condor.(3) Visual Shell: Personal computers, likethe Mac, are easy to use because of their simple and visual userinterfaces. The goal of this project is to build a visual shell for UNIX. This shell uses graphic displayand mouse input to list files, delete files, start programs, build pipes, redirect input and output, etc.Ke yboard input will also be need to be smoothly integrated in the design.This shell should also allowfor more advanced features such as non-linear pipes, editing of com-mands and program output (and feeding this back into programs), visual aliases, etc.(4) ALanguage for Distributed Games: DREGS is a system for helping design and build distributed,multi-player games. DREGS runs on our local uVax, Bobcat, and IBM RT/PC workstations. Thisproject involves the interaction of distributed systems and programming languages.The DREGS design includes a language call GDL (game description language) that simplifies the pro-gramming of the games. Currently,games are hand-coded according to a GDL-likecoding style. Thegoal of this project would be to build a simple GDL compiler.There are several games that currentlyrun under DREGS, and part of this project would be to convert at least one of these to directly useGDL. This project is especially suited to a person with a strong interest in compilers.An alternative version of this project would be to investigate the use of an object-oriented program-ming language (probably C++) to support a set of standard classes to support GDL. Youwould thengo on to implement these classes and test them by converting one of the simpler games.The current DREGS system is described in twopapers (I can supply copies of these):A. Bricker,M.Clark, T.Lebeck, B.P.Miller,and P.Wu, ‘‘Experience with DREGS’’, Proc. of the1987 Summer USENIX Conf.,Phoenix, June 1987.A. Bricker,T.Lebeck and B.P.Miller,‘‘DREGS: A Distributed Runtime Environment for Game Sup-port’’, Proc. of the EUUG 1986 Conf.,Manchester,England, September 1986.(5) AResource Scheduler for a Distributed Environment: The Computer Sciences Dept. has a resourcescheduling problem: that of scheduling conference rooms. This problem has several interesting char-acteristics.First, the service must be accessible from throughout the campus network, but not from outside thecampus (or department). Second, we need some levelofprotection. If one person makes a reserva-tion, then another person should not be able to delete it. Third, data consistencymust be preserved.This means that if twopeople are making reservations, you must serialize requests and avoid race con-ditions. Fourth, you will need a decent user interface. The users should be able to gracefully examinethe schedule and makereservations. A graphic interface (using X windows) would be best.(6) Distributed Simulation Algorithm: Chandy has developed a simulation algorithm that is supposed toprovide good parallel execution in a distributed