svn commit: r305807 - in head/sys: amd64/amd64 i386/i386 x86/include

[Bruce Evans]

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