A while ago I was trying to build a seccomp-bpf filter program that would
survive a change of x86 architecture. This was complicated for all sorts of
reasons, but one of the problems was that the different syscall numbers aren't
all available at the same time -- hence this patch.
Naming-wise, Andy Lutomirski has indicated he'd prefer the prefixes to be
__NR_x86_64_, __NR_x86_64_x32_ and __NR_i386_; however, for the latter two
sets of numbers there are existing headers that use different prefixes
(__NR_x32_ and __NR_ia32_), so altering those would involve a change and/or an
additional set of definitions. For the new constants I've left in my
original suggestion (__NR_amd64_) for the time being.
What are folks' thoughts about the preferred naming for these?
David Drysdale (1):
UAPI,x86: export syscall numbers for all x86 archs
arch/x86/entry/syscalls/Makefile | 11 ++++++++---
arch/x86/include/uapi/asm/Kbuild | 3 +++
2 files changed, 11 insertions(+), 3 deletions(-)
--
2.4.3.573.g4eafbef
Some userspace code occasionally has a need to reference the syscall
numbers for different-but-compatible architectures, so explicitly
export the generated files that contain the __NR_ia32_<name> and
__NR_x32_<name> constants.
Also, add a new generated unistd_64_amd64.h file, holding amd64
system call numbers in form __NR_amd64_<name>.
For example, this allows a seccomp-bpf filter to include filtering
for multiple architectures, and (in particular) to include x32
syscalls in an x86_64 filter. (Programmatic control of the audit
framework is another possible use case.)
Signed-off-by: David Drysdale <[email protected]>
---
arch/x86/entry/syscalls/Makefile | 11 ++++++++---
arch/x86/include/uapi/asm/Kbuild | 3 +++
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/x86/entry/syscalls/Makefile b/arch/x86/entry/syscalls/Makefile
index 57aa59fd140c..ec6811d0db0b 100644
--- a/arch/x86/entry/syscalls/Makefile
+++ b/arch/x86/entry/syscalls/Makefile
@@ -28,7 +28,7 @@ $(uapi)/unistd_32.h: $(syscall32) $(syshdr)
syshdr_abi_unistd_32_ia32 := i386
syshdr_pfx_unistd_32_ia32 := ia32_
-$(out)/unistd_32_ia32.h: $(syscall32) $(syshdr)
+$(uapi)/unistd_32_ia32.h: $(syscall32) $(syshdr)
$(call if_changed,syshdr)
syshdr_abi_unistd_x32 := common,x32
@@ -42,7 +42,12 @@ $(uapi)/unistd_64.h: $(syscall64) $(syshdr)
syshdr_abi_unistd_64_x32 := x32
syshdr_pfx_unistd_64_x32 := x32_
-$(out)/unistd_64_x32.h: $(syscall64) $(syshdr)
+$(uapi)/unistd_64_x32.h: $(syscall64) $(syshdr)
+ $(call if_changed,syshdr)
+
+syshdr_abi_unistd_64_amd64 := common,64
+syshdr_pfx_unistd_64_amd64 := amd64_
+$(uapi)/unistd_64_amd64.h: $(syscall64) $(syshdr)
$(call if_changed,syshdr)
$(out)/syscalls_32.h: $(syscall32) $(systbl)
@@ -56,8 +61,8 @@ $(out)/xen-hypercalls.h: $(srctree)/scripts/xen-hypercalls.sh
$(out)/xen-hypercalls.h: $(srctree)/include/xen/interface/xen*.h
uapisyshdr-y += unistd_32.h unistd_64.h unistd_x32.h
+uapisyshdr-$(CONFIG_X86_64) += unistd_32_ia32.h unistd_64_amd64.h unistd_64_x32.h
syshdr-y += syscalls_32.h
-syshdr-$(CONFIG_X86_64) += unistd_32_ia32.h unistd_64_x32.h
syshdr-$(CONFIG_X86_64) += syscalls_64.h
syshdr-$(CONFIG_XEN) += xen-hypercalls.h
diff --git a/arch/x86/include/uapi/asm/Kbuild b/arch/x86/include/uapi/asm/Kbuild
index 3dec769cadf7..68805cba2fad 100644
--- a/arch/x86/include/uapi/asm/Kbuild
+++ b/arch/x86/include/uapi/asm/Kbuild
@@ -4,6 +4,9 @@ include include/uapi/asm-generic/Kbuild.asm
genhdr-y += unistd_32.h
genhdr-y += unistd_64.h
genhdr-y += unistd_x32.h
+genhdr-y += unistd_64_amd64.h
+genhdr-y += unistd_64_x32.h
+genhdr-y += unistd_32_ia32.h
header-y += a.out.h
header-y += auxvec.h
header-y += bitsperlong.h
--
2.4.3.573.g4eafbef
On Tue, Jul 28, 2015 at 4:05 AM, David Drysdale <[email protected]> wrote:
> A while ago I was trying to build a seccomp-bpf filter program that would
> survive a change of x86 architecture. This was complicated for all sorts of
> reasons, but one of the problems was that the different syscall numbers aren't
> all available at the same time -- hence this patch.
Or just use libseccomp and let it take care of all the different ABI
specific warts for you. The library handles the undefined syscalls
you describe, but also multiplexed syscalls (e.g. socket related
syscalls on x86) and proper invalid arch/ABI filtering (you are
filtering x32 correctly on x86-64 right?).
* https://github.com/seccomp/libseccomp
--
paul moore
http://www.paul-moore.com
On Tue, Jul 28, 2015 at 1:20 PM, Paul Moore <[email protected]> wrote:
> On Tue, Jul 28, 2015 at 4:05 AM, David Drysdale <[email protected]> wrote:
>> A while ago I was trying to build a seccomp-bpf filter program that would
>> survive a change of x86 architecture. This was complicated for all sorts of
>> reasons, but one of the problems was that the different syscall numbers aren't
>> all available at the same time -- hence this patch.
>
> Or just use libseccomp and let it take care of all the different ABI
> specific warts for you. The library handles the undefined syscalls
> you describe, but also multiplexed syscalls (e.g. socket related
> syscalls on x86) and proper invalid arch/ABI filtering
Ah, I hadn't realized that libseccomp handled cross-architecture
stuff and the socketcall multiplexing -- very neat. I'll look into whether
I can convert my stuff to use it.
I still think exporting all the sub-arch syscall numbers is a good idea
though (even if my need for it is potentially reduced by libseccomp)...
> (you are
> filtering x32 correctly on x86-64 right?).
Yep, I think so, but it's fiddly. If I can leave the fiddliness
to libseccomp, so much the better...
Thanks for the pointer,
David
> * https://github.com/seccomp/libseccomp
>
> --
> paul moore
> http://www.paul-moore.com
On Tue, Jul 28, 2015 at 11:32 AM, David Drysdale <[email protected]> wrote:
> On Tue, Jul 28, 2015 at 1:20 PM, Paul Moore <[email protected]> wrote:
>> On Tue, Jul 28, 2015 at 4:05 AM, David Drysdale <[email protected]> wrote:
>>> A while ago I was trying to build a seccomp-bpf filter program that would
>>> survive a change of x86 architecture. This was complicated for all sorts of
>>> reasons, but one of the problems was that the different syscall numbers aren't
>>> all available at the same time -- hence this patch.
>>
>> Or just use libseccomp and let it take care of all the different ABI
>> specific warts for you. The library handles the undefined syscalls
>> you describe, but also multiplexed syscalls (e.g. socket related
>> syscalls on x86) and proper invalid arch/ABI filtering
>
> Ah, I hadn't realized that libseccomp handled cross-architecture
> stuff and the socketcall multiplexing -- very neat. I'll look into whether
> I can convert my stuff to use it.
[Ooops, forgot to hit reply-all]
It should be pretty easy; if you've been writing BPF assembly, simply
making a few function calls should be a no-brainer.
We've got man pages for each of the libseccomp APIs that should cover
most of your questions, but there is also a collection of tests (see
the "tests/" directory) which serve as reasonable examples too. If
all else fails, you can always ask for help on our mailing list:
* https://groups.google.com/d/forum/libseccomp
> I still think exporting all the sub-arch syscall numbers is a good idea
> though (even if my need for it is potentially reduced by libseccomp)...
No real argument against it from me. I just worry that some
developers accidently get the seccomp-bpf filters wrong when they do
it by hand, e.g. ABI specific filters and not properly handling x32 on
x86-64.
>> (you are filtering x32 correctly on x86-64 right?).
>
> Yep, I think so, but it's fiddly. If I can leave the fiddliness
> to libseccomp, so much the better...
Annoyingly fiddly. If we could do it over I would much prefer to see
x32 get its own 32-bit ABI token value; sharing a value with x86-64
makes things harder than they need to be, but sadly it is too late to
change it now.
> Thanks for the pointer,
> David
>
>> * https://github.com/seccomp/libseccomp
No problem, let me know if you run into any problems.
Good luck!
--
paul moore
http://www.paul-moore.com