Faultconfig is not filtered if end is not set
aewag opened this issue · 4 comments
If the "end" keyword is not used in the fault.json, which is valid behavior as defined in the fault-readme.md, the filtering of the faultconfig, which is at [1], is not executed.
I am not sure if this is done on purpose, but I would guess filtering is as well wanted when only using "start" and "max_instruction_count" values.
EDIT: I may fail to understand how this works as I also don't get how the goldenrun_data is created in some cases: a) start and max_instruction_count or b) max_instruction_count defined. The max_instruction_count set by the user is not used, but a huge predefined number.
[1] https://github.com/Fraunhofer-AISEC/archie/blob/master/goldenrun.py#L89
To clear up the missunderstanding regarding max_instruction_count set to huge number: If end is defined the tool does not yet know how many instructions are needed to reach it. It is not an elegant solution, but at least stops qemu after a certain time if the user configuration of end is not correct. It can however lead to system hang ups on system with constraint memory.
If the end keyword is not used, goldenrun is not created. Its missing the cases when end is not provided and when start and end are not provided. Therefore no filtering is currently possible. I will look into your fix.
The fix looks good with one problem: If the start is not reached with the user provided max_instruction_count in the pre-goldenrun phase, you prompt the user to increase max_instruction_count. But this also creates more potentially unwanted data, if a fault leads to a deviation in the program flow. 2 possible solutions i see. 1) like before use a ridiculous high number or 2) make it user configurable.
Other then that good work and thank you
The fix looks good with one problem: If the start is not reached with the user provided max_instruction_count in the pre-goldenrun phase, you prompt the user to increase max_instruction_count. But this also creates more potentially unwanted data, if a fault leads to a deviation in the program flow. 2 possible solutions i see. 1) like before use a ridiculous high number or 2) make it user configurable.
I would vote for 1). Than it is similar to the goldenrun phase.
Do you remember the MIPS performance you have encountered? The max_instruction_count could maybe a bit too high to be ever reached.
I just updated the PR.
Added a missing if-statement in the case the max_instruction_count is not set in the config:
aewag@4a96378#diff-babc306897c84d773ae9a4e5d8dc0c80bff355e9241388997b37390623da6b0cR27
Added the missing overwrite of the max_instruction_count for the pre-goldenrun phase:
aewag@4a96378#diff-babc306897c84d773ae9a4e5d8dc0c80bff355e9241388997b37390623da6b0cR43