Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1085485imm; Thu, 6 Sep 2018 15:17:01 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZAv/iJSdH+KrUdLKjc/GNG+WPM8gxnFAEBUpKq8nsHXpPCTWtCEs9save9dEQkrtto1JSe X-Received: by 2002:a63:1b4e:: with SMTP id b14-v6mr5034595pgm.303.1536272221516; Thu, 06 Sep 2018 15:17:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536272221; cv=none; d=google.com; s=arc-20160816; b=DJ8YVyCdP7oE8Hfsx9hE8eq1PZjHK6B5WoMUtqmgHirFENuKMW6fNfDmpjSbswUaIL prY/sr0X71Ko3U0CCGz7eac9o+dzVlZYBa8T4sfkKc2fd4XLxU2euFLs7DoxVNeeHOYa uaNra3oE8ISXM7TcFMi8m3BkhBCzzJ0sV+w88ue6Xs5/mhR2n3VHCoXNqnrRdBivazk0 tqNIb6EAS+maPhFJoQW9mzRMU7tNl7r3cTUSTmCel+B60u95AHEVRuxpvbRGWbeGRgUp E38wxl63DKnMH85jwZgiiE2+SDj55sgUJLTecgr1ito6fe75y1h5xet++gGBj7sGNfyQ v10Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=VgAEINDHJWOqEu7ZL77Hcum8imLIYrZX0+D80Qh/F2k=; b=EUcy1DEFcZOjulwK4wB5vfQFkk30AJpc0vIdIgJm2SmfEg+1OpF1VbdSDotTOWvOit Ak+wSVsgXE4AXKdcMfDEFSulITfGrLwh48GCSaDNR5EqkP0nOBmi9PNkSKclYF9dskW1 Gxm4U5aGapHPA7WGo57rilxT2087H2b+GHCdCKJ/G21U6w17b81K3IKEaNW+sLlnT89S coiWSi3V7F/D9I2EEU2fsuOG0vf7DEUF8dEW/c8vBR0bhX3GKVUK8iKx/75j3TdX6HLh S1vIAkG7TUhc4oESJRbmw8TkWOYiO24OTdL18pDDtX4q0fiJqaxvdvhWt6YBtm/u/GkE ZAzA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@tycho-ws.20150623.gappssmtp.com header.s=20150623 header.b=g0LXsEq2; 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 m63-v6si6171916pld.62.2018.09.06.15.16.46; Thu, 06 Sep 2018 15:17:01 -0700 (PDT) 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; dkim=pass header.i=@tycho-ws.20150623.gappssmtp.com header.s=20150623 header.b=g0LXsEq2; 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 S1730429AbeIFXHG (ORCPT + 99 others); Thu, 6 Sep 2018 19:07:06 -0400 Received: from mail-qk1-f194.google.com ([209.85.222.194]:43152 "EHLO mail-qk1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728599AbeIFXHG (ORCPT ); Thu, 6 Sep 2018 19:07:06 -0400 Received: by mail-qk1-f194.google.com with SMTP id 130-v6so8010784qkd.10 for ; Thu, 06 Sep 2018 11:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tycho-ws.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=VgAEINDHJWOqEu7ZL77Hcum8imLIYrZX0+D80Qh/F2k=; b=g0LXsEq2Qx3uOUpC2qSWnoUDeauaNIWJar8iLJhVr/HIMe9CE+RKRv/lD6NU0ebbWf UqfWg7i0g7qH6RTlAPa44pyHz0ktbbasZ/GSFS3KYI1p/K7arpxYXh1TcP1rn6v/LUu7 CJfNWRTGgBKLJsCCVAYLA+qgeTPn9dzxb2QXV6njmC85GN8BO6GxzqUrn+PxD4SKJXMM HPPIFX+ehbwlx6XRZPNZigHfsNGzOe6oSg3uC035pWw3Lj7PHFkDnrufp0lXrDY9lff8 yYpcYmeNNWkDDWhWGI53bi4q2SozPBHTtiNausNcjs1pjYANSVrjqkHe+4oZN6HjleDT Wejg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=VgAEINDHJWOqEu7ZL77Hcum8imLIYrZX0+D80Qh/F2k=; b=iQOTU75gZvi1CDZtZZbMK/OibdXRwaszBRQ3SRz7gOoQ31r9CZaYS9jnmsZuC3Mcoa IiF1L6gMyyweQjgD4vF9Q/538WolgBouJM7a8EcvAd/pXi0I2PmkTURpC9/ozzcnSIZR OyhgCl9Ijbo1K9ucA8eKBpfGyEhfY2QOyHmwOn/jhFntdmc/1NS3gM30Bme30zlL9+pP MR1w1fM/J7unoCtFH5Bm4GE/TsDaocdjqfZ2AXHYRGDkQQHbes4WbLVyD3ztaaU4dKLU MPDqGKa/M4zj/SKUSSj72k4NC4f21Y1nyF5fKd5qyFsy7XpUvwr5o9etMupWDZabAyho E9Gg== X-Gm-Message-State: APzg51ATkcKNEgQRkaZ4j8JtgzkR58VJIBvzL1xM05QWYq5pJlyaCvLa nlqAOvgSgGldxbcLfySNery9Vw== X-Received: by 2002:a37:c0d3:: with SMTP id v80-v6mr3202703qkv.256.1536258622742; Thu, 06 Sep 2018 11:30:22 -0700 (PDT) Received: from cisco.cisco.com ([173.38.117.76]) by smtp.gmail.com with ESMTPSA id i85-v6sm4242726qkh.3.2018.09.06.11.30.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 06 Sep 2018 11:30:21 -0700 (PDT) Date: Thu, 6 Sep 2018 12:30:18 -0600 From: Tycho Andersen To: Jann Horn Cc: Kees Cook , kernel list , containers@lists.linux-foundation.org, Linux API , Andy Lutomirski , Oleg Nesterov , "Eric W. Biederman" , "Serge E. Hallyn" , Christian Brauner , Tyler Hicks , suda.akihiro@lab.ntt.co.jp Subject: Re: [PATCH v6 4/5] seccomp: add support for passing fds via USER_NOTIF Message-ID: <20180906183018.GC3326@cisco.cisco.com> References: <20180906152859.7810-1-tycho@tycho.ws> <20180906152859.7810-5-tycho@tycho.ws> <20180906162246.GB3326@cisco.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180906162246.GB3326@cisco.cisco.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 06, 2018 at 10:22:46AM -0600, Tycho Andersen wrote: > On Thu, Sep 06, 2018 at 06:15:18PM +0200, Jann Horn wrote: > > On Thu, Sep 6, 2018 at 5:29 PM Tycho Andersen wrote: > > > The idea here is that the userspace handler should be able to pass an fd > > > back to the trapped task, for example so it can be returned from socket(). > > [...] > > > diff --git a/Documentation/userspace-api/seccomp_filter.rst b/Documentation/userspace-api/seccomp_filter.rst > > > index d1498885c1c7..1c0aab306426 100644 > > > --- a/Documentation/userspace-api/seccomp_filter.rst > > > +++ b/Documentation/userspace-api/seccomp_filter.rst > > > @@ -235,6 +235,9 @@ The interface for a seccomp notification fd consists of two structures: > > > __u64 id; > > > __s32 error; > > > __s64 val; > > > + __u8 return_fd; > > > + __u32 fd; > > > + __u32 fd_flags; > > > > Normally, syscalls that take an optional file descriptor accept a > > signed 32-bit number, with -1 standing for "no file descriptor". Is > > there a reason why this uses a separate variable to signal whether an > > fd was provided? > > No real reason other than I looked at the bpf code and they were using > __u32 for bpf (but I think in their case the fd args are not > optional). I'll switch it to __s32/-1 for the next version. Oh, I think there is a reason actually: since this is an API addition, the "0" value needs to be the previously default behavior if userspace doesn't specify it. Since the previously default behavior was not to return an fd, and we want to allow fd == 0, we need the extra flag to make this work. This is really only a problem because we're introducing this stuff in a second patch (mostly to illustrate how extending the response structure would work). I could fold this into the first patch if we want, or we could keep the return_fd bits if the illustration is useful. Tycho