Virtual Fault Space Abstraction

[stettberger]

This is a large change that will break your traces and your database
layouts. However, it repairs a lot of ad-hoc hacks that came into
FAIL* over the years.

What has changed?

The Virtual Fault Space Abstraction

Files: sal/faultspace/*
sal/x86/X86Faultspace.*
sal/arm/ArmFaultSpace.*

Instead of mapping registers ad-hoc into the virtual address space in
order to smuggle the bit-packed register-id from import-trace through
prune-trace and DatabaseCampaign to the DatabaseExperiment, we make
this mapping now official and adaptable to more complex architectures.

From now on the data_address field in the database is a fsp_address_t.
These addresses are translated by the FS abstraction within the
importer, which uses the architecture specific description of the
virtual fault space.

Within our whole tool chain, we now only work with fault-space
addresses, which are the Y-axis of our fault space.

When the fault-space address is about to be injected, we decode the
numerical address to a FaultSpaceElement*, which knows how to inject a
fault into itself. Thereby, we can unify the injection over different
types of machine state and support multiple memory types.

Furthermore, this simplifies import-trace and the DatabaseExperiment
significantly.

A detailed description of can be found in Malte Bargholz' Master thesis[1]

Bit-Masks in Database

With this breaking change, FAIL* does no longer use widths of data
accesses in its database schema, but bit masks. Thereby it is possible
to prevent or focus on the injection of individual bits.

For this change, the following database tables use masks with the
following meanings:

• trace.data_mask: given bits were accessed
• fspgroup.data_mask: complete or partial match of a trace-table
  entries data-mask
• fsppilot.data_mask: given bits are to be injected with this pilot

In order to reflect these database changes, you should
add (fspgroup.data_mask & trace.data_mask) to your join between trace
and fspgroup table to record for a cardinalty mismatch between both
tables. However, for the basic pruner (def-use pruner), this is not
necessary, as the data mask is in both cases 255.

Bit-Wise Pruning

Files: tools/import-trace/Importer.cc

Until now, every state (register/memory) access had to be at least 8
bits wide. While this is good for memory reads, which always access at
least a whole byte, this is not properly working for register
accesses. Especially, for our integration of more complex CPU
architectures (i.e., CHERI), we have to have bit-wise pruning to
inject only single tag bits instead of injecting always 8 tag bits.

Therefore, this change introduces bit-wise pruning for our importer.
Instead of tracking only a single left margin for every fault-space
address, we now track up to 8 different margins that are associated
with an access mask. Thereby, the importer (which is effectively a
def-use pruner) has to handle up to 8 left margins when accessing a
byte with an access mask of 0xff.

A detailed description of can be found in Malte Bargholz' Master thesis[1]

Unification of Disassembler Interface

The integration of the capstone disassembler into the RegisterImporter
was more or less a clone-and-own integration. However, as both
disassemblers basically perform the same task, a common interface is
possible.

Furthermore, the FailToTranslator* classes are no longer used for
injecting registers as the dissassembler has nothing to do with the
injector. This task is no performed by the virtual fault space.

This change was tested with:

• The integrated test-suite
• The fail-target repo and injection of register,memory,EIP,randomjump
• Both disassemblers

Currently untested:

• Gem5

[1] Quantifying Soft-Error Resilience of Embedded RISC-V Systems with Capability-based Memory Protection
https://www.sra.uni-hannover.de/Theses/2020/bargholz_20_ma.pdf