Paul Twohey

dblp:09/2839 · DBLP profile ↗
← Back
4ranked-venue papers
0as first author
0since 2021 · last 2006
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 2Systems, architecture and hardware · 1Security and privacy · 1

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
4 papers
Program analysis · 39% Program verification · 34% Operating systems · 21%
Computer architecture, parallel and distributed computing, and storage systems
2 papers
Storage systems · 100%
Network and information security
1 paper
Systems and software security · 100%
Theoretical computer science
1 paper
Automated reasoning and model checking · 100%

Topics — the 9 heaviest of 10, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Program verification
model checking
0.122006
Using model checking to find serious file system errors · ACM Trans. Comput. Syst. 2006
Using Model Checking to Find Serious File System Errors (Awarded Best Paper!) · OSDI 2004
Storage systems › storage reliability
file system reliability
0.122006
Using model checking to find serious file system errors · ACM Trans. Comput. Syst. 2006
Using Model Checking to Find Serious File System Errors (Awarded Best Paper!) · OSDI 2004
Systems and software security
vulnerability discovery
0.112006
Automatically Generating Malicious Disks using Symbolic Execution · S&P 2006
Program analysis
specification mining
0.112006
From Uncertainty to Belief: Inferring the Specification Within · OSDI 2006
Program analysis
symbolic execution
0.112006
Automatically Generating Malicious Disks using Symbolic Execution · S&P 2006
Storage systems
file systems
0.112006
Using model checking to find serious file system errors · ACM Trans. Comput. Syst. 2006
Operating systems › resource management › storage management › file systems
file system bug detection
0.012004
Using Model Checking to Find Serious File System Errors (Awarded Best Paper!) · OSDI 2004
Operating systems › resource management › storage management
file systems
0.012006
Automatically Generating Malicious Disks using Symbolic Execution · S&P 2006
Automated reasoning and model checking
model checking
0.012006
From Uncertainty to Belief: Inferring the Specification Within · OSDI 2006

Methods — techniques the papers use, named apart from their topics

model checking · 0.2symbolic execution · 0.1state space reduction · 0.1constraint solving · 0.1
YearPublicationVenuePosition
2006 From Uncertainty to Belief: Inferring the Specification Within
Ted Kremenek, Paul Twohey, Godmar Back, Andrew Y. Ng, Dawson R. Engler
OSDI2
2006 Automatically Generating Malicious Disks using Symbolic Execution
abstract
Many current systems allow data produced by potentially malicious sources to be mounted as a file system. File system code must check this data for dangerous values or invariant violations before using it. Because file system code typically runs inside the operating system kernel, even a single unchecked value can crash the machine or lead to an exploit. Unfortunately, validating file system images is complex: they form DAGs with complex dependency relationships across massive amounts of data bound together with intricate, undocumented assumptions. This paper shows how to automatically find bugs in such code using symbolic execution. Rather than running the code on manually-constructed concrete input, we instead run it on symbolic input that is initially allowed to be "anything." As the code runs, it observes (tests) this input and thus constrains its possible values. We generate test cases by solving these constraints for concrete values. The approach works well in practice: we checked the disk mounting code of three widely-used Linux file systems: ext2, ext3, and JFS and found bugs in all of them where malicious data could either cause a kernel panic or form the basis of a buffer overflow attack.
Can Sar, Paul Twohey, Cristian Cadar, Dawson R. Engler
S&P3
2006 Using model checking to find serious file system errors
abstract
This article shows how to use model checking to find serious errors in file systems. Model checking is a formal verification technique tuned for finding corner-case errors by comprehensively exploring the state spaces defined by a system. File systems have two dynamics that make them attractive for such an approach. First, their errors are some of the most serious, since they can destroy persistent data and lead to unrecoverable corruption. Second, traditional testing needs an impractical, exponential number of test cases to check that the system will recover if it crashes at any point during execution. Model checking employs a variety of state-reducing techniques that allow it to explore such vast state spaces efficiently.We built a system, FiSC, for model checking file systems. We applied it to four widely-used, heavily-tested file systems: ext3, JFS, ReiserFS and XFS. We found serious bugs in all of them, 33 in total. Most have led to patches within a day of diagnosis. For each file system, FiSC found demonstrable events leading to the unrecoverable destruction of metadata and entire directories, including the file system root directory “/”.
Paul Twohey, Dawson R. Engler, Madan Musuvathi
ACM Trans. Comput. Syst.2
2004 Using Model Checking to Find Serious File System Errors (Awarded Best Paper!)
Paul Twohey, Dawson R. Engler, Madan Musuvathi
OSDI2