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=-15.1 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL 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 E20C1C4363D for ; Wed, 30 Sep 2020 23:09:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9C74C2075F for ; Wed, 30 Sep 2020 23:09:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="HIKXee3A" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732066AbgI3XId (ORCPT ); Wed, 30 Sep 2020 19:08:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57100 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732012AbgI3XId (ORCPT ); Wed, 30 Sep 2020 19:08:33 -0400 Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [IPv6:2a00:1450:4864:20::642]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E2A58C061755 for ; Wed, 30 Sep 2020 16:08:31 -0700 (PDT) Received: by mail-ej1-x642.google.com with SMTP id z23so5201495ejr.13 for ; Wed, 30 Sep 2020 16:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oSjyCndmSDw71eE/BIT10kmAi2CWzQm4Fdkl0rDwsVs=; b=HIKXee3AjLR1yKNiCxpi/lY3cYYCKNhBnzExJFzXfKnsypgwzwfgjzM0tb17O4Vgyp lhgXkKM9j2PeIgZpOnVu++oMi7gJvxIjizwMo703OTz8iXPRoqS8aax65sRSbVXVQhaN tvjeuhg5mYZ8mUI0vBLvW61A38C6uccE8YKBXI8V0m4NvbBCXtfIlsDBT4jZHcnedOEg PO51mrwjnCCJ8TSH0ZBojL0RZxbyHtHcw2Xb7KRra7wZgBheblTerBSatg5051UvvYcT ITGkQ01vRidlmaOwJA9wdrUJhVLTQwm8L4zEsmgVhT/kFZfXhq9Mntu4wkm3OmlCTSg/ IPLQ== 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=oSjyCndmSDw71eE/BIT10kmAi2CWzQm4Fdkl0rDwsVs=; b=bseGmL09bfYvfzV1MAh+WRXvsGz1vt5EKDDMXdwTXSj3kWVpWthUX7QAnNUEmom+rK eaUQe/izC+ODKEkOt6WZKLXvhv0mQXXZ3ojmDLXuiL4YoWUN8mjcYc10hJ0gZN7VhACP 0dvPgILFTNMd3ALydVBFnBBzlaJbzOMi9MWITpBucyPJ2V7Ces64a2T664ynYNXIZDci dGI6Cem38V9a4F59VsKHf+MYBq4WHt8JFv7pEW693/NZo+cZpfskpZ/YhvhbinGI1/Fr J/PjF9QESjjCbHDzY+t0DiN3M7+7dMQPbqcBdU56j70/WHjcDtsSqpdWSwT2XwY57IOP pJjw== X-Gm-Message-State: AOAM530KDP0I2NaDzvw27LrubCx0TvasDd+CLy8Bxr+c14u3IQ3bNl+o BRRVuh4HQUT1+VJxfFiX2b1T6Hd4+q/H8rYeCF7XuQ== X-Google-Smtp-Source: ABdhPJyC+4DouNB+AJFTmGjbAtJDvRkfFxZToj/svy2V/efpofZpBJvCX/A3ee/XkublfA579qMlv91dBfLYJ/TEfyE= X-Received: by 2002:a17:906:33c8:: with SMTP id w8mr574212eja.233.1601507310348; Wed, 30 Sep 2020 16:08:30 -0700 (PDT) MIME-Version: 1.0 References: <202009301554.590642EBE@keescook> In-Reply-To: <202009301554.590642EBE@keescook> From: Jann Horn Date: Thu, 1 Oct 2020 01:08:04 +0200 Message-ID: Subject: Re: [PATCH v3 seccomp 5/5] seccomp/cache: Report cache data through /proc/pid/seccomp_cache To: Kees Cook Cc: YiFei Zhu , Linux Containers , YiFei Zhu , bpf , kernel list , Aleksa Sarai , Andrea Arcangeli , Andy Lutomirski , David Laight , Dimitrios Skarlatos , Giuseppe Scrivano , Hubertus Franke , Jack Chen , Josep Torrellas , Tianyin Xu , Tobin Feldman-Fitzthum , Tycho Andersen , Valentin Rothberg , Will Drewry , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "the arch/x86 maintainers" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [adding x86 folks to enhance bikeshedding] On Thu, Oct 1, 2020 at 12:59 AM Kees Cook wrote: > On Wed, Sep 30, 2020 at 10:19:16AM -0500, YiFei Zhu wrote: > > From: YiFei Zhu > > > > Currently the kernel does not provide an infrastructure to translate > > architecture numbers to a human-readable name. Translating syscall > > numbers to syscall names is possible through FTRACE_SYSCALL > > infrastructure but it does not provide support for compat syscalls. > > > > This will create a file for each PID as /proc/pid/seccomp_cache. > > The file will be empty when no seccomp filters are loaded, or be > > in the format of: > > > > where ALLOW means the cache is guaranteed to allow the syscall, > > and filter means the cache will pass the syscall to the BPF filter. > > > > For the docker default profile on x86_64 it looks like: > > x86_64 0 ALLOW > > x86_64 1 ALLOW > > x86_64 2 ALLOW > > x86_64 3 ALLOW > > [...] > > x86_64 132 ALLOW > > x86_64 133 ALLOW > > x86_64 134 FILTER > > x86_64 135 FILTER > > x86_64 136 FILTER > > x86_64 137 ALLOW > > x86_64 138 ALLOW > > x86_64 139 FILTER > > x86_64 140 ALLOW > > x86_64 141 ALLOW [...] > > diff --git a/arch/x86/include/asm/seccomp.h b/arch/x86/include/asm/seccomp.h > > index 7b3a58271656..33ccc074be7a 100644 > > --- a/arch/x86/include/asm/seccomp.h > > +++ b/arch/x86/include/asm/seccomp.h > > @@ -19,13 +19,16 @@ > > #ifdef CONFIG_X86_64 > > # define SECCOMP_ARCH_DEFAULT AUDIT_ARCH_X86_64 > > # define SECCOMP_ARCH_DEFAULT_NR NR_syscalls > > +# define SECCOMP_ARCH_DEFAULT_NAME "x86_64" > > # ifdef CONFIG_COMPAT > > # define SECCOMP_ARCH_COMPAT AUDIT_ARCH_I386 > > # define SECCOMP_ARCH_COMPAT_NR IA32_NR_syscalls > > +# define SECCOMP_ARCH_COMPAT_NAME "x86_32" > > I think this should be "ia32"? Is there a good definitive guide on this > naming convention? "man 2 syscall" calls them "x86-64" and "i386". The syscall table files use ABI names "i386" and "64". The syscall stub prefixes use "x64" and "ia32". I don't think we have a good consistent naming strategy here. :P