Fuzz Testing is a largely automated testing technique that provides random and unexpected input to a program in attempt to trigger failure conditions. Much of the research conducted thus far into Fuzz Testing has focused on developing improvements to available Fuzz Testing tools and frameworks in order to improve efficiency. In this paper however, we instead look at a way in which we can reduce the amount of developer time required to integrate Fuzz Testing to help maintain an existing codebase. We accomplish this with a new technique for automatically generating Fuzz Targets, the modified versions of programs on which Fuzz Testing tools operate. We evaluated three different Fuzz Testing solutions on the codebase of our industry partner and found a fully automated solution to result in significantly more bugs found with respect to the developer time required to implement said solution. Our research is an important step towards increasing the prevalence of Fuzz Testing by making it simpler to integrate a Fuzz Testing solution for maintaining an existing codebase.

We describe how to combine a minimal Trusted Computing Base (TCB) with polyinstantiated and slightly augmented Commercial Off The Shelf (COTS) software programs in separate Single Level Secure (SLS) partitions to create MultiLevel Secure (MLS) applications. These MLS applications can coordinate fine grained (intra-document) Bell LaPadula (BLP) [6] separation between information at multiple security levels. The untrusted COTS programs in the SLS partitions send at-level file edits as diff transactions to the TCB. The TCB verifies that BLP semantics will be observed and then patches these transactions into its canonical representation of the file. Finally, it releases appropriately filtered versions back to each SLS partition for re-assembly into the COTS program's standard file format. Furthermore, by judiciously restricting how the user can interact with the system the multiple SLS instantiations of the COTS program can be made to appear as if they are a single MLS instantiation. We demonstrate the utility of this approach using Microsoft Word and DokuWiki.

Planetary science missions, such as those that explore Mars and Saturn, employ a variety of spacecraft such as arbiters, landers, probes, and rovers. Each of these kinds of spacecraft depends on embedded real-time control systems - systems that are increasingly being asked to do more as challenging new mission concepts are proposed. For both systems engineers and software engineers the large challenges are in analysis, design and verification of complex control systems that run on relatively limited processors. Project Golden Gate - a collaboration among NASA's Jet Propulsion Laboratory, Sun Microsystems Laboratory, and Carnegie Mellon University - is exploring those challenges in the context of real-time Java applied to space mission software. This paper describes the problem domain and our experimentation with the first commercial implementation of the real time specification for Java. The two main issues explored in this report are: (I) the effect of RTSJ's nonheap memory on the programming model, and (2) performance benchmarking of RTSJ/Linux relative to C++/VxWorks