Portably solving file races with hardness amplification

Tsafrir, Dan; Hertz, Tomer; Wagner, David; Silva, Dilma Da

doi:10.1145/1416944.1416948

Cited by 26 publications

(32 citation statements)

References 26 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…TOCTOU races. TOCTOU race detection [32,33,35] has been a hot topic in the security community. Similar to RACEPRO, these systems often perform OS-level detection because file accesses are sanitized by the kernel.…”

Section: Related Workmentioning

confidence: 99%

Pervasive detection of process races in deployed systems

Laadan

Viennot

Tsai

et al. 2011

Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles

View full text Add to dashboard Cite

Process races occur when multiple processes access shared operating system resources, such as files, without proper synchronization. We present the first study of real process races and the first system designed to detect them. Our study of hundreds of applications shows that process races are numerous, difficult to debug, and a real threat to reliability. To address this problem, we created RACEPRO, a system for automatically detecting these races. RACEPRO checks deployed systems in-vivo by recording live executions then deterministically replaying and checking them later. This approach increases checking coverage beyond the configurations or executions covered by software vendors or beta testing sites. RACEPRO records multiple processes, detects races in the recording among system calls that may concurrently access shared kernel objects, then tries different execution orderings of such system calls to determine which races are harmful and result in failures. To simplify race detection, RACEPRO models under-specified system calls based on load and store micro-operations. To reduce false positives and negatives, RACEPRO uses a replay and go-live mechanism to distill harmful races from benign ones. We have implemented RACEPRO in Linux, shown that it imposes only modest recording overhead, and used it to detect a number of previously unknown bugs in real applications caused by process races.

show abstract

Section: Related Workmentioning

confidence: 99%

Pervasive detection of process races in deployed systems

Laadan

Viennot

Tsai

et al. 2011

Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles

View full text Add to dashboard Cite

show abstract

“…Many papers on automated source code scanning followed (see [29] for a discussion of publicly available tools). Researchers developed many innovative techniques to detect and fix problems in programs that often led to security vulnerabilities [30]- [33].…”

Section: A Vulnerabilitiesmentioning

confidence: 99%

Reflections on UNIX Vulnerabilities

Bishop¹

2009

2009 Annual Computer Security Applications Conference

View full text Add to dashboard Cite

Abstract-The UNIX operating system was developed in a friendly, collaborative environment without any particular predefined objectives. As it entered less friendly environments, expanded its functionality, and became the basis for commercial, infrastructure, and home systems, vulnerabilities in the system affected its robustness and security. This paper presents a brief history of UNIX vulnerabilities, beginning with a report written in 1981-1983, but never published. It examines how the nature of vulnerabilities has (and has not) changed since then, and presents some thoughts on the future of vulnerabilities in the UNIX operating system and its variants and other UNIXlike systems.

show abstract

“…Figure 1 shows an example of ICR. [36,38] races. The difference is that while TOCTTOU races apply to conditions in the file system between competing processes, ICRs apply to memory accesses of multi-threaded programs.…”

Section: Introductionmentioning

confidence: 99%

Dynamically detecting and tolerating IF-Condition Data Races

Muzahid

Ahn

et al. 2014

2014 IEEE 20th International Symposium on High Performance Computer Architecture (HPCA)

View full text Add to dashboard Cite

An IF-Condition Invariance Violation (ICIV) occurs when, after a thread has computed the control expression of an IF statement and while it is executing the THEN or ELSE clauses, another thread updates variables in the IF's control expression. An ICIV can be easily detected, and is likely to be a sign of a concurrency bug in the code. Typically, the ICIV is caused by a data race, which we call IF-Condition Data Race (ICR).In this paper, we analyze the data races reported in the bug databases of popular software systems and show that ICRs occur relatively often. Then, we present two techniques to handle ICRs dynamically. They rely on simple code transformations and, in one case, additional hardware help. One of them (SW-IF) detects the races, while the other (HW-IF) detects and prevents them. We evaluate SW-IF and HW-IF using a variety of applications. We show that these new techniques are effective at finding new data race bugs and run with low overhead. Specifically, HW-IF finds 5 new (unreported) race bugs and SW-IF finds 3 of them. In addition, 8-threaded executions of SPLASH-2 codes show that, on average, SW-IF adds 2% execution overhead, while HW-IF adds less than 1%.

show abstract

Portably solving file races with hardness amplification

Cited by 26 publications

References 26 publications

Pervasive detection of process races in deployed systems

Pervasive detection of process races in deployed systems

Reflections on UNIX Vulnerabilities

Dynamically detecting and tolerating IF-Condition Data Races

Contact Info

Product

Resources

About