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=-13.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 3838FC4361B for ; Thu, 17 Dec 2020 12:15:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D8BB4238E8 for ; Thu, 17 Dec 2020 12:15:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726160AbgLQMPB convert rfc822-to-8bit (ORCPT ); Thu, 17 Dec 2020 07:15:01 -0500 Received: from mail-ot1-f44.google.com ([209.85.210.44]:39774 "EHLO mail-ot1-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726155AbgLQMPA (ORCPT ); Thu, 17 Dec 2020 07:15:00 -0500 Received: by mail-ot1-f44.google.com with SMTP id d8so27023166otq.6; Thu, 17 Dec 2020 04:14:44 -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:content-transfer-encoding; bh=g+ZQ9Hep/ihbUcAAKgQBrtb6DKWZjd1MMpk6GQGQBFo=; b=TwUE/sAaDxSik4eC4+AwHfhs259wcfDFaqZ9iAEraBl2QkccsjfTrFTz3utu1eAtxe Z0QtTCQVWqfSQV4KSrzJPi3sYXIZQ9iOrgZKZ+4n3He0ShWxke3P6LN05fBagccHvcBQ r2OUQ1tdC6f7OivbGm+kTXTRufY4ouXz4j/wneC71NeHmY2l4RXdmwhBLZjDHYSyYSIJ KcssnimozOGMCMvU7FRpDf4gYdPodv3BTeIBgKghLNwiDoYMCBCOnsYrG1JwmlqtcgVa YAk3Kar9SihjT7kmv3ntqhFSkAFfWk7FHKnANOJksbpUek993z5QavpMwDRPwQRTZOGc u+HQ== X-Gm-Message-State: AOAM532KaE/4c9ToIExUavd/+ExtHVxSGbk8aB2uXujvKXjrpdm1hZBy sBBSuvmzsVjHsIp7TS5jL27+xagesoMkuAJFzJzSSEJ3c/A= X-Google-Smtp-Source: ABdhPJz59bsLl40yU/AMrbYd1pTjEH6DKHmAPNcgiQuY6xiSJuPFg3psehvXyIwiQfTmcEKRkCfg14X04prnuLoQcg4= X-Received: by 2002:a05:6830:210a:: with SMTP id i10mr29145891otc.145.1608207259025; Thu, 17 Dec 2020 04:14:19 -0800 (PST) MIME-Version: 1.0 References: <4706b0ff81f28b498c9012fd3517fe88319e7c42.1602431034.git.yifeifz2@illinois.edu> In-Reply-To: <4706b0ff81f28b498c9012fd3517fe88319e7c42.1602431034.git.yifeifz2@illinois.edu> From: Geert Uytterhoeven Date: Thu, 17 Dec 2020 13:14:07 +0100 Message-ID: Subject: Re: [PATCH v5 seccomp 5/5] seccomp/cache: Report cache data through /proc/pid/seccomp_cache To: YiFei Zhu Cc: containers@lists.linux-foundation.org, YiFei Zhu , bpf , Linux Kernel Mailing List , Aleksa Sarai , Andrea Arcangeli , Andy Lutomirski , David Laight , Dimitrios Skarlatos , Giuseppe Scrivano , Hubertus Franke , Jack Chen , Jann Horn , Josep Torrellas , Kees Cook , Tianyin Xu , Tobin Feldman-Fitzthum , Tycho Andersen , Valentin Rothberg , Will Drewry Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org Hi Yifei, On Sun, Oct 11, 2020 at 8:08 PM 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 > [...] > > This file is guarded by CONFIG_SECCOMP_CACHE_DEBUG with a default > of N because I think certain users of seccomp might not want the > application to know which syscalls are definitely usable. For > the same reason, it is also guarded by CAP_SYS_ADMIN. > > Suggested-by: Jann Horn > Link: https://lore.kernel.org/lkml/CAG48ez3Ofqp4crXGksLmZY6=fGrF_tWyUCg7PBkAetvbbOPeOA@mail.gmail.com/ > Signed-off-by: YiFei Zhu > @@ -2311,3 +2314,59 @@ static int __init seccomp_sysctl_init(void) > device_initcall(seccomp_sysctl_init) > > #endif /* CONFIG_SYSCTL */ > + > +#ifdef CONFIG_SECCOMP_CACHE_DEBUG > +/* Currently CONFIG_SECCOMP_CACHE_DEBUG implies SECCOMP_ARCH_NATIVE */ Should there be a dependency on SECCOMP_ARCH_NATIVE? Should all architectures that implement seccomp have this? E.g. mips does select HAVE_ARCH_SECCOMP_FILTER, but doesn't have SECCOMP_ARCH_NATIVE? (noticed with preliminary out-of-tree seccomp implementation for m68k, which doesn't have SECCOMP_ARCH_NATIVE > +static void proc_pid_seccomp_cache_arch(struct seq_file *m, const char *name, > + const void *bitmap, size_t bitmap_size) > +{ > + int nr; > + > + for (nr = 0; nr < bitmap_size; nr++) { > + bool cached = test_bit(nr, bitmap); > + char *status = cached ? "ALLOW" : "FILTER"; > + > + seq_printf(m, "%s %d %s\n", name, nr, status); > + } > +} > + > +int proc_pid_seccomp_cache(struct seq_file *m, struct pid_namespace *ns, > + struct pid *pid, struct task_struct *task) > +{ > + struct seccomp_filter *f; > + unsigned long flags; > + > + /* > + * We don't want some sandboxed process to know what their seccomp > + * filters consist of. > + */ > + if (!file_ns_capable(m->file, &init_user_ns, CAP_SYS_ADMIN)) > + return -EACCES; > + > + if (!lock_task_sighand(task, &flags)) > + return -ESRCH; > + > + f = READ_ONCE(task->seccomp.filter); > + if (!f) { > + unlock_task_sighand(task, &flags); > + return 0; > + } > + > + /* prevent filter from being freed while we are printing it */ > + __get_seccomp_filter(f); > + unlock_task_sighand(task, &flags); > + > + proc_pid_seccomp_cache_arch(m, SECCOMP_ARCH_NATIVE_NAME, > + f->cache.allow_native, error: ‘struct action_cache’ has no member named ‘allow_native’ struct action_cache is empty if SECCOMP_ARCH_NATIVE is not defined (so there are checks for it). > + SECCOMP_ARCH_NATIVE_NR); > + > +#ifdef SECCOMP_ARCH_COMPAT > + proc_pid_seccomp_cache_arch(m, SECCOMP_ARCH_COMPAT_NAME, > + f->cache.allow_compat, > + SECCOMP_ARCH_COMPAT_NR); > +#endif /* SECCOMP_ARCH_COMPAT */ > + > + __put_seccomp_filter(f); > + return 0; > +} > +#endif /* CONFIG_SECCOMP_CACHE_DEBUG */ > -- > 2.28.0 > -- Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds