On Wed, 14 Sep 2016, Bruce Evans wrote:
... Log: ... Fix logic errors in treating vm86 bioscall mode as kernel mode. The main place checked all the necessary flags, but put the necessary parentheses for the PSL_VM and PCB_VM86CALL checks in the wrong place. The broken case is only reached if a vm86 bioscall uses a %cs which is nonzero mod 4, but that is unusual -- most bios calls start with %cs = 0xc000 or 0xf000 and rarely change it. Another place was missing the check for PCB_VM86CALL, but was only reachable if there are bugs virtualizing PSL_I.
Forgot: Reviewed by: kib Just before committing, I checked when this was broken. It was in the Giant attack for SMPng. vm86 bios calls need mutual exclusion, and apparently Giant was used, and WITNESS warned about this, so as a quick fix vm86 bios calls were treated as kernel mode although this causes other problems. Now vm86 bios calls use vm86_lock instead of Giant, but the quick fix is still in place. vm86 bios calls shouldn't be treated as kernel mode, but I used this recently to debug one. ddb almost worked on them without really trying. It should work similarly on normal vm86 user mode and normal user mode if we sent the debugger traps to ddb instead of to the thread. There is the problem that users must not be allowed to enter the kernel using unprivileged debugger traps. Already for vm86 bios calls, we depend on BIOSes not generating any debugger traps. My recent changes to keep the trace flag set by ddb will have to be reviewed to make sure that if vm86 mode initiates the setting of the trace flag then the resulting trap doesn't go to the kernel. Bruce _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
