From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754198AbdCJCmP convert rfc822-to-8bit (ORCPT ); Thu, 9 Mar 2017 21:42:15 -0500 Received: from mail.kernel.org ([198.145.29.136]:35614 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752659AbdCJCmN (ORCPT ); Thu, 9 Mar 2017 21:42:13 -0500 MIME-Version: 1.0 In-Reply-To: <1489021909.131264.30.camel@ranerica-desktop> References: <20170308003254.27833-1-ricardo.neri-calderon@linux.intel.com> <79ba0fff-4c01-2bfa-06cb-5cfc98dd710c@list.ru> <997ba581-ecfa-b773-a48e-85b92a439836@list.ru> <1489021909.131264.30.camel@ranerica-desktop> From: Andy Lutomirski Date: Thu, 9 Mar 2017 18:41:43 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention To: Ricardo Neri 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 , 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 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 On Wed, Mar 8, 2017 at 5:11 PM, Ricardo Neri wrote: > On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote: >> 08.03.2017 19:46, Andy Lutomirski пишет: >> >> No no, since I meant prot mode, this is not what I need. >> >> I would never need to disable UMIP as to allow the >> >> prot mode apps to do SLDT. Instead it would be good >> >> to have an ability to provide a replacement for the dummy >> >> emulation that is currently being proposed for kernel. >> >> All is needed for this, is just to deliver a SIGSEGV. >> > That's what I meant. Turning off FIXUP_UMIP would leave UMIP on but >> > turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86 >> > GP exit). >> But then I am confused with the word "compat" in >> your "COMPAT_MASK0_X86_UMIP_FIXUP" and >> "sys_adjust_compat_mask(int op, int word, u32 mask);" >> >> Leaving UMIP on and only disabling a fixup doesn't >> sound like a compat option to me. I would expect >> compat to disable it completely. > > I guess that the _UMIP_FIXUP part makes it clear that emulation, not > UMIP is disabled, allowing the SIGSEGV be delivered to the user space > program. > > Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a > COMPAT_MASK0_X86_UMIP to disable UMIP make sense? > > Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its > purpose? Applications could simply use this compat mask to bypass UMIP > and gain access to the instructions it protects. > I was obviously extremely unclear. The point of the proposed syscall is to let programs opt out of legacy features. So there would be a bit to disable emulation of UMIP-blocked instructions (this giving the unadulterated #GP). There would not be a bit to disable UMIP itself. There's also a flaw in my proposal. Disable-vsyscall would be per-mm and disable-umip-emulation would be per-task, so they'd need to be in separate words to make any sense. I'll ponder this a bit more.