This PR is for "I/O Interface to Bochs Debugger" from ring3 (port range:
**0x8A00 - 0x8A01**)
PR #64 was for E9 HACK (port **0xE9**)
By enabling the iodebug's 'all_rings' option, you can utilize the port
I/O Interface to Bochs Debugger from ring3. This PR allows the code
running inside Bochs (ring3) to monitor memory ranges, trace individual
instructions, and observe register values during execution.
https://bochs.sourceforge.io/doc/docbook/development/debugger-advanced.html
IMO very useful for:
- user-mode sandbox (ex Cuckoo)
- malware analysis
- API/SYSCALL hook/monitor from ring3
- automation + instrumentation from user mode code
...
A complement for PR #64
**This PR is 100% backward compatibility**
btw, @stlintel I'm not certain about:
- if misc is the ideal location for this.. should I create a new
iodebug-option for this?
- should I remove the #if in 'new bx_param_bool_c'?
- the new .bochsrc entry makes sense for you?
By enabling the 'all_rings' option, you can utilize the port e9 hack
from ring3
IMO very useful for:
- user-mode sandbox (ex Cuckoo)
- malware analysis
- API/SYSCALL logger with a simple hook from ring3
- automation + instrumentation from user mode code
- ...
So yes, from this PR a user-mode-sandbox can display on the console of
the system running Bochs anything that is written to 0xE9 port
**This PR is 100% backward compatibility**
btw, @stlintel I'm not certain if **bochs/config.cc** is the ideal
location to define **bool port_e9_hack_all_rings** (unmapped io/dev is
better?)
from Fixes in VM Entry Checks for Guest Segment Registers #51
Correction in checks for Code Segment (CS):
Previously, the DPL of CS was incorrectly compared with its own RPL.
According to Intel SDM, Vol. 3C, Chapter 27.3.1.2, for non-conforming code segments (type 9 or 11), the DPL of CS should be equal to the DPL of SS.
And for conforming code segments (type 13 or 15), the DPL of CS cannot be greater than the DPL of SS.
This way VMCS is not accessed multiple times which is important for some usages
Fixes in VM Entry Checks for Guest Segment Registers #51
Correction in Type range checks for DS, ES, FS, GS:
The original code erroneously applied the check for types less than 11, excluding types equal to 11.
This is not in accordance with Intel SDM, Vol. 3C, Chapter 27.3.1.2, which states that the check should include types equal to or less than 11.
This fix corrects this by including types equal to or less than 11 in the check.
This adds over-current signaling to the USBs four host controllers.
To signal an OC, use the runtime configuration and set the checkbox (GUI) or text config's parameter to 1.
This pull request also adds USB documentation to user.dbk.
This adds over-current signaling to the USBs four host controllers.
To signal an OC, use the runtime configuration and set the checkbox (GUI) or text config's parameter to 1.
This pull request also adds USB documentation to user.dbk.
This adds over-current signaling to the USBs four host controllers.
To signal an OC, use the runtime configuration and set the checkbox (GUI) or text config's parameter to 1.
This pull request also adds USB documentation to user.dbk.
The 'd.pcap_image_t pcapture' in usb_common.h called its constructor and set 'fd' to -1. However, in the usb_device_c() constructor, we then cleared all of 'd', resetting pcapture.fd back to zero. Then on Bochs exit, the pcap_image_t destructor tried to close the file since 'fd' was zero instead of -1. To fix this, I removed the pcap_image_t constructor and now call pcap_image_init() within the usb_device_c constructor.
Shwartsman