LDP
/
man-pages
mirror of https://github.com/mkerrisk/man-pages
0
1
Fork 0
Code Releases Activity

seccomp.2: Note why all filters in a set are executed even after SECCOMP_RET_KILL 

Reported-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2015-09-05 09:00:02 +02:00
parent 755a656a49
commit d74503a55a
1 changed files with 16 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
man2/seccomp.2
View File

@ -346,6 +346,22 @@ are "data" to be associated with this return value.
If multiple filters exist, they are \fIall\fP executed,
in reverse order of their addition to the filter tree\(emthat is,
the most recently installed filter is executed first.
(Note that all filters will be called
even if one of the earlier filters returns
.BR SECCOMP_RET_KILL .
This is done to simplify the kernel code and to provide a
tiny speed-up in the execution of sets of filters by
avoiding a check for this uncommon case.)
.\" From an Aug 2015 conversation with Kees Cook where I asked why *all*
.\" filters even if one of the early filters returns SECCOMP_RET_KILL:
.\"
.\" It's just because it would be an optimization that would only speed up
.\" the RET_KILL case, but it's the uncommon one and the one that doesn't
.\" benefit meaningfully from such a change (you need to kill the process
.\" really quickly?). We would speed up killing a program at the (albeit
.\" tiny) expense to all other filtered programs. Best to keep the filter
.\" execution logic clear, simple, and as fast as possible for all
.\" filters.
The return value for the evaluation of a given system call is the first-seen
.BR SECCOMP_RET_ACTION
value of highest precedence (along with its accompanying data)