From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756573Ab1HVBtG (ORCPT ); Sun, 21 Aug 2011 21:49:06 -0400 Received: from terminus.zytor.com ([198.137.202.10]:45761 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752891Ab1HVBtD (ORCPT ); Sun, 21 Aug 2011 21:49:03 -0400 Message-ID: <4E51B56F.3080301@zytor.com> Date: Sun, 21 Aug 2011 18:48:31 -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: Al Viro , Andrew Lutomirski , mingo@redhat.com, Richard Weinberger , user-mode-linux-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Re: SYSCALL, ptrace and syscall restart breakages (Re: [RFC] weird crap with vdso on uml/i386) References: <20110820201406.GF2203@ZenIV.linux.org.uk> <4E501F51.9060905@nod.at> <20110821063443.GH2203@ZenIV.linux.org.uk> <20110821084230.GI2203@ZenIV.linux.org.uk> <20110821144352.GJ2203@ZenIV.linux.org.uk> <20110821164124.GL2203@ZenIV.linux.org.uk> <20110822011645.GM2203@ZenIV.linux.org.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/21/2011 06:41 PM, Linus Torvalds wrote: > If people are using syscall directly, we're pretty much stuck. No > amount of "that's hopelessly wrong" will ever matter. We don't break > existing binaries. > > That said, I'd *hope* that everybody uses the vdso32, simply because > user programs are not supposed to know which CPU they are running on > and if that CPU even *supports* the syscall instruction. In which case > it may be possible that we can play games with the vdso thing. But > that really would be conditional on "nobody ever reports a failure". I think we found that out with the vsyscall emulation issue last cycle. It works, so it will have been used, somewhere... > But if that's possible, maybe we can increment the RIP by 2 for > 'syscall', and slip an "'int 0x80" after the syscall instruction in > the vdso there? Resulting in the same pseudo-solution I suggested for > sysenter... I think we have the above problem. The problem here is that the syscall state is actually more complex than we retain: the entire state is given by (entry point, register state); with that amount of state we have all the information needed to *either* extract the syscall arguments *or* the register contents. Without those, we can only represent one of the two possible metalevels (right now we represent the higher-level metalevel, the argument vector), but we need both for different usages. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.