Messages in this thread | | | From | Jann Horn <> | Date | Tue, 22 Sep 2020 02:25:46 +0200 | Subject | Re: [RFC PATCH seccomp 1/2] seccomp/cache: Add "emulator" to check if filter is arg-dependent |
| |
On Tue, Sep 22, 2020 at 1:44 AM YiFei Zhu <zhuyifei1999@gmail.com> wrote: > On Mon, Sep 21, 2020 at 12:47 PM Jann Horn <jannh@google.com> 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
| |