|
EFInjectFault Injection on Firmware Level![]() Software-implemented fault injection (SWIFI) is an established method to emulate hardware faults in computer systems. Existing approaches either extend the operating system by special drivers, modify the runtime environment, or change the application under test. The FutureSOC project on novel SWIFI approaches investigates new ideas for adding fault injection as standard dependability assessment tool in modern server environments. One approach relies on the Extensible Firmware Interface (EFI), the BIOS-successor available in latest X86 systems as provided by the FutureSOC lab. Our approach extends the firmware of these systems in order to a) make fault injection completely transparent to the operating system, and to b) support a larger variety of fault types. No modifications to the operating system or the application code are needed. Our prototype is available for free use in non-commerical usage scenarios. Below you can find installation and configuration instructions. Binaries are provided for download at the end of the page. In case of further questions, please contact Peter Tröger. InstallationExtract the following files from the binary distribution into a folder on the EFI system partition:
Depending on the operating system you need the following files accessible from within the operating system:
Injection cyclesEFInject is prepared to perform injections several times. The package provides a helper script and application to run a specified number of injection cycles. First of all you need to configure the injection itself. The configuration method is described in a separate section below. After configuring the driver you can set the number of injection cycles using the helper application: InjectReportApp setcycles [count] To integrate with EFInject with your system you have to modify both the loadefinject.nsh and your startup.nsh. In loadefinject.nsh replace the exit command with whatever is necessary to boot the operating system under test. Then modify your startup.nsh so that you change the directory to the one where the EFInject file live and that loadefinject.nsh is called afterwards. Finally make sure that the default boot option is the internal EFI shell which calls the startup.nsh script. Modify the operating so that it starts the appropriate tick script with root/Administrator privileges during boot. ConfigurationTo configure EFInject, launch the EFInject helper application from the EFI Shell in the following way: InjectReportApp configure [configuration string] The configuration string consists of four parameters delimited by semicolons:
Both injectors always work with native-sized memory words, i.e. with DWORDs on IA32 and with QWORDs on X64. The OR-XOR-semantics allow for four different actions for each bit in the register/memory location:
At this time the supported registers are:
Configuration Examples
TroubleshootingIf something does not work, try the following steps: The configuration oneshot;1;nop; should always be valid regardless of the underlying platform. Therefore the following commands should always work and result in a running driver: InjectReportApp.efi configure oneshot;1;nop; load InjectReportDxe.efi To test the driver itself, you can issue commands from the EFI shell. As the driver uses the variable interface to communicate with the shell and operating systems, you can use the dmpstore tool to run some tests. The following command should print some data showing a UTF16-encoded Callback works! string: dmpstore Test If you run Linux as an operating system after loading the driver, the equivalent to the command above would be: (run as root) hd /sys/firmware/efi/vars/Test-8b1cd116-7f14-4594-8474-edbebda318ce/data In the commands above, you can replace the verb Test with Inject to perform an immediate injection (independent of any trigger) or Tick to call the trigger once. |