On Wed, Jul 16, 2014 at 1:12 PM, Kees Cook [off-list ref] wrote:

On Tue, Jul 15, 2014 at 12:32 PM, Andy Lutomirski [off-list ref] wrote:

quoted

The reason I did this is to add a seccomp API that will be usable
for an x86 fast path.  The x86 entry code needs to use a rather
expensive slow path for a syscall that might be visible to things
like ptrace.  By splitting seccomp into two phases, we can check
whether we need the slow path and then use the fast path in if the
filter allows the syscall or just returns some errno.

As a side effect, I think the new code is much easier to understand
than the old code.

I'd agree. The #idefs got a little weirder, but the actual code flow
was much easier to read. I wonder if "phase1" and "phase2" should be
renamed "pretrace" and "tracing" or something more meaningful? Or
"fast" and "slow"?

Queue the bikeshedding :)

I like "phase1" and "phase2" because it makes it clear that phase1 has
to come first.  But I'd be amenable to counterarguments.

quoted

This has one user-visible effect: the audit record written for
SECCOMP_RET_TRACE is now a simple indication that SECCOMP_RET_TRACE
happened.  It used to depend in a complicated way on what the tracer
did.  I couldn't make much sense of it.

I think this change is okay. The only way to get the audit record to
report SIGSYS before was to have an additional signal come in and kill
it while the tracer was working on it. Which is confusing too. I like
this way better.

Thanks :)

--Andy

-Kees

--
Kees Cook
Chrome OS Security

-- 
Andy Lutomirski
AMA Capital Management, LLC