Results 1 - 10
of
14
Parallel randomized state-space search
- in International Conference on Software Engineering
"... Model checkers search the space of possible program behaviors to detect errors and to demonstrate their absence. Despite major advances in reduction and optimization techniques, state-space search can still become cost-prohibitive as program size and complexity increase. In this paper, we present a ..."
Abstract
-
Cited by 20 (0 self)
- Add to MetaCart
Model checkers search the space of possible program behaviors to detect errors and to demonstrate their absence. Despite major advances in reduction and optimization techniques, state-space search can still become cost-prohibitive as program size and complexity increase. In this paper, we present a technique for dramatically improving the costeffectiveness of state-space search techniques for error detection using parallelism. Our approach can be composed with all of the reduction and optimization techniques we are aware of to amplify their benefits. It was developed based on insights gained from performing a large empirical study of the cost-effectiveness of randomization techniques in state-space analysis. We explain those insights and our technique, and then show through a focused empirical study that our technique speeds up analysis by factors ranging from 2 to over 1000 as compared to traditional modes of state-space search, and does so with relatively small numbers of parallel processors. 1.
Parity Lost and Parity Regained
"... RAID storage systems protect data from storage errors, such as data corruption, using a set of one or more integrity techniques, such as checksums. The exact protection offered by certain techniques or a combination of techniques is sometimes unclear. We introduce and apply a formal method of analyz ..."
Abstract
-
Cited by 12 (2 self)
- Add to MetaCart
RAID storage systems protect data from storage errors, such as data corruption, using a set of one or more integrity techniques, such as checksums. The exact protection offered by certain techniques or a combination of techniques is sometimes unclear. We introduce and apply a formal method of analyzing the design of data protection strategies. Specifically, we use model checking to evaluate whether common protection techniques used in parity-based RAID systems are sufficient in light of the increasingly complex failure modes of modern disk drives. We evaluate the approaches taken by a number of real systems under single-error conditions, and find flaws in every scheme. In particular, we identify a parity pollution problem that spreads corrupt data (the result of a single error) across multiple disks, thus leading to data loss or corruption. We further identify which protection measures must be used to avoid such problems. Finally, we show how to combine real-world failure data with the results from the model checker to estimate the actual likelihood of data loss of different protection strategies. 1
Fixing races for fun and profit: how to abuse atime
- In 14th USENIX Security Symp
, 2005
"... Dean and Hu proposed a probabilistic countermeasure to the classic access(2)/open(2) TOCTTOU race condition in privileged Unix programs [4]. In this paper, we describe an attack that succeeds with very high probability against their countermeasure. We then consider a stronger randomized variant of t ..."
Abstract
-
Cited by 11 (4 self)
- Add to MetaCart
Dean and Hu proposed a probabilistic countermeasure to the classic access(2)/open(2) TOCTTOU race condition in privileged Unix programs [4]. In this paper, we describe an attack that succeeds with very high probability against their countermeasure. We then consider a stronger randomized variant of their defense and show that it, too, is broken. We conclude that access(2) must never be used in privileged Unix programs. The tools we develop can be used to attack other filesystem races, underscoring the importance of avoiding such races in secure software. 1
Exploiting unix file-system races via algorithmic complexity attacks
, 2009
"... We defeat two proposed Unix file-system race condition defense mechanisms. First, we attack the probabilistic defense mechanism of Tsafrir, et al., published at USENIX FAST 2008[26]. We then show that the same attack breaks the kernel-based dynamic race detector of Tsyrklevich and Yee, published at ..."
Abstract
-
Cited by 6 (0 self)
- Add to MetaCart
We defeat two proposed Unix file-system race condition defense mechanisms. First, we attack the probabilistic defense mechanism of Tsafrir, et al., published at USENIX FAST 2008[26]. We then show that the same attack breaks the kernel-based dynamic race detector of Tsyrklevich and Yee, published at USENIX Security 2003[28]. We then argue that all kernel-based dynamic race detectors must have a model of the programs they protect or provide imperfect protection. The techniques we develop for performing these attacks work on multiple Unix operating systems, on uni- and multi-processors, and are useful for exploiting most Unix file-system races. We conclude that programmers should use provably-secure methods for avoiding race conditions when accessing the file-system. 1.
Portably solving file TOCTTOU races with hardness amplification
- In FAST
, 2008
"... The file-system API of contemporary systems makes programs vulnerable to TOCTTOU (time of check to time of use) race conditions. Existing solutions either help users to detect these problems (by pinpointing their locations in the code), or prevent the problem altogether (by modifying the kernel or i ..."
Abstract
-
Cited by 5 (0 self)
- Add to MetaCart
The file-system API of contemporary systems makes programs vulnerable to TOCTTOU (time of check to time of use) race conditions. Existing solutions either help users to detect these problems (by pinpointing their locations in the code), or prevent the problem altogether (by modifying the kernel or its API). The latter alternative is not prevalent, and the former is just the first step: programmers must still address TOCTTOU flaws within the limits of the existing API with which several important tasks can not be accomplished in a portable straightforward manner. Recently, Dean and Hu addressed this problem and suggested a probabilistic hardness amplification approach that alleviated the matter. Alas, shortly after, Borisov et al. responded with an attack termed “filesystem maze ” that defeated the new approach. We begin by noting that mazes constitute a generic way to deterministically win many TOCTTOU races (gone are the days when the probability was small). In the face of this threat, we (1) develop a new user-level defense that can withstand mazes, and (2) show that our method is undefeated even by much stronger hypothetical attacks that provide the adversary program with ideal conditions to win the race (enjoying complete and instantaneous knowledge about the defending program’s actions and being able to perfectly synchronize accordingly). The fact that our approach is immune to these unrealistic attacks suggests it can be used as a simple and portable solution to a large class of TOCTTOU vulnerabilities, without requiring modifications to the underlying operating system. 1
Multiscale not multicore: Efficient heterogeneous cloud computing
- In Proc. ACM-BCS Visions of Computer Science, Electronic Workshops in Computing
, 2010
"... In this paper, we present a vision of the future of heterogeneous cloud computing. Ours is a cleanslate approach, sweeping away decades of accreted system software. We believe the advent of the latest technology discontinuity—the move to the virtual cloud—makes this a necessary step to take, but one ..."
Abstract
-
Cited by 2 (1 self)
- Add to MetaCart
In this paper, we present a vision of the future of heterogeneous cloud computing. Ours is a cleanslate approach, sweeping away decades of accreted system software. We believe the advent of the latest technology discontinuity—the move to the virtual cloud—makes this a necessary step to take, but one capable of delivering significant benefits in the security, reliability and efficiency of our digital infrastructure at all scales. We motivate this vision by presenting two challenges arising in different fields yet with fundamental commonalities best addressed by a unifying software platform supporting devices ranging from virtual servers in the cloud, through desktops, to mobile smartphones. After drawing out this common ground, we describe our solution and its benefits. We then describe the initial steps we have taken toward our solution, the Mirage framework, as well as ongoing future work. 1.
Regression Model Checking
"... Model checking is a promising technique for verifying program behavior and is increasingly finding usage in industry. To date, however, researchers have primarily considered model checking of single versions of programs. It is well understood that model checking can be very expensive for large, comp ..."
Abstract
-
Cited by 2 (0 self)
- Add to MetaCart
Model checking is a promising technique for verifying program behavior and is increasingly finding usage in industry. To date, however, researchers have primarily considered model checking of single versions of programs. It is well understood that model checking can be very expensive for large, complex programs. Thus, simply reapplying model checking techniques on subsequent versions of programs as they evolve, in the limited time that is typically available for validating new releases, presents challenges. To address these challenges, we have developed a new technique for regression model checking (RMC), that applies model checking incrementally to new versions of systems. We report results of an empirical study examining the effectiveness of our technique; our results show that it is significantly faster than traditional model checking. 1.
unknown title
"... 1 Introduction Data reliability and integrity is vital to storage systems.Performance problems can be tuned, tools can be added to cope with management issues, but data loss is seen ascatastrophic. As Keeton et al. state, data unavailability may cost a company "... more than $1 million/hour&quo ..."
Abstract
- Add to MetaCart
1 Introduction Data reliability and integrity is vital to storage systems.Performance problems can be tuned, tools can be added to cope with management issues, but data loss is seen ascatastrophic. As Keeton et al. state, data unavailability may cost a company "... more than $1 million/hour", butthe price of data loss is "even higher " [23]. In well-designed, high-end systems, disk-related er-rors are still one of the main causes of potential trouble and thus must be carefully considered to avoid dataloss [25]. Fortunately, with simple disk errors (e.g., an entire disk failing in a fail-stop fashion), designing pro-tection schemes to cope with disk errors is not overly challenging. For example, early systems successfullyhandle the failure of a single disk through the use of mirroring or parity-based redundancy schemes [6, 24, 29].
Mining API Specifications from Source Code for Improving Software Reliability
"... A software system interacts with third-party libraries through various Application Program Interfaces (APIs). Using these APIs correctly often needs to follow certain programming rules, i.e., API specifications. API specifications specify the required checks (on API input parameters and return value ..."
Abstract
- Add to MetaCart
A software system interacts with third-party libraries through various Application Program Interfaces (APIs). Using these APIs correctly often needs to follow certain programming rules, i.e., API specifications. API specifications specify the required checks (on API input parameters and return values) and other APIs to be invoked before (preconditions) and after (postconditions) an API call. Incorrect usage of APIs (in short, API violations) can lead to security and robustness problems, two primary hindrances for the reliable operation of a software system. Hence, for a software system, adherence to the specifications, which govern the correct usage of APIs used by the system, is paramount for software reliability. Specifications, when known, can be formally written for third-party APIs and statically verified against a software system. This dissertation addresses two main problems faced by programmers in effectively and correctly reusing third-party APIs. (1) Formal API specifications are complicated and lengthy mainly due to the various API details (such as input/return type, error-flag codes, and return values for APIs on success/failure) and language-specific syntax considerations required for the specification to be accurate and complete. Hence, manually writing a large number of formal API specifications, when known, for static verification is often inaccurate or incomplete,

