Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp5271510imd; Tue, 30 Oct 2018 14:52:17 -0700 (PDT) X-Google-Smtp-Source: AJdET5cBBbV1VZYHRBsrF81Dni1jrlqXOfqtU4RXifHOh4+oWX3o1c9rFqOk9cz3Yd9m9p4kzZOs X-Received: by 2002:a65:580d:: with SMTP id g13-v6mr413162pgr.370.1540936336945; Tue, 30 Oct 2018 14:52:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540936336; cv=none; d=google.com; s=arc-20160816; b=APEGm36Sf0Ie8zjTMSF3sThgbbQUEZmFmzjIzyGkX95WIDTFtCm0+MTH12D4Muoh9R qSOc82Vi7++eXOplXsRv/mY8evkipn6ze+6DFGCtpfcxvwCb2fJk/4JLihG4HeDDdX49 N9VjYYqFGKcVjEX0VHva2PTOvpwYOmTgCmHIxdnjtABc0QoSu7EvH5Dzt88E1Gz6O3vl bJZ2BL8fRNX3HfBdb+GFOlLy94wIyKALntSb0moklsgiA/bXj73nk18iqmcDN4T1VVRn El6t9WAFua5K6SSJROVX4vzg0m5NKrqg7rhMX4lh04fVRh4xOZVAUuYTvYtdiTVtPgm6 zHIg== 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 :references:in-reply-to:mime-version:dkim-signature; bh=ga2nEOPvIwUYywBDkqbUH6ZXONUHVEyuPRXON1dMRhU=; b=tp4dbWqvhW0W2i5uEUZHkVsv9RjoLVV53mPOT4PCTa8p2IVXOZydokYB4Qaoon6i3p 8HmO2hHGGEiX4YQ191b5oiI5cXwU+GKGu6ygFmZpI28v3hiyiFomPnMXpbQrwkZOqaNM OBotccBXnYXfLcLnT5zII+r/PIRHx6MjkVZ2n9KDc6aphyY6ad9F5it47PZZSOxE7H9S 1pGxZ6Yte/oeUikyODZPu8iaH5dFIR71AEtDAsCP5mVX2VTW9sjjqbxZsb6zudRXMCun VnVvAIPonIjKCI9Knta9WX2bMdr8FgbRv/mPqy9IcW/nblOT2D9dqrrWMzQQXS87GZ0P 57LA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="di/cwHL9"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q10-v6si24750604pgk.392.2018.10.30.14.52.01; Tue, 30 Oct 2018 14:52:16 -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=@chromium.org header.s=google header.b="di/cwHL9"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728080AbeJaGog (ORCPT + 99 others); Wed, 31 Oct 2018 02:44:36 -0400 Received: from mail-yw1-f67.google.com ([209.85.161.67]:44306 "EHLO mail-yw1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728011AbeJaGof (ORCPT ); Wed, 31 Oct 2018 02:44:35 -0400 Received: by mail-yw1-f67.google.com with SMTP id k6-v6so1218791ywa.11 for ; Tue, 30 Oct 2018 14:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ga2nEOPvIwUYywBDkqbUH6ZXONUHVEyuPRXON1dMRhU=; b=di/cwHL9pCYacoB//i7xbNdx+pPYbkO6HDvO8JJumzfLpm6b8X0NvfVZKx+S7bE3r4 sFaDN2YmX1tPmyk8jsnoOtBK6N2X+wYLqWUaW0xhkyB8WCk/o5HcGAKxFMWeMbt3RVEx TtsxuMtcFc1K15sKIFLoLpQulN5NOpoGRkv8k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ga2nEOPvIwUYywBDkqbUH6ZXONUHVEyuPRXON1dMRhU=; b=MR4almEP8PYTeSYLentbgrArWdCimC+7sb9BCdGkf+NmE3hxh4E+OShnNMOEPYvWPr QtS3EIA1U3lW+Uk9d8V1VUZvU7nIkBFY/xj9xpDQYmF+JM5o2WSprzvh3bPB8fReMo6p mricZ6eDs4Co/U7ciFv7XpFTd8JQttiTTyihIlvrbg/Aiwcj4wLSv+Y86JXNyegrGvDz 7gcj2LVctpqBUJx/QmQX0foyXfPxS1rncekfzNjfjLASCPnLGaZXidXzrBretIQiyPFV HurGuKjKiBVRuHV7FZPnIB2K32hpY2sec+qo5L4VHAwWIW6xHaxvHfyLJQI9O3/1zjQt COvQ== X-Gm-Message-State: AGRZ1gJTkTPpif5CcZDJapy04E7dnZ51+bsJfcf23slTfk9Hg3qFR3+T SUJwOHIJ8fTBnBQ+EuQ4LNj+wd91s8I= X-Received: by 2002:a81:ae42:: with SMTP id g2-v6mr494763ywk.151.1540936164085; Tue, 30 Oct 2018 14:49:24 -0700 (PDT) Received: from mail-yw1-f41.google.com (mail-yw1-f41.google.com. [209.85.161.41]) by smtp.gmail.com with ESMTPSA id q2-v6sm6386353ywa.24.2018.10.30.14.49.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Oct 2018 14:49:22 -0700 (PDT) Received: by mail-yw1-f41.google.com with SMTP id z72-v6so1329136ywa.0 for ; Tue, 30 Oct 2018 14:49:22 -0700 (PDT) X-Received: by 2002:a81:813:: with SMTP id 19-v6mr555686ywi.168.1540936162187; Tue, 30 Oct 2018 14:49:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:3990:0:0:0:0:0 with HTTP; Tue, 30 Oct 2018 14:49:21 -0700 (PDT) In-Reply-To: <20181029224031.29809-2-tycho@tycho.ws> References: <20181029224031.29809-1-tycho@tycho.ws> <20181029224031.29809-2-tycho@tycho.ws> From: Kees Cook Date: Tue, 30 Oct 2018 14:49:21 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v8 1/2] seccomp: add a return code to trap to userspace To: Tycho Andersen Cc: Andy Lutomirski , Oleg Nesterov , "Eric W . Biederman" , "Serge E . Hallyn" , Christian Brauner , Tyler Hicks , Akihiro Suda , Aleksa Sarai , LKML , Linux Containers , Linux API 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 Mon, Oct 29, 2018 at 3:40 PM, Tycho Andersen wrote: > * switch to a flags based future-proofing mechanism for struct > seccomp_notif and seccomp_notif_resp, thus avoiding version issues > with structure length (Kees) [...] > > +struct seccomp_notif { > + __u64 id; > + __u32 pid; > + __u32 flags; > + struct seccomp_data data; > +}; > + > +struct seccomp_notif_resp { > + __u64 id; > + __s64 val; > + __s32 error; > + __u32 flags; > +}; Hrm, so, what's the plan for when struct seccomp_data changes size? I'm realizing that it might be "too late" for userspace to discover it's running on a newer kernel. i.e. it gets a user notification, and discovers flags it doesn't know how to handle. Do we actually need both flags AND a length? Designing UAPI is frustrating! :) Do we need another ioctl to discover the seccomp_data size maybe? -- Kees Cook