Thread (1 message) 1 message, 1 author, 2017-08-08

[PATCH 1/4] seccomp: Provide matching filter for introspection

From: Kees Cook <hidden>
Date: 2017-08-08 01:46:07
Also in: lkml

On Mon, Aug 7, 2017 at 6:03 PM, Tyler Hicks [off-list ref] wrote:
quoted
-static u32 seccomp_run_filters(const struct seccomp_data *sd)
+static u32 seccomp_run_filters(const struct seccomp_data *sd,
+                            struct seccomp_filter **match)
 {
      struct seccomp_data sd_local;
      u32 ret = SECCOMP_RET_ALLOW;
My version of this patch initialized *match to f here. The reason I did
that is because if BPF_PROG_RUN() returns RET_ALLOW for all
filters, I didn't want *match to remain NULL when seccomp_run_filters()
returns. FILTER_FLAG_LOG nor FILTER_FLAG_KILL_PROCESS would be affected
by this because they don't care about RET_ALLOW actions but there could
conceivably be a filter flag in the future that cares about RET_ALLOW
and not initializing *match to the first filter could result in a latent
bug for that filter flag.
Very true, yes. I did intentionally adjust this because I wanted to
keep the hot path as untouched as possible.
I'm fine with not adding the initialization since this is a hot path and
it doesn't help any of the currently existing/planned filter flags but I
wanted to at least mention it.
Yeah, and while I doubt I'll want to ever check "match" for RET_ALLOW,
I'll add a big comment there to explain it.
Reviewed-by: Tyler Hicks <redacted>
Thanks!

-Kees

-- 
Kees Cook
Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help