On Wed, Jul 16, 2014 at 2:56 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > On Wed, Jul 16, 2014 at 1:56 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> 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. > > That works. I didn't have a strong feeling about it. I was just > wondering if there was a good way to self-document that phase1 is on > the fast path, and phase2 was on the slow path for tracing. The > existing comments really should be sufficient, though. > > You mentioned architectures providing "sd" directly. I wonder if that > new optional ability should be mentioned in the Kconfig help text that > defines what's needed for an arch to support SECCOMP_FILTER? Good call. Queued for v2. > > -Kees > > -- > Kees Cook > Chrome OS Security -- Andy Lutomirski AMA Capital Management, LLC
