Fault-tolerant typed assembly language

Abstract

A transient hardware fault occurs when an energetic particle strikes a transistor, causing it to change state. Although transient faults do not permanently damage the hardware, they may corrupt computations by altering stored values and signal transfers. In this paper, we propose a new scheme for provably safe and reliable computing in the presence of transient hardware faults. In our scheme, software computations are replicated to provide redundancy while special instructions compare the independently computed results to detect errors before writing critical data. In stark contrast to any previous efforts in this area, we have analyzed our fault tolerance scheme from a formal, theoretical perspective. To be specific, first, we provide an operational semantics for our assembly language, which includes a precise formal definition of our fault model. Second, we develop an assembly-level type system designed to detect reliability problems in compiled code. Third, we provide a formal specification for program fault tolerance under the given fault model and prove that all well-typed programs are indeed fault tolerant. In addition to the formal analysis, we evaluate our detection scheme and show that it only takes 34% longer to execute than the unreliable version.

SymPLFIED: Symbolic program-level fault injection and error detection framework

“…A recent paper [8] proposes the use of typechecking to verify the fault-tolerance provided by a specific error detection mechanism, namely, compilerbased instruction duplication. The paper proposes a detailed machine model for executing programs.…”

“…However, the detection mechanism (duplication) is tightly coupled with the machine model, due to inherent assumptions that limit error propagation in the program and may not hold in non-duplicated programs. Further, the type-checking technique in [8] either accepts or rej ects a program based on whether the program has been duplicated correctly, but it does not consider the consequences of the error on the program. As a result, the program may be rejected by the technique even though the error is benign and has no effect on the program's output.…”

“…Further, existing verification techniques are often coupled with the detection mechanism (e.g. duplication) being verified [7] [8]. Therefore, there exists no generic technique that allows reasoning about the effects of arbitrary hardware faults on software, and can be combined with an arbitrary fault model and detection technique(s).…”

Verifying quantitative reliability for programs that execute on unreliable hardware

“…To prevent out-ofbounds memory accesses that may occur as a consequence of an unreliable array index computation, Rely requires that each array read and write includes a bounds check; these bounds check computations also execute reliably. Rely does not require a specific underlying mechanism to execute these operations reliably; one can use any applicable software or hardware technique [20,26,28,51,53,57,66,70].…”

“…However, aggressively pursuing these design goals can often increase the frequency of soft errors in small [67] and large systems [10] alike. Researchers have developed numerous techniques for detecting and masking soft errors in both hardware [23] and software [20,53,57,64]. These techniques typically come at the price of increased execution time, increased energy consumption, or both.…”