Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934275AbdC3RqX (ORCPT ); Thu, 30 Mar 2017 13:46:23 -0400 Received: from mail-io0-f171.google.com ([209.85.223.171]:34543 "EHLO mail-io0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933806AbdC3RqV (ORCPT ); Thu, 30 Mar 2017 13:46:21 -0400 MIME-Version: 1.0 In-Reply-To: <20170330154902.GA27416@redhat.com> References: <20170328145413.GA3164@redhat.com> <20170329163335.GA23977@redhat.com> <20170329165554.GA24250@redhat.com> <20170329170442.GA24342@redhat.com> <20170329185041.GA24806@redhat.com> <20170330135100.GA25882@redhat.com> <20170330154902.GA27416@redhat.com> From: Linus Torvalds Date: Thu, 30 Mar 2017 10:46:19 -0700 X-Google-Sender-Auth: iZ0G--dJ5Byue1ps4OnhUDH8btk Message-ID: Subject: Re: syscall_get_error() && TS_ checks To: Oleg Nesterov Cc: Andrew Morton , Andy Lutomirski , Denys Vlasenko , "H. Peter Anvin" , Ingo Molnar , Jan Kratochvil , Pedro Alves , Thomas Gleixner , "the arch/x86 maintainers" , Linux Kernel Mailing List 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: 2135 Lines: 48 On Thu, Mar 30, 2017 at 8:49 AM, Oleg Nesterov wrote: >> >> case offsetof(struct user32, regs.orig_eax): > ^^^^^^^^^^^^^^ > damn, just in case, of course this is typo, should be > > case offsetof(struct user32, regs.eax); So honestly, the first version of your patch I went "Ok, that looks perfectly reasonable", because orig_eax is special, and always sign-extending it sounds fine. The *fixed* version of your patch I go "no, that's obviously complete garbage, that's completely bogus". Because the regular eax register is *not* special, and sign-extending it sounds very dangerous indeed. The user will actually *use* that register as a register, unlike orig_eax. And eax is no different from all the other random registers. Yes, it happens to be the return value for system calls, but this codepath is not at all limited to system calls, it's absolutely *any* context when you use gdb on a 32-bit binary. Now, you may well say that "the upper bits aren't well-defined in that case anyway". And you'd be mostly right. Except the semantics of x86-64 is that 32-bit operations zero-extend the upper bits, so zero-extension really *is* the right thing to do. For example, let's assume that %eax contains a 32-bit pointer with the high bit set, and we're using a 32-bit debugger on a 32-bit program (ie you're just running a 32-bit distro on a 64-bit kernel, which people have definitely done). We *really* shouldn't sign-extend that value if the debugger ends up updating the pointer (or maybe the debugger just reloads previous values, not really "updating" anything - I think that's what gdb does when you do a call within the context of the debugged program from within gdb, for example) So I really *really* don't think you can just sign-extend %eax. Which is exactly why we have that nasty odd sign-extension in the signal path instead, but then have to make it conditional on running a 32-bit program. But maybe there is still something I'm not understanding in your argument. This thread has been a series of mis-understandings. Linus