From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2F194C388F7 for ; Thu, 22 Oct 2020 20:54:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C5EF62080C for ; Thu, 22 Oct 2020 20:54:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="d6+CBZng" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S371993AbgJVUwf (ORCPT ); Thu, 22 Oct 2020 16:52:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36354 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S371979AbgJVUwe (ORCPT ); Thu, 22 Oct 2020 16:52:34 -0400 Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E49CC0613CE; Thu, 22 Oct 2020 13:52:34 -0700 (PDT) Received: by mail-pg1-x544.google.com with SMTP id n16so1711798pgv.13; Thu, 22 Oct 2020 13:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ag5R8ANFXiIKHrZi3CpUKkJaLv+KTVPp7lGufqkGA/Q=; b=d6+CBZngB4ab2gx0rcr80/mUgsqGHrDfBj1/ysacUwotFwRiXDdiFVeXasFIZHuxHV 1x42nCvwwG6yQagKIIf1tCqN7+6tPyMBG1vriokW70nyWmsc8sMnME4tilAanNACPt9O UzNtsCl8lGUuz9Im9a2MYKC37+MOa7tXY3edPXllbkN0hCEGFSQJnOVjVtVIAq/+HJLn puZeL7mEq755h14QQNrKiJO3EdeJ0uF64975sPV2JD6dBoaXPh5ct0LHO4hygeT08KGT jSXmP5u+fSJpVAIRfAuEVSd0XPlAxR+NDLBHr9Bh1K2r/SHLCD+LPnn7xcu4RCGkQK5K 2CnQ== 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=Ag5R8ANFXiIKHrZi3CpUKkJaLv+KTVPp7lGufqkGA/Q=; b=O7JKExU18i8h5t8FeQ8pekLfr5vW2QMhyLht6agAp/FCfedQiX1tERjHcDGH5Vl1ms /iDDBfd3SqQblaN2Me8KYjcPG3XgwZmnGrAY/la8HnDP9kFFa+Z1dIs8kMtajVgqIZgs ElPdcFs0WEME/jCuw8+lnIXiSnragfrTIAK0zjPBdewhsCMA2KA5csWfSgCfy+ZDZeKQ LpWqMFIGS2pTEKqZ8cNCKciTgjGfwDFJnLxiZrkmRghycAhexEvTMnf1N9bZifJFUNeu Wn0OYyz7gsfzhs3ZAQkqmwzVtp+jMdPYwQRKihIeJNNurB7kKUg03SxWx0oMnElk9Vjp GGHA== X-Gm-Message-State: AOAM530BAvB8+L1wcG2mL/k74EuzqT7M8tz1WYF57kwpaMaK7bW/YGnL iVCOHIX5+ZW5q2+oLYt/iDvvBX2Pi1z4WfvaMzc= X-Google-Smtp-Source: ABdhPJx+dBEdcJ+BztG+kLdnt+vX7FpE4LlJQH01ipc7IDV0pS9xsoGFMHkw/BUBCjO1GOwzT0IU3w3pZk202vhKcQg= X-Received: by 2002:a17:90a:f184:: with SMTP id bv4mr3823913pjb.1.1603399952372; Thu, 22 Oct 2020 13:52:32 -0700 (PDT) MIME-Version: 1.0 References: <202010091613.B671C86@keescook> <202010121556.1110776B83@keescook> In-Reply-To: From: YiFei Zhu Date: Thu, 22 Oct 2020 15:52:20 -0500 Message-ID: Subject: Re: [PATCH v4 seccomp 5/5] seccomp/cache: Report cache data through /proc/pid/seccomp_cache To: Kees Cook Cc: Linux Containers , YiFei Zhu , bpf , kernel list , Aleksa Sarai , Andrea Arcangeli , Andy Lutomirski , David Laight , Dimitrios Skarlatos , Giuseppe Scrivano , Hubertus Franke , Jack Chen , Jann Horn , Josep Torrellas , Tianyin Xu , Tobin Feldman-Fitzthum , Tycho Andersen , Valentin Rothberg , Will Drewry Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 12, 2020 at 7:31 PM YiFei Zhu wrote: > > On Mon, Oct 12, 2020 at 5:57 PM Kees Cook wrote: > > I think it's fine to just have this "dangle" with a help text update of > > "if seccomp action caching is supported by the architecture, provide the > > /proc/$pid ..." > > I think it would be weird if someone sees this help text and wonder... > "hmm does my architecture support seccomp action caching" and without > a clear pointer to how seccomp action cache works, goes and compiles > the kernel with this config option on for the purpose of knowing if > their arch supports it... Or, is it a common practice in the kernel to > leave dangling configs? Bump, in case this question was missed. I don't really want to miss the 5.10 merge window... YiFei Zhu