Currently, E9Patch will disable all Intel Control-Flow Enforcement Technology (CET) features in the rewritten binary. This is because there are several problems with the interaction of E9Tool/E9Patch and Intel CET, specifically:
Indirect Branch Tracking (IBT):
E9Patch cannot rewrite the endbr64 instruction. If the endbr64 is replaced by a jump-to-trampoline, then an indirect call/jump to this location will fail.
~E9Tool's if f() goto instrumentation will fail unless the goto happens to target an endbr64 instruction. This is because the goto instrumentation is compiled down into an indirect jump in the rewritten binary.~ \
Edit: the indirect jump can use the NOTRACK prefix, which disables IBT for the instruction.
Shadow Stack (SHSTK):
In trampoline code, E9Patch translates call instructions into an explicit push+jump combination. This ensures the "original" return address (i.e., as if the program were uninstrumented) is pushed onto the stack, as opposed to a return address belonging to the trampoline. However, this will break SHSTK since the push+jump will not push anything on to the shadow stack.
Possible Solutions
Never rewrite/replace endbr64 instructions.
~Disable CET only if if f() goto (or other incompatible feature) is used.~
Implement calls as calls in trampoline code (as a user option). This may break transparency, but most programs do not care.
Intel CET Opportunities
Intel CET also helps the E9Tool/E9Patch toolchain:
E9Tool's control-flow recovery analysis is more accurate since some indirect jump/call targets are explicitly annotated with the endbr64 instruction. This is already implemented.
~E9Tool can feasibly detect when an instruction is never a jump/call target. This information could be used by E9Patch to further optimize the coverage/speed of the rewritten binary. For example, if the current instruction cannot be patched and is definitely not a target, then the previous instruction could be patched instead. Similarly, if the next instruction is not a target, it can be overwritten without the need for instruction punning.~\
Edit: unfortunately this will not work if the program uses the NOTRACK prefix, which seems to be common for things like switches (to avoid endbr64 proliferation).
Update (18/06/22): I had overlooked the optional NOTRACK prefix for indirect calls/jumps, so the comment is updated accordingly.
Currently, E9Patch will disable all Intel Control-Flow Enforcement Technology (CET) features in the rewritten binary. This is because there are several problems with the interaction of E9Tool/E9Patch and Intel CET, specifically:
Indirect Branch Tracking (IBT):
endbr64instruction. If theendbr64is replaced by a jump-to-trampoline, then an indirect call/jump to this location will fail.if f() gotoinstrumentation will fail unless thegotohappens to target anendbr64instruction. This is because thegotoinstrumentation is compiled down into an indirect jump in the rewritten binary.~ \ Edit: the indirect jump can use theNOTRACKprefix, which disables IBT for the instruction.Shadow Stack (SHSTK):
callinstructions into an explicitpush+jumpcombination. This ensures the "original" return address (i.e., as if the program were uninstrumented) is pushed onto the stack, as opposed to a return address belonging to the trampoline. However, this will break SHSTK since thepush+jumpwill not push anything on to the shadow stack.Possible Solutions
endbr64instructions.if f() goto(or other incompatible feature) is used.~calls ascalls in trampoline code (as a user option). This may break transparency, but most programs do not care.Intel CET Opportunities
Intel CET also helps the E9Tool/E9Patch toolchain:
endbr64instruction. This is already implemented.NOTRACKprefix, which seems to be common for things like switches (to avoidendbr64proliferation).Update (18/06/22): I had overlooked the optional
NOTRACKprefix for indirect calls/jumps, so the comment is updated accordingly.