lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 18 Dec 2020 13:35:21 +0100 From: Geert Uytterhoeven <geert@...ux-m68k.org> To: YiFei Zhu <zhuyifei1999@...il.com> Cc: Linux Containers <containers@...ts.linux-foundation.org>, YiFei Zhu <yifeifz2@...inois.edu>, bpf <bpf@...r.kernel.org>, Linux Kernel Mailing List <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>, Kees Cook <keescook@...omium.org>, 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 v5 seccomp 5/5] seccomp/cache: Report cache data through /proc/pid/seccomp_cache Hi YiFei, On Thu, Dec 17, 2020 at 7:34 PM YiFei Zhu <zhuyifei1999@...il.com> wrote: > On Thu, Dec 17, 2020 at 6:14 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote: > > 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 > > You are correct. This specific patch in this series was not applied, > and this was addressed in a follow up patch series [1]. MIPS does not > define SECCOMP_ARCH_NATIVE because the bitmap expects syscall numbers > to start from 0, whereas MIPS does not (defines > CONFIG_HAVE_SPARSE_SYSCALL_NR). The follow up patch makes it so that > any arch with HAVE_SPARSE_SYSCALL_NR (currently just MIPS) cannot have > CONFIG_SECCOMP_CACHE_DEBUG on, by the depend on clause. > > I see that you are doing an out of tree seccomp implementation for > m68k. Assuming unchanged arch/xtensa/include/asm/syscall.h, something > like this to arch/m68k/include/asm/seccomp.h should make it work: > > #define SECCOMP_ARCH_NATIVE AUDIT_ARCH_M68K > #define SECCOMP_ARCH_NATIVE_NR NR_syscalls > #define SECCOMP_ARCH_NATIVE_NAME "m68k" > > If the file does not exist already, arch/xtensa/include/asm/seccomp.h > is a good example of how the file should look like, and remember to > remove `generic-y += seccomp.h` from arch/m68k/include/asm/Kbuild. > > [1] https://lore.kernel.org/lkml/cover.1605101222.git.yifeifz2@illinois.edu/T/ Thank you for your extensive explanation. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-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
Powered by blists - more mailing lists