Hi YiFei, On Thu, Dec 17, 2020 at 7:34 PM YiFei Zhu <zhuyifei1999@xxxxxxxxx> wrote: > On Thu, Dec 17, 2020 at 6:14 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxx/T/ Thank you for your extensive explanation. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx 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
