Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932090AbbGJLQj (ORCPT ); Fri, 10 Jul 2015 07:16:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42345 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752224AbbGJLQb (ORCPT ); Fri, 10 Jul 2015 07:16:31 -0400 Subject: Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN To: Andy Lutomirski , Ingo Molnar References: <23d4709cee2fe92c32d41b99c7a3c1823725925a.1436312944.git.luto@kernel.org> <559C8BFE.6050604@linux.intel.com> <20150709055225.GA29556@gmail.com> <20150709055917.GA30478@gmail.com> Cc: Brian Gerst , Linus Torvalds , Arjan van de Ven , Andy Lutomirski , the arch/x86 maintainers , Linux Kernel Mailing List , Oleg Nesterov , Kees Cook , Peter Zijlstra , Borislav Petkov From: Paolo Bonzini X-Enigmail-Draft-Status: N1110 Message-ID: <559FA988.9030205@redhat.com> Date: Fri, 10 Jul 2015 13:16:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3947 Lines: 89 On 09/07/2015 20:33, Andy Lutomirski wrote: > On Wed, Jul 8, 2015 at 10:59 PM, Ingo Molnar wrote: >> >> * Ingo Molnar 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/