On Sun, Oct 11, 2020 at 5:48 PM YiFei Zhu <zhuyifei1999@xxxxxxxxx> wrote: > SECCOMP_CACHE will only operate on syscalls that do not access > any syscall arguments or instruction pointer. To facilitate > this we need a static analyser to know whether a filter will > return allow regardless of syscall arguments for a given > architecture number / syscall number pair. This is implemented > here with a pseudo-emulator, and stored in a per-filter bitmap. > > In order to build this bitmap at filter attach time, each filter is > emulated for every syscall (under each possible architecture), and > checked for any accesses of struct seccomp_data that are not the "arch" > nor "nr" (syscall) members. If only "arch" and "nr" are examined, and > the program returns allow, then we can be sure that the filter must > return allow independent from syscall arguments. > > Nearly all seccomp filters are built from these cBPF instructions: > > BPF_LD | BPF_W | BPF_ABS > BPF_JMP | BPF_JEQ | BPF_K > BPF_JMP | BPF_JGE | BPF_K > BPF_JMP | BPF_JGT | BPF_K > BPF_JMP | BPF_JSET | BPF_K > BPF_JMP | BPF_JA > BPF_RET | BPF_K > BPF_ALU | BPF_AND | BPF_K > > Each of these instructions are emulated. Any weirdness or loading > from a syscall argument will cause the emulator to bail. > > The emulation is also halted if it reaches a return. In that case, > if it returns an SECCOMP_RET_ALLOW, the syscall is marked as good. > > Emulator structure and comments are from Kees [1] and Jann [2]. > > Emulation is done at attach time. If a filter depends on more > filters, and if the dependee does not guarantee to allow the > syscall, then we skip the emulation of this syscall. > > [1] https://lore.kernel.org/lkml/20200923232923.3142503-5-keescook@xxxxxxxxxxxx/ > [2] https://lore.kernel.org/lkml/CAG48ez1p=dR_2ikKq=xVxkoGg0fYpTBpkhJSv1w-6BG=76PAvw@xxxxxxxxxxxxxx/ > > Suggested-by: Jann Horn <jannh@xxxxxxxxxx> > Co-developed-by: Kees Cook <keescook@xxxxxxxxxxxx> > Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx> > Signed-off-by: YiFei Zhu <yifeifz2@xxxxxxxxxxxx> Reviewed-by: Jann Horn <jannh@xxxxxxxxxx>
