libipt: software interrupt handling
Software interrupts receive FUP(CLIP) + TIP(BLIP?)
We can not reliably determine whether the FUP/TIP belongs to the software
interrupt or to an asynchronous interrupt that was taken before the instruction.
To distinguish the two cases we would need to read ahead but that may require
decoding an unknown amount of code (in the kernel or hypervisor or even in
different processes) until we return either to CLIP if it was an asynchronous
interrupt or to NLIP (or even to a later IP) if it wasn't.
Instead, we assume that it was an asynchronous interrupt. Control appears to
flow from before the software interrupt instruction to the interrupt handler and
back after the instruction.
This is wrong most of the time. But it is predictably wrong and it avoids the
case where we incorrectly assume a synchronous transfer and get out of sync when
we see the FUP/TIP for the software interrupt.
Update our tests to show the correct trace and the incorrect control flow.
Later patches may add heuristics that read ahead a little bit.
Change-Id: I17849efe3d51d24ace5df00ddda8bd1573b11f7d
Signed-off-by: Markus Metzger <markus.t.metzger@intel.com>
2 files changed
