Tags: 0vercl0k/wtf
Tags
Fix regressing while single-stepping after a breakpoint in WHV (#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 #223 ) (#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 #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 #1 cov: 0 exec/s: 0.0 lastcov: 0.0s crash: 0 timeout: 0 cr3: 0 uptime: 0.0s ```
Load x87 state properly (#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 -_-)
PreviousNext