On Wed, Jul 16, 2014 at 1:12 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > On Tue, Jul 15, 2014 at 12:32 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> 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. > >> 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
