The inquiry stems from an observation that, with single-step enabled (where one TB represents a single guest instruction), conditional branch TBs (jb, ja, je, jne, etc.) were never marked as tainted.
Here's a concrete example of what I mean:
cmp edx, ebx ; Marked as tainted.
jae 0xdeadbeef ; Not marked as tainted.
As the jae uses flags based on the tainted cmp, logically jae should be tainted as well.
In root causing, the situation seems related to the fact that the various virtual CPU registers responsible for tracking flag status (e.g., CPUX86State::cc_src) are blacklisted, or removed from the taint equation.
Hi @likebreath ,
I'm curious what is the purpose of the
Analyzer::guest_vcpu_regs_black_list_? Defined here https://github.com/SVL-PSU/crete-dev/blob/master/front-end/qemu-2.3/runtime-dump/tci_analyzer.cpp#L854The inquiry stems from an observation that, with single-step enabled (where one TB represents a single guest instruction), conditional branch TBs (jb, ja, je, jne, etc.) were never marked as tainted.
Here's a concrete example of what I mean:
As the
jaeuses flags based on the taintedcmp, logicallyjaeshould be tainted as well.In root causing, the situation seems related to the fact that the various virtual CPU registers responsible for tracking flag status (e.g., CPUX86State::cc_src) are blacklisted, or removed from the taint equation.
PS. Unsurprisingly, disabling the blacklist lead to an assertion: https://github.com/SVL-PSU/crete-dev/blob/master/front-end/qemu-2.3/runtime-dump/runtime-dump.cpp#L118
Thanks,