Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933631AbdCKBWl (ORCPT ); Fri, 10 Mar 2017 20:22:41 -0500 Received: from mga07.intel.com ([134.134.136.100]:36792 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932614AbdCKBWb (ORCPT ); Fri, 10 Mar 2017 20:22:31 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,143,1486454400"; d="scan'208";a="234777822" Message-ID: <1489195348.131264.56.camel@ranerica-desktop> Subject: Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention From: Ricardo Neri To: Andy Lutomirski Cc: Stas Sergeev , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Andy Lutomirski , Borislav Petkov , Peter Zijlstra , Andrew Morton , Brian Gerst , Chris Metcalf , Dave Hansen , Paolo Bonzini , Liang Z Li , Masami Hiramatsu , Huang Rui , Jiri Slaby , Jonathan Corbet , "Michael S. Tsirkin" , Paul Gortmaker , Vlastimil Babka , Chen Yucong , Alexandre Julliard , Fenghua Yu , "Ravi V. Shankar" , Shuah Khan , "linux-kernel@vger.kernel.org" , X86 ML , linux-msdos@vger.kernel.org, wine-devel@winehq.org Date: Fri, 10 Mar 2017 17:22:28 -0800 In-Reply-To: References: <20170308003254.27833-1-ricardo.neri-calderon@linux.intel.com> <79ba0fff-4c01-2bfa-06cb-5cfc98dd710c@list.ru> <997ba581-ecfa-b773-a48e-85b92a439836@list.ru> <1489022122.131264.33.camel@ranerica-desktop> <63231222-5b42-c8c9-02f0-0afbe702d8b5@list.ru> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2632 Lines: 69 On Fri, 2017-03-10 at 06:17 -0800, Andy Lutomirski wrote: > On Fri, Mar 10, 2017 at 3:33 AM, Stas Sergeev wrote: > > 10.03.2017 05:39, Andy Lutomirski пишет: > > > >> On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev wrote: > >>> > >>> 09.03.2017 04:15, Ricardo Neri пишет: > >>> > >>>> On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote: > >>>>> > >>>>> On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev wrote: > >>>>>> > >>>>>> 08.03.2017 19:06, Andy Lutomirski пишет: > >>>>>>> > >>>>>>> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev wrote: > >>>>>>>> > >>>>>>>> 08.03.2017 03:32, Ricardo Neri пишет: > >>>>>>>>> > >>>>>>>>> These are the instructions covered by UMIP: > >>>>>>>>> * SGDT - Store Global Descriptor Table > >>>>>>>>> * SIDT - Store Interrupt Descriptor Table > >>>>>>>>> * SLDT - Store Local Descriptor Table > >>>>>>>>> * SMSW - Store Machine Status Word > >>>>>>>>> * STR - Store Task Register > >>>>>>>>> > >>>>>>>>> This patchset initially treated tasks running in virtual-8086 > >>>>> > >>>>> mode as a > >>>>>>>>> > >>>>>>>>> special case. However, I received clarification that DOSEMU[8] > >>>>> > >>>>> does not > >>>>>>>>> > >>>>>>>>> support applications that use these instructions. > >>>>>>> > >>>>>>> Can you remind me what was special about it? It looks like you > >>>>> > >>>>> still > >>>>>>> > >>>>>>> emulate them in v8086 mode. > >>>>>> > >>>>>> Indeed, sorry, I meant prot mode here. :) > >>>>>> So I wonder what was cited to be special about v86. > >>>> > >>>> Initially my patches disabled UMIP on virtual-8086 instructions, without > >>>> regards of protected mode (i.e., UMIP was always enabled). I didn't have > >>>> emulation at the time. Then, I added emulation code that now covers > >>>> protected and virtual-8086 modes. I guess it is not special anymore. > >>> > >>> But isn't SLDT&friends just throw UD in v86? > >>> How does UMIP affect this? How does your patch affect > >>> this? > >> > >> Er, right. Ricardo, your code may need fixing. But don't you have a > >> test case for this? > > > > Why would you need one? > > Or do you really want to allow these instructions > > in v86 by the means of emulation? If so - this wasn't > > clearly stated in the patch description, neither it was > > properly discussed, it seems. > > What I meant was: if the patches incorrectly started making these > instructions work in vm86 mode where they used to cause a vm86 exit, > then that's a bug that the selftest should have caught. Yes, this is the case. I will fix this behavior... and update the test cases.