Showing 1–5 of 5 results for author: De Bosschere, K

Multi-Variant Execution of Parallel Programs

Authors: Stijn Volckaert, Bjorn De Sutter, Koen De Bosschere, Per Larsen

Abstract: Multi-Variant Execution Environments (MVEEs) are a promising technique to protect software against memory corruption attacks. They transparently execute multiple, diversified variants (often referred to as replicae) of the software receiving the same inputs. By enforcing and monitoring the lock-step execution of the replicae's system calls, and by deploying diversity techniques that prevent an att… ▽ More Multi-Variant Execution Environments (MVEEs) are a promising technique to protect software against memory corruption attacks. They transparently execute multiple, diversified variants (often referred to as replicae) of the software receiving the same inputs. By enforcing and monitoring the lock-step execution of the replicae's system calls, and by deploying diversity techniques that prevent an attacker from simultaneously compromising multiple replicae, MVEEs can block attacks before they succeed. Existing MVEEs cannot handle non-trivial multi-threaded programs because their undeterministic behavior introduces benign system call inconsistencies in the replicae, which trigger false positive detections and deadlocks in the MVEEs. This paper for the first time extends the generality of MVEEs to protect multi-threaded software by means of secure and efficient synchronization replication agents. On the PARSEC 2.1 parallel benchmarks running with four worker threads, our prototype MVEE incurs a run-time overhead of only 1.32x. △ Less

Submitted 26 July, 2016; originally announced July 2016.

Instrumenting self-modifying code

Authors: J. Maebe, K. De Bosschere

Abstract: Adding small code snippets at key points to existing code fragments is called instrumentation. It is an established technique to debug certain otherwise hard to solve faults, such as memory management issues and data races. Dynamic instrumentation can already be used to analyse code which is loaded or even generated at run time.With the advent of environments such as the Java Virtual Machine wit… ▽ More Adding small code snippets at key points to existing code fragments is called instrumentation. It is an established technique to debug certain otherwise hard to solve faults, such as memory management issues and data races. Dynamic instrumentation can already be used to analyse code which is loaded or even generated at run time.With the advent of environments such as the Java Virtual Machine with optimizing Just-In-Time compilers, a new obstacle arises: self-modifying code. In order to instrument this kind of code correctly, one must be able to detect modifications and adapt the instrumentation code accordingly, preferably without incurring a high penalty speedwise. In this paper we propose an innovative technique that uses the hardware page protection mechanism of modern processors to detect such modifications. We also show how an instrumentor can adapt the instrumented version depending on the kind of modificiations as well as an experimental evaluation of said techniques. △ Less

Submitted 16 September, 2003; originally announced September 2003.

Comments: In M. Ronsse, K. De Bosschere (eds), proceedings of the Fifth International Workshop on Automated Debugging (AADEBUG 2003), September 2003, Ghent. cs.SE/0309027

ACM Class: D.2.5

Proceedings of the Fifth International Workshop on Automated Debugging (AADEBUG 2003)

Authors: Michiel Ronsse, Koen De Bosschere

Abstract: Over the past decades automated debugging has seen major achievements. However, as debugging is by necessity attached to particular programming paradigms, the results are scattered. To alleviate this problem, the Automated and Algorithmic Debugging workshop (AADEBUG for short) was organised in 1993 in Link"o** (Sweden). As this workshop proved to be successful, subsequent workshops have been o… ▽ More Over the past decades automated debugging has seen major achievements. However, as debugging is by necessity attached to particular programming paradigms, the results are scattered. To alleviate this problem, the Automated and Algorithmic Debugging workshop (AADEBUG for short) was organised in 1993 in Link"o** (Sweden). As this workshop proved to be successful, subsequent workshops have been organised in 1995 (Saint-Malo, France), 1997 (again in Link"o**, Sweden) and 2000 (Munich, Germany). In 2003, the workshop is organised in Ghent, Belgium, the proceedings of which you are reading right now. △ Less

Submitted 21 December, 2004; v1 submitted 15 September, 2003; originally announced September 2003.

Comments: Workshop homepage at http://www.elis.UGent.be/aadebug2003/

ACM Class: D.2.5

Execution replay and debugging

Authors: Michiel Ronsse, Koen De Bosschere, Jacques Chassin de Kergommeaux

Abstract: As most parallel and distributed programs are internally non-deterministic -- consecutive runs with the same input might result in a different program flow -- vanilla cyclic debugging techniques as such are useless. In order to use cyclic debugging tools, we need a tool that records information about an execution so that it can be replayed for debugging. Because recording information interferes… ▽ More As most parallel and distributed programs are internally non-deterministic -- consecutive runs with the same input might result in a different program flow -- vanilla cyclic debugging techniques as such are useless. In order to use cyclic debugging tools, we need a tool that records information about an execution so that it can be replayed for debugging. Because recording information interferes with the execution, we must limit the amount of information and keep the processing of the information fast. This paper contains a survey of existing execution replay techniques and tools. △ Less

Submitted 6 November, 2000; originally announced November 2000.

Comments: In M. Ducasse (ed), proceedings of the Fourth International Workshop on Automated Debugging (AADebug 2000), August 2000, Munich. cs.SE/0010035

ACM Class: D.2.5

Non-intrusive on-the-fly data race detection using execution replay

Authors: Michiel Ronsse, Koen De Bosschere

Abstract: This paper presents a practical solution for detecting data races in parallel programs. The solution consists of a combination of execution replay (RecPlay) with automatic on-the-fly data race detection. This combination enables us to perform the data race detection on an unaltered execution (almost no probe effect). Furthermore, the usage of multilevel bitmaps and snooped matrix clocks limits t… ▽ More This paper presents a practical solution for detecting data races in parallel programs. The solution consists of a combination of execution replay (RecPlay) with automatic on-the-fly data race detection. This combination enables us to perform the data race detection on an unaltered execution (almost no probe effect). Furthermore, the usage of multilevel bitmaps and snooped matrix clocks limits the amount of memory used. As the record phase of RecPlay is highly efficient, there is no need to switch it off, hereby eliminating the possibility of Heisenbugs because tracing can be left on all the time. △ Less

Submitted 6 November, 2000; originally announced November 2000.

Comments: In M. Ducasse (ed), proceedings of the Fourth International Workshop on Automated Debugging (AAdebug 2000), August 2000, Munich. cs.SE/0010035

ACM Class: D.2.5