On Tue, Sep 22, 2020 at 1:44 AM YiFei Zhu <zhuyifei1999@xxxxxxxxx> wrote: > On Mon, Sep 21, 2020 at 12:47 PM Jann Horn <jannh@xxxxxxxxxx> wrote: > > > + depends on SECCOMP > > > + depends on SECCOMP_FILTER > > > > SECCOMP_FILTER already depends on SECCOMP, so the "depends on SECCOMP" > > line is unnecessary. > > The reason that this is here is because of the looks in menuconfig. > SECCOMP is the direct previous entry, so if this depends on SECCOMP > then the config would be indented. Is this looks not worth keeping or > is there some better way to do this? Ah, I didn't realize this. > > > + help > > > + Seccomp filters can potentially incur large overhead for each > > > + system call. This can alleviate some of the overhead. > > > + > > > + If in doubt, select 'none'. > > > > This should not be in arch/x86. Other architectures, such as arm64, > > should also be able to use this without extra work. > > In the initial RFC patch I only added to x86. I could add it to any > arch that has seccomp filters. Though, I'm wondering, why is SECCOMP > in the arch-specific Kconfigs? Ugh, yeah, the existing code is already bad... as far as I can tell, SECCOMP shouldn't be there, and instead the arch-specific Kconfig should define something like HAVE_ARCH_SECCOMP and then arch/Kconfig would define SECCOMP and let it depend on HAVE_ARCH_SECCOMP. It's really gross how the SECCOMP config description has been copypasted into a dozen different Kconfig files; and looking around a bit, you can actually see that e.g. s390 has an utterly outdated help text which still claims that seccomp is controlled via the ancient "/proc/<pid>/seccomp". I guess this very nicely illustrates why putting such options into arch-specific Kconfig is a bad idea. :P
