Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4697179imu; Sat, 1 Dec 2018 00:52:29 -0800 (PST) X-Google-Smtp-Source: AFSGD/XT7wNx9Y1tMI3eaSi2H3sXJbLXspW0IoKYx9jJFKdp28MJTKhAxJv6s70av4njHYNxj/uA X-Received: by 2002:a62:7f94:: with SMTP id a142mr8705469pfd.96.1543654349412; Sat, 01 Dec 2018 00:52:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543654349; cv=none; d=google.com; s=arc-20160816; b=GwyU07gcWJeSMcgyfH+C5xfKrzVq/LGJAyScn43OglGPxWVJqiZ4AXW3LugghvT5hy NqKxpOnQnHZHh2M/hijBENrg+UAYEy0LwT1QOcIHP3GqB6VY4aUrx102jzm1zXNmfSWu ODpFPAIfB1rCLOkkAgrnGqgGzQeSs9hm4vZWn+XbPq24YuD/1Mp5pIsip/Q43edbNHAE /jlCk0lmSMjLHz1ZCDuTpco44tTlrtIjIXiQpLB+ZSDUKWHCxYpHtykJTXMw79G8kENa VTS4V3jE4wW1v1RGqueqIKBEjJDsOiQUCDbFdDHdi8ca+BjzBW6rAf1p+yDVW1OBZZ+v fz+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=XlMvT1nlDvqDeuuFKDUcE7NepCTv6cI0dlPTopFOVyM=; b=BytHiQYxz0YGpD9lrCfIflSmUB2Q3DV1uZGHdfEawhAmK6sJP3arfWCai9D+1dnzpq BQjVH8zU8TF+/4483+R4ZTL3frNq/9Z+cjTrgZb1Ru8Zy5K4bJ3+MdC6H9HKRlvpLky+ F+KiOJEeqqBoIphYoS8euNk7b2WHw7L+tWsFdA62pGzYaH7vDUk+2vT/jZNrwdsDRIHQ 2pShx9+6Btj65hPWP0PnWb3grbG2+5pzrEdmfswy6r9KGuTuB977h0nBT9/4CZ94ZWcd nPv0mn/HmzQXoua55Gw83rKuVOKN22xm8dLG+d2nA2Z25xKWgujLLWlEQjp6Ka5vTPjU WrlA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t2si7381688plz.344.2018.12.01.00.52.14; Sat, 01 Dec 2018 00:52:29 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726570AbeLAUDi (ORCPT + 99 others); Sat, 1 Dec 2018 15:03:38 -0500 Received: from mail-qt1-f194.google.com ([209.85.160.194]:34250 "EHLO mail-qt1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726182AbeLAUDi (ORCPT ); Sat, 1 Dec 2018 15:03:38 -0500 Received: by mail-qt1-f194.google.com with SMTP id r14so8670016qtp.1; Sat, 01 Dec 2018 00:51:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XlMvT1nlDvqDeuuFKDUcE7NepCTv6cI0dlPTopFOVyM=; b=hNqdBkl1NjqojZzbc+spVqsRN8FxspPFhnUdy6ABP016vQSK48GcuRNEREq87JHk/s vUUWlhSamBhSKmnxUhzAy2Qv97SJ7fgauLKEuprOB83NOZBxUrfaZA+h4ORZ/r8T7tZg X+rzFd/TtRDBpyzO14KU8gAZeusiq1Z3AM4PP2jLLzn4d9kQXfKwUQPHjQxrMhwmdF5p rcpdNNn3MFKgGaX/7Ih/cT+fLVRYx/mkbMLOJ3A7EPPkDBdleIm4U538ozgVSzUPsbju rFFp2ikCCKU/phyXoQ20XxBqIlzNhjw/b2u3sCNMAEF6FZzQUmNUNfDmzs97C/Sgsq2O W93Q== X-Gm-Message-State: AA+aEWYfj994JhZxDQAdVfk7CzDrEPDE7GK1jkTha9+0I7xyv+YG8G4F 7tCMQlD5WhyhNrMEre/9vecN+Na+qv/BNpfkOZY= X-Received: by 2002:a0c:f50c:: with SMTP id j12mr8465383qvm.149.1543654296412; Sat, 01 Dec 2018 00:51:36 -0800 (PST) MIME-Version: 1.0 References: <20181120105124.14733-1-christian@brauner.io> <87in0g5aqo.fsf@oldenburg.str.redhat.com> <36323361-90BD-41AF-AB5B-EE0D7BA02C21@amacapital.net> <993B98AC-51DF-4131-AF7F-7DA2A7F485F1@brauner.io> <20181129195551.woe2bl3z3yaysqb6@brauner.io> <6E21165F-2C76-4877-ABD9-0C86D55FD6AA@amacapital.net> <87y39b2lm2.fsf@xmission.com> <20181130065606.kmilbbq46oeycjp5@brauner.io> In-Reply-To: From: Arnd Bergmann Date: Sat, 1 Dec 2018 09:51:18 +0100 Message-ID: Subject: Re: [PATCH v2] signal: add procfd_signal() syscall To: Andy Lutomirski Cc: christian@brauner.io, "Eric W . Biederman" , Florian Weimer , Linux Kernel Mailing List , "Serge E. Hallyn" , Jann Horn , Andrew Morton , Oleg Nesterov , cyphar@cyphar.com, Al Viro , Linux FS-devel Mailing List , Linux API , Daniel Colascione , Tim Murray , linux-man@vger.kernel.org, Kees Cook Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Dec 1, 2018 at 12:54 AM Andy Lutomirski wrote: > On Fri, Nov 30, 2018 at 2:10 PM Arnd Bergmann wrote: > > On Fri, Nov 30, 2018 at 5:36 PM Andy Lutomirski wrote: > > > On Fri, Nov 30, 2018 at 3:41 AM Arnd Bergmann wrote: > > > > siginfo_t as it is now still has a number of other downsides, and Andy in > > > > particular didn't like the idea of having three new variants on x86 > > > > (depending on how you count). His alternative suggestion of having > > > > a single syscall entry point that takes a 'signfo_t __user *' but interprets > > > > it as compat_siginfo depending on in_compat_syscall()/in_x32_syscall() > > > > should work correctly, but feels wrong to me, or at least inconsistent > > > > with how we do this elsewhere. > > The '548 | 0x40000000' part seems to be the only sensible > > way to handle x32 here. What exactly would you propose to > > avoid defining the other entry points? > > I would propose that it should be 335 | 0x40000000. I can't see any > reasonable way to teach the kernel to reject 335 | 0x40000000 that > wouldn't work just as well to accept it and make it do the right > thing. Currently we accept it and do the *wrong* thing, which is no > good. > > > and we have to > > add more complexity to the copy_siginfo_from_user() > > implementation to duplicate the hack that exists in > > copy_siginfo_from_user32(). > > What hack are you referring to here? I mean this part: #ifdef CONFIG_COMPAT int copy_siginfo_to_user32(struct compat_siginfo __user *to, const struct kernel_siginfo *from) #if defined(CONFIG_X86_X32_ABI) || defined(CONFIG_IA32_EMULATION) { return __copy_siginfo_to_user32(to, from, in_x32_syscall()); } int __copy_siginfo_to_user32(struct compat_siginfo __user *to, const struct kernel_siginfo *from, bool x32_ABI) #endif { ... case SIL_CHLD: new.si_pid = from->si_pid; new.si_uid = from->si_uid; new.si_status = from->si_status; #ifdef CONFIG_X86_X32_ABI if (x32_ABI) { new._sifields._sigchld_x32._utime = from->si_utime; new._sifields._sigchld_x32._stime = from->si_stime; } else #endif { new.si_utime = from->si_utime; new.si_stime = from->si_stime; } break; ... } #endif If we have a '548 | 0x40000000' entry pointing to __x32_compat_sys_procfd_kill, then that will do the right thing. If you instead try to have x32 call into the native sys_procfd_kill, then copy_siginfo_to_user() will also have to know about x32, effectively duplicating that mess above, unless you want to also change all users of copy_siginfo_to_user32() to use copy_siginfo_to_user() and handle all cases in one function. Arnd