EDBT 2026 Demo / reviewers in the wild / expert
Paul Twohey
dblp:09/2839
· DBLP profile ↗
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
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Program verification
model checking |
0.1 | 2 | 2006 | 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.1 | 2 | 2006 | 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.1 | 1 | 2006 | Automatically Generating Malicious Disks using Symbolic Execution · S&P 2006 |
Program analysis
specification mining |
0.1 | 1 | 2006 | From Uncertainty to Belief: Inferring the Specification Within · OSDI 2006 |
Program analysis
symbolic execution |
0.1 | 1 | 2006 | Automatically Generating Malicious Disks using Symbolic Execution · S&P 2006 |
Storage systems
file systems |
0.1 | 1 | 2006 | 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.0 | 1 | 2004 | Using Model Checking to Find Serious File System Errors (Awarded Best Paper!) · OSDI 2004 |
Operating systems › resource management › storage management
file systems |
0.0 | 1 | 2006 | Automatically Generating Malicious Disks using Symbolic Execution · S&P 2006 |
Automated reasoning and model checking
model checking |
0.0 | 1 | 2006 | 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
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2006 | From Uncertainty to Belief: Inferring the Specification Within
Ted Kremenek, Paul Twohey, Godmar Back, Andrew Y. Ng, Dawson R. Engler |
OSDI | 2 |
| 2006 | Automatically Generating Malicious Disks using Symbolic ExecutionabstractMany 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&P | 3 |
| 2006 | Using model checking to find serious file system errorsabstractThis 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 |
OSDI | 2 |