Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752362AbbG1Pwy (ORCPT ); Tue, 28 Jul 2015 11:52:54 -0400 Received: from mail-ig0-f173.google.com ([209.85.213.173]:33015 "EHLO mail-ig0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750886AbbG1Pww (ORCPT ); Tue, 28 Jul 2015 11:52:52 -0400 MIME-Version: 1.0 X-Originating-IP: [73.143.245.155] In-Reply-To: References: <1438070731-17764-1-git-send-email-drysdale@google.com> Date: Tue, 28 Jul 2015 11:52:51 -0400 Message-ID: Subject: Re: [PATCH RFC 0/1] UAPI,x86: export syscall numbers for all x86 archs From: Paul Moore To: David Drysdale Cc: X86 ML , Thomas Gleixner , Ingo Molnar , Andy Lutomirski , "H. Peter Anvin" , Michael Kerrisk , Kees Cook , Eric Paris , Linux API , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2640 Lines: 64 On Tue, Jul 28, 2015 at 11:32 AM, David Drysdale wrote: > On Tue, Jul 28, 2015 at 1:20 PM, Paul Moore wrote: >> On Tue, Jul 28, 2015 at 4:05 AM, David Drysdale 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 www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/