Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN

[Paolo Bonzini <pbonzini@redhat.com>]

On 09/07/2015 20:33, Andy Lutomirski wrote:
> On Wed, Jul 8, 2015 at 10:59 PM, Ingo Molnar <mingo@kernel.org> wrote:
>>
>> * Ingo Molnar <mingo@kernel.org> wrote:
>>
>>>> Without something like that, we'll be in the awkward position of having some
>>>> of the selectors (DS, ES, FS, and GS) in both the normal pt_regs slot and in
>>>> the extended hardware frame during execution of normal vm86-unaware kernel
>>>> code.  If, on the other hand, we copied the selectors across in
>>>> enter_from_user_mode and prepare_return_from_usermode, then pt_regs would work
>>>> normally even for tasks that are running in v8086 mode.
>>>>
>>>> regs->flags & X86_EFLAGS_VM will be true regardless, so all of the asm that
>>>> decides to invoke those helpers should work fine.
>>>
>>> Btw., has anyone considered an entirely different approach: using KVM's
>>> instruction emulator to emulate vm86 16-bit code execution? Basically the vm86
>>> system call would be kept compatible, but fully emulated, the CPU never enters
>>> true 16-bit mode, just iterates pt_regs as if it had.
>>>
>>> This approach has four main advantages:
>>>
>>>  - we could remove the fragile vm86 code from the entry code
>>>
>>>  - it might even be faster for certain workloads than faulting in and out all
>>>    the time and using ancient, fragile hardware mode of the CPU. (For example it
>>>    could detect the VGA screen write patterns and accelerate them.)
>>>
>>>  - it could be made to work on 64-bit as well, FWIIW
>>>
>>>  - it would provide another angle of testing for the KVM emulator
>>
>> So there's a fifth advantage as well that I think needs to be stressed:
>>
>>    - it's an _obviously_ much more secure design, as we only iterate user-space
>>      pt_regs and never truly touch any security relevant CPU state. The whole
>>      nested pt_regs and different hw frame entry complications would go away
>>      entirely. All CPU semantics would not be just assumed implicitly, but would
>>      be very much present in the CPU emulator and would be reviewable.
>>
> 
> Hmm.
> 
> If we did this, I think I'd prefer a slightly more general approach.
> First teach KVM to support a mode in which it's purely an emulator
> (Paolo: how hard is this?  It would also make testing the emulator
> much easier).

This isn't hard, at least for Intel: make emulation_required() return
true always (and fix the fallout).  However, it's not necessary.  The
emulator is designed to be independent from the rest of KVM.  At some
point I think Avi was testing it in userspace (or planning to do so).
So you would just move it from arch/x86/kvm to arch/x86/emulate.

The obvious downside is that the emulator isn't really designed for
speed.  In KVM it's currently 1000-1500 times slower than the real
thing.  Even if you modified it to remove the KVM overhead (vm86 is just
running ring 3 code; no interrupts and no pagetables to walk), it
probably would take 300-500 cycles to execute one instruction.

But it's doable.

> The big downside of that, or of writing a more ad-hoc emulator, is
> understanding what the semantics of all the weird vm86plus stuff is
> supposed to be in the first place.

Do you mean VIF/VIP and the other vm86 mode extensions?  Or is vm86plus
something in Linux?

Paolo

> It's completely undocumented and
> it's not at all obvious what it's all supposed to do.  This sounds
> like a fairly large project.
> 
> I think I'd rather get all the distros to turn vm86 off and let it
> slowly die in a dark corner.  After all, dosemu and vbetool both
> already contain emulators that seem to work, and dosbox (which is, by
> all reports, better than dosemu) never used vm86 in the first place.
> 
> --Andy
>