Q: clarify the seccomp_syscall_resolve_name_rewrite() behavior

[lucab]

I was reading the doc and the source in parallel, and I'm still not sure about the behavior and recommended usage of seccomp_syscall_resolve_name_rewrite().

According to the manpage:

[seccomp_syscall_resolve_name*()] resolve the commonly used syscall
name to the syscall number used by the kernel and the rest of the libseccomp API,
with seccomp_syscall_resolve_name_rewrite() rewriting the syscall number for
architectures that modify the syscall.

Some doubts I have:

• How does re-writing interact with pseudo-syscalls? Perl bindings are a bit more explicit here, but I'm not sure if correct and cannot reproduce that behavior on x86_64. I'll be happy to get some hints/pointer/examples here.
• Which name resolving function should be recommended and used by consumers? "_rewrite" seems to be more precise in some cases (which?), but is the non-rewrite behavior a concern people should be aware? Does it have security implications?
• The default/simpler seccomp_syscall_resolve_name has a non-rewrite behavior. Is that on purpose and what are the implications? Would it make sense to switch it to the rewrite behavior (and if not, why)?
• When resolving with a non-rewrite behavior, will other libseccomp functions perform the rewriting internally or not?

Sorry for the long list of questions, but I didn't get a clear answer for this when navigating through the code. I think I got the general idea but I fear that some details in it may be wrong, so I'd prefer if they could be clarified here from a knowledgeable source. I'll be happy to expand the docs (if needed) with those inputs.

[pcmoore]

Let me try to answer all your questions, point by point. Let me know if anything is still confusing at the end. In the future you might try directing questions like these to the mailing list:

• https://groups.google.com/forum/#!forum/libseccomp

How does re-writing interact with pseudo-syscalls? Perl bindings are a bit more explicit here, but I'm not sure if correct and cannot reproduce that behavior on x86_64. I'll be happy to get some hints/pointer/examples here.

Good question. Basically rewriting only happens when the syscall name in question resolves to a pseudo syscall, e.g. the ipc() syscalls on 32-bit x86. Keep in mind that syscall rewriting is relatively rare, with only 32-bit x86 and s390/s390x providing syscall rewriting routines.

Which name resolving function should be recommended and used by consumers? "_rewrite" seems to be more precise in some cases (which?), but is the non-rewrite behavior a concern people should be aware? Does it have security implications?

This probably isn't the answer you are looking for, but the best answer is: "it depends". I've seen libseccomp used in a variety of different applications and there is no one set of API calls which works for all the different use cases; this is why we provide many different variants in libseccomp.

The default/simpler seccomp_syscall_resolve_name has a non-rewrite behavior. Is that on purpose and what are the implications? Would it make sense to switch it to the rewrite behavior (and if not, why)?

Sometimes you want to know if a syscall is implemented on a specific architecture and seccomp_syscall_resolve_name() will tell you that via a negative syscall number.

When resolving with a non-rewrite behavior, will other libseccomp functions perform the rewriting internally or not?

It depends on the APIs used. For example, the seccomp_rule_add() function will accept pseudo syscalls and make a "best effort" to create the filter as specified (either ignoring of rewriting the syscall depending on the architecture), while the seccomp_rule_add_exact() function will fail if the filter cannot be created exactly as described on the architecture.

[lucab]

Thanks for the details, I opened this on github as it is easier to link from other projects and turn into actionable items.

With pointers to x86 & s390 rewriting, I'm understanding this now. I think that my personal confusion arose because the term "pseudo syscall" is used both for really non-existing syscalls and for multiplexed syscalls. In the former case glibc often uses transparent wrappers (e. waitpid -> wait4 on x86_64) and I was wondering if libseccomp re-writing was supposed to do something similar.

Given your answer, I think that manpages can be enhanced with the following details:

• "resolve page" should mention that rewriting takes care of multiplexed syscalls, with x86 socket & ipc examples
• the usecases and usages of rewriting and non-rewriting resolving should be listed explicitly
• "add page" should mention "rewriting" and "multiplexed" somewhere (for doc grepping), talk about internal rewriting and link to "resolve page" (perhaps moving the x86 examples out of it)

Is that ok? If so, I'll follow up with a PR for doc changes.

[pcmoore]

I think that my personal confusion arose because the term "pseudo syscall" is used both for really non-existing syscalls and for multiplexed syscalls. In the former case glibc often uses transparent wrappers (e. waitpid -> wait4 on x86_64) and I was wondering if libseccomp re-writing was supposed to do something similar.

In cases where the ABI does not define a syscall and glibc does a transparent remapping, e.g. your waitpid example on x86_64, then I believe libseccomp should have code to do a syscall rewrite. However, as you found out, there are several cases where this rewriting code is still missing.

If you have a list of syscalls like the example above, it would be great if you could file a new issue against libseccomp with the information.

[pcmoore]

Merged PR #43 via a66f000 so I'm considering this closed; thanks for the help!