[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202011031606.423EC9E@keescook>
Date: Tue, 3 Nov 2020 16:11:40 -0800
From: Kees Cook <keescook@...omium.org>
To: YiFei Zhu <zhuyifei1999@...il.com>
Cc: containers@...ts.linux-foundation.org,
YiFei Zhu <yifeifz2@...inois.edu>, linux-csky@...r.kernel.org,
linux-parisc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org,
linux-sh@...r.kernel.org, linux-xtensa@...ux-xtensa.org,
linux-kernel@...r.kernel.org, Aleksa Sarai <cyphar@...har.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Andy Lutomirski <luto@...capital.net>,
David Laight <David.Laight@...lab.com>,
Dimitrios Skarlatos <dskarlat@...cmu.edu>,
Giuseppe Scrivano <gscrivan@...hat.com>,
Hubertus Franke <frankeh@...ibm.com>,
Jack Chen <jianyan2@...inois.edu>,
Jann Horn <jannh@...gle.com>,
Josep Torrellas <torrella@...inois.edu>,
Tianyin Xu <tyxu@...inois.edu>,
Tobin Feldman-Fitzthum <tobin@....com>,
Tycho Andersen <tycho@...ho.pizza>,
Valentin Rothberg <vrothber@...hat.com>,
Will Drewry <wad@...omium.org>
Subject: Re: [PATCH seccomp 0/8] seccomp: add bitmap cache support on
remaining arches and report cache in procfs
On Tue, Nov 03, 2020 at 07:42:56AM -0600, YiFei Zhu wrote:
> From: YiFei Zhu <yifeifz2@...inois.edu>
>
> This patch series enables bitmap cache for the remaining arches with
> SECCOMP_FILTER, other than MIPS.
>
> I was unable to find any of the arches having subarch-specific NR_syscalls
> macros, so generic NR_syscalls is used. SH's syscall_get_arch seems to
> only have the 32-bit subarch implementation. I'm not sure if this is
> expected.
>
> This series has not been tested; I have not built all the cross compilers
> necessary to build test, let alone run the kernel or benchmark the
> performance, so help on making sure the bitmap cache works as expected
> would be appreciated. The series applies on top of Kees's for-next/seccomp
> branch.
Thank you! This looks good. I wonder if the different handling of little
endian is worth solving -- I'm suspicious about powerpc's use of
__LITTLE_ENDIAN__ vs a CONFIG, but I guess the compiler would match the
target endian-ness. Regardless, it captures what the architectures are
doing, and gets things standardized.
>
> YiFei Zhu (8):
> csky: Enable seccomp architecture tracking
> parisc: Enable seccomp architecture tracking
I don't have compilers for these.
> powerpc: Enable seccomp architecture tracking
> riscv: Enable seccomp architecture tracking
> s390: Enable seccomp architecture tracking
These I can build-test immediately.
> sh: Enable seccomp architecture tracking
> xtensa: Enable seccomp architecture tracking
These two are available in Ubuntu's cross compiler set, so I'll get them
added to my cross-builders.
> seccomp/cache: Report cache data through /proc/pid/seccomp_cache
In the meantime, I'll wait a bit to see if we can get some Acks/Reviews
from arch maintainers. :)
-Kees
>
> arch/Kconfig | 15 ++++++++
> arch/csky/include/asm/Kbuild | 1 -
> arch/csky/include/asm/seccomp.h | 11 ++++++
> arch/parisc/include/asm/Kbuild | 1 -
> arch/parisc/include/asm/seccomp.h | 22 +++++++++++
> arch/powerpc/include/asm/seccomp.h | 21 +++++++++++
> arch/riscv/include/asm/seccomp.h | 10 +++++
> arch/s390/include/asm/seccomp.h | 9 +++++
> arch/sh/include/asm/seccomp.h | 10 +++++
> arch/xtensa/include/asm/Kbuild | 1 -
> arch/xtensa/include/asm/seccomp.h | 11 ++++++
> fs/proc/base.c | 6 +++
> include/linux/seccomp.h | 7 ++++
> kernel/seccomp.c | 59 ++++++++++++++++++++++++++++++
> 14 files changed, 181 insertions(+), 3 deletions(-)
> create mode 100644 arch/csky/include/asm/seccomp.h
> create mode 100644 arch/parisc/include/asm/seccomp.h
> create mode 100644 arch/xtensa/include/asm/seccomp.h
>
>
> base-commit: 38c37e8fd3d2590c4234d8cfbc22158362f0eb04
> --
> 2.29.2
--
Kees Cook
Powered by blists - more mailing lists