From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QveDG-0006Wh-2k for user-mode-linux-devel@lists.sourceforge.net; Mon, 22 Aug 2011 23:47:26 +0000 Received: from terminus.zytor.com ([198.137.202.10] helo=mail.zytor.com) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1QveDF-0003Hu-CF for user-mode-linux-devel@lists.sourceforge.net; Mon, 22 Aug 2011 23:47:26 +0000 Message-ID: <4E52EA50.6070105@zytor.com> Date: Mon, 22 Aug 2011 16:46:24 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 References: <20110822011645.GM2203@ZenIV.linux.org.uk> <4E51B56F.3080301@zytor.com> <20110822020737.GP2203@ZenIV.linux.org.uk> <4E51D597.3060800@zytor.com> <20110822095336.GB25949@kernel.org> <20110822144051.GD2946@aftab> <20110822151305.GV2203@ZenIV.linux.org.uk> <4E52B7F8.3050002@zytor.com> <4E52D280.3010107@zytor.com> In-Reply-To: List-Id: The user-mode Linux development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: user-mode-linux-devel-bounces@lists.sourceforge.net Subject: Re: [uml-devel] SYSCALL, ptrace and syscall restart breakages (Re: [RFC] weird crap with vdso on uml/i386) To: Linus Torvalds Cc: Andrew Lutomirski , "user-mode-linux-devel@lists.sourceforge.net" , Richard Weinberger , "linux-kernel@vger.kernel.org" , Borislav Petkov , "mingo@redhat.com" , Al Viro , Ingo Molnar On 08/22/2011 04:27 PM, Linus Torvalds wrote: > On Mon, Aug 22, 2011 at 3:04 PM, H. Peter Anvin wrote: >> >> However, we could just issue a SIGILL or SIGSEGV at this point; the same >> way we would if we got an #UD or #GP fault; SIGILL/#UD would be >> consistent with Intel CPUs here. > > Considering that this is not a remotely new issue, and that it has > been around for years without anybody even noticing, I'd really prefer > to just fix things going forwards rather than add any code to actively > break any possible unlucky legacy users. > > So I think the "let's fix the vdso case for sysenter" + "let's remove > the 32-bit syscall vdso" is the right solution. If somebody has > hardcoded syscall instructions, or generates them dynamically with > some JIT, that's their problem. We'll continue to support it as well > as we ever have (read: "almost nobody will ever notice"). > > One thing we *could* do is to just say "we never restart a x86-32 > 'syscall' instruction at all", and just make such a case return EINTR. > IOW, do something along the lines of the appended pseudo-patch. > > Because returning -EINTR is always "almost correct". > I have to say it worries me from a potential security hole point of view, especially since it clearly isn't very well trod ground to begin with. An almost-never-used path with access to the full system call suite is scarier than hell in that sense. Keep in mind support for SYSCALL32 is already (vendor-)conditional. (The obvious solution of just putting the proper register frame back in its place would be okay except for totally breaking anything trace-on-exit as already hashed to death...) -hpa ------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754178Ab1HVXrh (ORCPT ); Mon, 22 Aug 2011 19:47:37 -0400 Received: from terminus.zytor.com ([198.137.202.10]:49971 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751668Ab1HVXre (ORCPT ); Mon, 22 Aug 2011 19:47:34 -0400 Message-ID: <4E52EA50.6070105@zytor.com> Date: Mon, 22 Aug 2011 16:46:24 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: Linus Torvalds CC: Andrew Lutomirski , Al Viro , Borislav Petkov , Ingo Molnar , "user-mode-linux-devel@lists.sourceforge.net" , Richard Weinberger , "linux-kernel@vger.kernel.org" , "mingo@redhat.com" Subject: Re: [uml-devel] SYSCALL, ptrace and syscall restart breakages (Re: [RFC] weird crap with vdso on uml/i386) References: <20110822011645.GM2203@ZenIV.linux.org.uk> <4E51B56F.3080301@zytor.com> <20110822020737.GP2203@ZenIV.linux.org.uk> <4E51D597.3060800@zytor.com> <20110822095336.GB25949@kernel.org> <20110822144051.GD2946@aftab> <20110822151305.GV2203@ZenIV.linux.org.uk> <4E52B7F8.3050002@zytor.com> <4E52D280.3010107@zytor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/22/2011 04:27 PM, Linus Torvalds wrote: > On Mon, Aug 22, 2011 at 3:04 PM, H. Peter Anvin wrote: >> >> However, we could just issue a SIGILL or SIGSEGV at this point; the same >> way we would if we got an #UD or #GP fault; SIGILL/#UD would be >> consistent with Intel CPUs here. > > Considering that this is not a remotely new issue, and that it has > been around for years without anybody even noticing, I'd really prefer > to just fix things going forwards rather than add any code to actively > break any possible unlucky legacy users. > > So I think the "let's fix the vdso case for sysenter" + "let's remove > the 32-bit syscall vdso" is the right solution. If somebody has > hardcoded syscall instructions, or generates them dynamically with > some JIT, that's their problem. We'll continue to support it as well > as we ever have (read: "almost nobody will ever notice"). > > One thing we *could* do is to just say "we never restart a x86-32 > 'syscall' instruction at all", and just make such a case return EINTR. > IOW, do something along the lines of the appended pseudo-patch. > > Because returning -EINTR is always "almost correct". > I have to say it worries me from a potential security hole point of view, especially since it clearly isn't very well trod ground to begin with. An almost-never-used path with access to the full system call suite is scarier than hell in that sense. Keep in mind support for SYSCALL32 is already (vendor-)conditional. (The obvious solution of just putting the proper register frame back in its place would be okay except for totally breaking anything trace-on-exit as already hashed to death...) -hpa