Re: [libseccomp-discuss] [RFC PATCH] arch: add support for syscall name resolution

[Kees C. <kee...@ch...>]

On Mon, Aug 20, 2012 at 2:13 PM, Paul Moore <pm...@re...> wrote:
> On Monday, August 20, 2012 01:57:15 PM Kees Cook wrote:
>> On Mon, Aug 20, 2012 at 1:16 PM, Paul Moore <pm...@re...> wrote:
>> > Like I said, the architecture is already tied to the context - it has been
>> > since the early days of development - if you haven't already, take a look
>> > at the code, as I believe it should address all of the concerns you've
>> > described here.  If not, perhaps we can discuss this more at
>> > LinuxCon/LPC/etc., will you be there this year?
>>
>> We appear to be in feverish agreement. :) And yup, I'll be at Plumbers. :)
>
>  :)
>
>> What I've been objecting to was the email that had this patch for the API:
>>
>> +int seccomp_syscall_resolve_name(const char *name);
>>
>> I think it must contain ctx as an argument as well. How else can a
>> multi-arch host get the right syscalls?
>
> The libseccomp API deals only takes rules (syscall numbers and anything else
> that might be arch specific) in the context of the native architecture,
> *regardless* of what the library has told is the architecture of the resulting
> filter.
>
> This makes it easier for the app developer as they can always call ...
>
>  seccomp_rule_add(ctx, SCMP_ACT_ALLOW, __NR_open, 0);
>
> ... without worrying about the architecture(s) assigned to ctx; all the
> translation magic is handled internally.  Not only does this make things
> easier, it also allows us to support multiple architectures with one ctx.
> After all, how would you handle multiple simultaneous architectures?
>
> Because of this, we want seccomp_syscall_resolve_name() to *always* return the
> native syscall numbers, making the context unnecessary for this function.

Hrm, I see your point.

I find the use of "__NR_open" pretty confusing then, since it may
undergo translation into a non-native value. I'm not sure if it should
be changed or if it should be heavily documented. Hmm.

-Kees

-- 
Kees Cook
Chrome OS Security