Quoting Paul Moore (pmo...@redhat.com): > On Friday, June 20, 2014 06:51:49 PM Serge Hallyn wrote: > > Quoting Paul Moore (pmo...@redhat.com): > > > On Thursday, June 19, 2014 02:18:16 AM Serge Hallyn wrote: > > > > include/seccomp.h carefully sets __NR_foo to a negative number if > > > > the syscall name is not known. However when actually filling in the > > > > per-arch syscall tables, we were unconditionally inserting the > > > > negative numbers. This patch uses the __NR_foo (which is the real > > > > syscall if known, or the negative number if unknown) in place of > > > > the __PNR_foo (the negative number). > > > > > > > > Without this patch, using > > > > seccomp_syscall_resolve_name_arch(finit_module), > > > > for instance, always returned a negative number, and using > > > > seccomp_add_rule on the result had no effect. With this patch, > > > > finit_module becomes properly confined. > > > > > > > > Signed-off-by: Serge Hallyn <serge.hal...@ubuntu.com> > > > > > > Sorta. > > > > > > I guess I'm not being very clear, if an ABI doesn't define a given syscall > > > then we should leave the syscall number as the __PNR_* value. > > > > With my patch, if the syscall is not known at build time then it will be > > returned as the __PNR_* value. > > What about the x86 syscall table when compiled on a x86_64 system? What > about > a MIPS syscall table when compiled on an ARM system (okay, this is contrived > but it makes a point)? > > The current policy is that libseccomp should be able to generate filters for > any ABI regardless of the host system. Unless I'm mistaken this patch breaks > that policy. > > > If we don't do this, then the seccomp_syscall_resolve_name() family of > > calls becomes worthless to me, and I'm better off checking unistd.h myself. > > (Because here now i'm trying to filter module insertion, but because > > finit_module is unknown there is libseccomp-linked program that will be > > able to filter it) > > No, we just need to update/fix the syscall tables. We've established that > the > syscall tables are outdated, the correct solution is to simply update them, > not throw out mechanisms we've built to support multiple architectures.
Ok, I see - I misunderstood the purpose of the __PNR_foo. > If you aren't able to provide a patch, I'll take care of it, but I'm still in > the middle of the MIPS64 code and making sure the AArch64 guys have what they > need. You are also welcome to go off and roll your own hack that sifts > through unistd.h. Oh the wacky benefits of Open Source :) I won't be able to today, but I can provide one early next week. -serge ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ libseccomp-discuss mailing list libseccomp-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss
