Cuckoo: a Language for Implementing Memory- and Thread-safe System Services

This paper is centered around the design of a thread- and memory-safe language, primarily for the compilation of application-specific services for extensible operating systems. We describe various issues that have influenced the design of our language, called Cuckoo, that guarantees safety of programs with potentially asynchronous flows of control. Comparisons are drawn between Cuckoo and related software safety techniques, including Cyclone and software-based fault isolation (SFI), and performance results suggest our prototype compiler is capable of generating safe code that executes with low runtime overheads, even without potential code optimizations. Compared to Cyclone, Cuckoo is able to safely guard accesses to memory when programs are multithreaded. Similarly, Cuckoo is capable of enforcing memory safety in situations that are potentially troublesome for techniques such as SFI

Analysis of a benchmark suite to evaluate mixed numeric and symbolic processing

The suite of programs that formed the benchmark for a proposed advanced computer is described and analyzed. The features of the processor and its operating system that are tested by the benchmark are discussed. The computer codes and the supporting data for the analysis are given as appendices

Synthesis of Technical Requirements and Considerations for Automated Snowplow Route Optimization: Final Report

DOTs and other transportation agencies are increasingly using automated methods for snowplow route optimization, which have been demonstrated to produce significant savings when they result in the implementation of new routes. However, many route optimization projects have fallen short of implementation due to technical/operational issues with the routes produced or institutional barriers to change. These shortcomings can be substantially mitigated with improvements to the process of soliciting, selecting, and managing the route optimization software or service provider. This project’s objective was to provide DOTs with the tools needed to make these improvements. The key lessons from this project are provided in two complementary documents: a Decision Support Guidance document and a Contracting Language Template. The Decision Support Guidance provides DOT staff with an accessible and in-depth discussion of the technical requirements for route optimization and the key decisions DOTs should consider when developing the project scope and managing a provider. The Contracting Language Template provides DOTs with a flexible template to assist with the development of a scope of work for a Request for Proposals (RFP) for automated snowplow route optimization services. The language suggested in the Contracting document is intended to ensure that DOTs and service providers have a shared understanding of the scope of work that the DOT requires and to maximize the likelihood that the project will result in safe, feasible, implementation-ready routes

CONFLLVM: A Compiler for Enforcing Data Confidentiality in Low-Level Code

We present an instrumenting compiler for enforcing data confidentiality in low-level applications (e.g. those written in C) in the presence of an active adversary. In our approach, the programmer marks secret data by writing lightweight annotations on top-level definitions in the source code. The compiler then uses a static flow analysis coupled with efficient runtime instrumentation, a custom memory layout, and custom control-flow integrity checks to prevent data leaks even in the presence of low-level attacks. We have implemented our scheme as part of the LLVM compiler. We evaluate it on the SPEC micro-benchmarks for performance, and on larger, real-world applications (including OpenLDAP, which is around 300KLoC) for programmer overhead required to restructure the application when protecting the sensitive data such as passwords. We find that performance overheads introduced by our instrumentation are moderate (average 12% on SPEC), and the programmer effort to port OpenLDAP is only about 160 LoC.Comment: Technical report for CONFLLVM: A Compiler for Enforcing Data Confidentiality in Low-Level Code, appearing at EuroSys 201

Idempotent I/O for safe time travel

Debuggers for logic programming languages have traditionally had a capability most other debuggers did not: the ability to jump back to a previous state of the program, effectively travelling back in time in the history of the computation. This ``retry'' capability is very useful, allowing programmers to examine in detail a part of the computation that they previously stepped over. Unfortunately, it also creates a problem: while the debugger may be able to restore the previous values of variables, it cannot restore the part of the program's state that is affected by I/O operations. If the part of the computation being jumped back over performs I/O, then the program will perform these I/O operations twice, which will result in unwanted effects ranging from the benign (e.g. output appearing twice) to the fatal (e.g. trying to close an already closed file). We present a simple mechanism for ensuring that every I/O action called for by the program is executed at most once, even if the programmer asks the debugger to travel back in time from after the action to before the action. The overhead of this mechanism is low enough and can be controlled well enough to make it practical to use it to debug computations that do significant amounts of I/O.Comment: In M. Ronsse, K. De Bosschere (eds), proceedings of the Fifth International Workshop on Automated Debugging (AADEBUG 2003), September 2003, Ghent. cs.SE/030902