ScEpTIC.emulator.intermittent_executor.interruption_managers package¶

Submodules¶

ScEpTIC.emulator.intermittent_executor.interruption_managers.base module¶

class ScEpTIC.emulator.intermittent_executor.interruption_managers.base.InterruptionManager(vmstate, checkpoint_manager)¶

Bases: object

Base interruption manager

collect_memory_trace = False¶

do_data_anomaly_check = False¶

has_stack_activation_record_anomalies(reset_pc, append_anomaly=True)¶: Verifies if the stack portion of a call is modified by subsequent operations.

input_lookup_enabled = False¶

intermittent_execution_required()¶: Returns if the current operation requires an intermittent execution. Retruns always false, as base simulates a continuous execution

requires_static_checkpoint = False¶

run_with_intermittent_execution()¶: Runs tests in intermittent execution scenario.

ScEpTIC.emulator.intermittent_executor.interruption_managers.input module¶

class ScEpTIC.emulator.intermittent_executor.interruption_managers.input.InputInterruptionManager(vmstate, checkpoint_manager)¶

Bases: ScEpTIC.emulator.intermittent_executor.interruption_managers.base.InterruptionManager

Interruption manager for analyzing input policies

input_lookup_enabled = True¶

intermittent_execution_required()¶: To verify input anomalies no interruption is required: interruptions will only introduce war anomalies / memory map anomalies. Input access anomalies are measurable without running in intermittent scenario, because they refers to a previous checkpoint. It is sufficient to run the program sequentially: when a checkpoint is encountered, just skip it and increment the checkpoint_clock. The system will automatically check the input lookup table of registers and memory w.r.t. the current checkpoint_clock. If a discrepancy is found between the measured consistency model and the one required by the programmer, an anomaly is created.

requires_static_checkpoint = True¶

run_with_intermittent_execution()¶: Runs tests in intermittent execution scenario.

ScEpTIC.emulator.intermittent_executor.interruption_managers.memory_evaluate module¶

class ScEpTIC.emulator.intermittent_executor.interruption_managers.memory_evaluate.EvaluateMemoryAnomaliesInterruptionManager(vmstate, checkpoint_manager)¶

Bases: ScEpTIC.emulator.intermittent_executor.interruption_managers.base.InterruptionManager

Interruption manager for evaluating the effects of memory-related intermittence anomalies

do_data_anomaly_check = True¶

intermittent_execution_required()¶: Returns if the current operation requires an intermittent execution.

run_with_intermittent_execution()¶

Runs an intermittent execution as an interrupt was generated just before the current instruction. In case of a dynamic checkpoint mechanism, it tests all the next #execution_depth operations. In case of a static checkpoint mechanism, it tests all the next operations until another checkpoint is reached. For static but dynamic checkpoint mechanisms (-> checkpoint statically placed BUT taken only if power is low) the analysis is the same as for the static ones: if I take a checkpoint and then some energy restores my buffer, I can get past the execution depth, so is required to analyze the interval from a checkpoint to another (-> execution depth = till next checkpoint, as in static case).

All the instructions are tested incrementally, so to get all the possible combination of machine resets, and so to observe all possible anomalies. If a MemoryException happens, the subsequent instructions cannot be tested, so a consistent dump is restored and the execution continue in continuous mode.

Resets are generated on each instruction which writes on a previosuly read memory area which resides in the NVM/NVM. To achieve such optimization of resets points:

When a load is run:

if its address is in the address space to be verified, save it for further comparisons

if its address is in the address space to be verified, and is not the one on which the interruption was generated, set a marker for restore_end_execution.

When a store is run, if the target address is in the ones saved from the previously executed loads, resets the state and test the execution until such store is executed.
If an anomaly happens during such testing, it is stored in the vmstate.anomalies list.

If an operation (different from the first one) which requires intermittent execution testing is run, a marker is set. At the end of the intermittent execution, if such marker is set, a consistent dump is restored since further testing is required in the interval, and in order to be able to observe all possible anomalies (and not false-positive due to previous anomalies), the state must be restored to a consistent one.

If heap is stored in NVM/NVM, a reset is required afeter each heap-specific operation: malloc/free/realloc/calloc.: -> heap memory wasting is not part of my analysis, so I do not track wasting due to re-execution of malloc/calloc.

If stack is stored in NVM/NVM, a reset is required after each function call (due to stack pushes of arguments, registers, ebp, pc).

When a reset in triggered, the checkpoint is restored and the instructions are executed until the operation which have generated the reset is reached. If an anomaly is found, a consistent state is restored and the execution is forced in continuous execution until the operation which have generated the reset is reached. Then the intermittent executions continues to do so until the interval termination condition is verified (execution depth reached or checkpoint reached).

ScEpTIC.emulator.intermittent_executor.interruption_managers.memory_locate module¶

class ScEpTIC.emulator.intermittent_executor.interruption_managers.memory_locate.LocateMemoryAnomaliesInterruptionManager(vmstate, checkpoint_manager)¶

Bases: ScEpTIC.emulator.intermittent_executor.interruption_managers.base.InterruptionManager

Interruption manager for locating memory-related intermittence anomalies

analyze_memory_traces()¶: Analyzes memory traces

collect_memory_trace = True¶

intermittent_execution_required()¶: The analysis runs inside run_with_intermittent_execution

run_with_intermittent_execution()¶: Runs the test

ScEpTIC.emulator.intermittent_executor.interruption_managers.output module¶

class ScEpTIC.emulator.intermittent_executor.interruption_managers.output.OutputInterruptionManager(vmstate, checkpoint_manager)¶

Bases: ScEpTIC.emulator.intermittent_executor.interruption_managers.base.InterruptionManager

Interruption manager for analyzing output interactions

intermittent_execution_required()¶: Returns if the current operation requires an intermittent execution. Retruns always false, as base simulates a continuous execution

requires_static_checkpoint = True¶

run_with_intermittent_execution()¶: Runs tests in intermittent execution scenario.

ScEpTIC.emulator.intermittent_executor.interruption_managers.profiling module¶

class ScEpTIC.emulator.intermittent_executor.interruption_managers.profiling.ProfilingInterruptionManager(vmstate, checkpoint_manager)¶

Bases: ScEpTIC.emulator.intermittent_executor.interruption_managers.base.InterruptionManager

Interruption manager for profiling intermittent executions

intermittent_execution_required()¶: Returns if the current operation requires an intermittent execution. Retruns always false, as base simulates a continuous execution

requires_static_checkpoint = False¶

run_with_intermittent_execution()¶: Runs tests in intermittent execution scenario.

Module contents¶

ScEpTIC.emulator.intermittent_executor.interruption_managers.get_interruption_manager(name, class_name)¶: Returns the proper interruption manager class