On Tue, Feb 13, 2018 at 3:47 PM, Kees Cook <keesc...@chromium.org> wrote: > On Tue, Feb 13, 2018 at 7:42 AM, Sargun Dhillon <sar...@sargun.me> wrote: >> This patchset enables seccomp filters to be written in eBPF. Although, >> this patchset doesn't introduce much of the functionality enabled by >> eBPF, it lays the ground work for it. >> >> It also introduces the capability to dump eBPF filters via the PTRACE >> API in order to make it so that CHECKPOINT_RESTORE will be satisifed. >> In the attached samples, there's an example of this. One can then use >> BPF_OBJ_GET_INFO_BY_FD in order to get the actual code of the program, >> and use that at reload time. >> >> The primary reason for not adding maps support in this patchset is >> to avoid introducing new complexities around PR_SET_NO_NEW_PRIVS. >> If we have a map that the BPF program can read, it can potentially >> "change" privileges after running. It seems like doing writes only >> is safe, because it can be pure, and side effect free, and therefore >> not negatively effect PR_SET_NO_NEW_PRIVS. Nonetheless, if we come >> to an agreement, this can be in a follow-up patchset. > > What's the reason for adding eBPF support? seccomp shouldn't need it, > and it only makes the code more complex. I'd rather stick with cBPF > until we have an overwhelmingly good reason to use eBPF as a "native" > seccomp filter language. >
I can think of two fairly strong use cases for eBPF's ability to call functions: logging and Tycho's user notifier thing. They let seccomp filters *do* something synchronously, which is a better match for both use cases than the current approach of "hey, I'd like to log this syscall, but it's really awkward to attach other information or to track exactly *which* filter logged what or to stack any of it". Also, eBPF's stronger arithmetic support would allow bitops (I think), which would make "is the nr in this list" quite a bit faster in some cases.