Fix regressing while single-stepping after a breakpoint in WHV (0verc…

…l0k#228)

In v0.5.5 I introduced a regression in WHV where the code handling the single step exception generated after handling a breakpoint didn't properly remove the trap flag which leads to another VMEXIT but this time is not expected.

I thought the bit would get stripped off by the CPU it was getting removed by the CPU but maybe VMX behaves differently? I've looked through the manuals a bit but I didn't really find anything conclusive. If you know why / where this is documented please let me know :)

Disable single stepping once we've stepped over the breakpoint (fix 0…

…vercl0k#223) (0vercl0k#224)

This PR fixes a regression in the KVM backend that was introduced in `v0.5.5` when implementing RIP traces. 

The issue happens when the user has a breakpoint set-up that won't move execution; in that case `wtf` needs to step-over that breakpoint to carry on execution. To do that, it temporarily removes the breakpoint off of memory and will single-step this instruction. After the single-step, we receive a fault and we can figure out that the reason why we're getting this fault is because we were single-stepping over a breakpoint in which case we need to re-enable it, etc.

Because that single-step bit wasn't properly unset in that case, execution would carry on and re-enter with another single step instruction but this time the state didn't indicate that it was because we were performing a step-over, so `wtf` aborts.

Here is an illustration of the bug with the HEVD/KVM with logging on:
```
bubuntu:~/wtf/targets/hevd$ sudo ../../src/build/wtf run --name hevd --input ./inputs/A --backend kvm
...
Running ./inputs/A
kvm: exit_reason = KVM_EXIT_DEBUG @ 0x7ff6f5bb111e
kvm: Handling bp @ 0x7ff6f5bb111e
Hevd: Hello!
kvm: Disarming bp and turning on RFLAGS.TF (rip=0x7ff6f5bb111e)
kvm: Turning on RFLAGS.TF
kvm: exit_reason = KVM_EXIT_DEBUG @ 0x7ff83e2e6360
kvm: Received debug trap @ 0x7ff83e2e6360 <------------------------ first, expected trap
kvm: Resetting breakpoint @ 0xd37411e
kvm: Turning off RFLAGS.TF                              <------------------------ this was actually not done
kvm: exit_reason = KVM_EXIT_DEBUG @ 0x7ff83e2e6365
kvm: Received debug trap @ 0x7ff83e2e6365 <------------------------- second trap which is unexpected
Got into OnDebugTrap with LastBreakpointGpa_ = none
--------------------------------------------------
Run stats:
          Dirty pages: 53248 bytes, 13 pages, 0 MB
            UffdPages: 90112 bytes, 22 pages, 0 MB
              VMExits: 3
Instructions executed: 2
0vercl0k#1 cov: 0 exec/s: 0.0 lastcov: 0.0s crash: 0 timeout: 0 cr3: 0 uptime: 0.0s
```

Here is the expected output / the fixed version:

```
bubuntu:~/wtf/targets/hevd$ sudo ../../src/build/wtf run --name hevd --input ./inputs/A --backend kvm
...
Running ./inputs/A
kvm: exit_reason = KVM_EXIT_DEBUG @ 0x7ff6f5bb111e
kvm: Handling bp @ 0x7ff6f5bb111e
Hevd: This is a breakpoint executed before the first instruction :)
kvm: Disarming bp and will turn on single step (rip=0x7ff6f5bb111e)
kvm: Turning on SINGLESTEP
kvm: exit_reason = KVM_EXIT_DEBUG @ 0x7ff83e2e6360
kvm: Received debug trap @ 0x7ff83e2e6360
kvm: Resetting breakpoint @ 0xd37411e
kvm: Turning off SINGLESTEP
kvm: exit_reason = KVM_EXIT_DEBUG @ 0xfffff8046f122bb0
kvm: Handling bp @ 0xfffff8046f122bb0
Hevd: DbgPrintEx: [-] Invalid IOCTL Code: 0x%X
kvm: The bp handler ended up moving @rip from 0xfffff8046f122bb0 to 0xfffff8046ca955ec so no need to do the step-over dance
kvm: exit_reason = KVM_EXIT_DEBUG @ 0x7ff6f5bb1124
kvm: Handling bp @ 0x7ff6f5bb1124
Hevd: Back from kernel!
kvm: The bp handler asked us to stop so no need to do the step-over dance
--------------------------------------------------
Run stats:
          Dirty pages: 663552 bytes, 162 pages, 0 MB
            UffdPages: 684032 bytes, 167 pages, 0 MB
              VMExits: 4
Instructions executed: 6400
0vercl0k#1 cov: 0 exec/s: 0.0 lastcov: 0.0s crash: 0 timeout: 0 cr3: 0 uptime: 0.0s
```

Update README.md

Add support for Linux userland ELF snapshots and fuzzing (0vercl0k#192)

Co-authored-by: 0vercl0k <[email protected]>

kdmp-parser v072 (0vercl0k#198)

Load x87 state properly (0vercl0k#193)

The way `@fptw` was handled has been wrong for a long time but I finally figured out. This updates all the backends to do the right thing.

Other more minor changes:
  - The code that reads the CPU state has been updated to be compatible with [snapshot](https://github.com/0vercl0k/snapshot). It also should be now able to load precise values for 80-bit registers. Loading 'old' dumps should also work as they were before (with the buggy code) to not break them
  - Updated bxcpu to be able to load `@fpst` registers with a `frac` / `exponent` (cf yrp604/bochscpu@cab8051)
  - Minor updates to the README
  - Update the CI to get rid of warnings as well as removing the CodeQL scanning (it hasn't reported a single hit since it's been turned on -_-)

Update `kdmp-parser` to v0.7.1 (0vercl0k#190)

The latest version of `kdmp-parser` now supports parsing the new kernel dumps types (8, 9, 10) that recent WinDbg generates.

Use clang16 for the CI (0vercl0k#179)

Update gifs (0vercl0k#151)

Grab the bugcheck code as part of crash detection and fix rdrand opco…

…de detection (0vercl0k#115)