Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932594AbbGJQo3 (ORCPT ); Fri, 10 Jul 2015 12:44:29 -0400 Received: from mail-lb0-f181.google.com ([209.85.217.181]:33395 "EHLO mail-lb0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754395AbbGJQoW (ORCPT ); Fri, 10 Jul 2015 12:44:22 -0400 MIME-Version: 1.0 In-Reply-To: References: <23d4709cee2fe92c32d41b99c7a3c1823725925a.1436312944.git.luto@kernel.org> <559C8BFE.6050604@linux.intel.com> <87twtc14po.fsf@x220.int.ebiederm.org> From: Andy Lutomirski Date: Fri, 10 Jul 2015 09:44:01 -0700 Message-ID: Subject: Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN To: Linus Torvalds Cc: "Eric W. Biederman" , Arjan van de Ven , Andy Lutomirski , "the arch/x86 maintainers" , Linux Kernel Mailing List , Oleg Nesterov , Kees Cook , Peter Zijlstra , Borislav Petkov Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1942 Lines: 47 On Fri, Jul 10, 2015 at 9:35 AM, Linus Torvalds wrote: > On Fri, Jul 10, 2015 at 7:37 AM, Andy Lutomirski wrote: >> >> Having just written a pile of tests for it, I don't think so, as long as none >> of the syscall slow path stuff is in use :( > > It seems that you are thinking that people actually use vm86 mode as a > real Linux mode, and do system calls from it etc. Nope. > > The common situation is that you enter vm86 mode with vm86(), and that > you exit it due to one of the (many) unhandled situations or a signal > or whatever. Yeah,we handle a few sad instructions directly, but most > vm86 exits just return to user mode. > > The system call paths just aren't an issue in reality, because they > just aren't used. > That's not what I mean. I'm referring to the vm86 syscall itself. If you have a ti flag that causes the slow exit path to be used, then you call vm86. vm86 sets up the ludicrous double stack frame that it uses and jumps back to the exit asm. The exit asm then branches off to the slow path, hits the notifysig_v86 kludge, calls save_v86_state, tears down its double stack frame, and keeps meandering back through the exit asm. We finally IRET right back to protected mode, and the code that userspace was trying to execute in v8086 mode never actually runs. That code looked fishy when I first read it, and it is, indeed, entirely incorrect. So the vm86 syscall itself is broken if the slow path is in use. Fortunately, you can't do an a syscall inside vm86. If you could, I think it would be a disaster, because the double stack means that the syscall would run in a completely bogus context. --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/