Re: [Qemu-ppc] seccomp breakage on arm

[Paul Moore]

On Friday, April 10, 2015 01:44:32 PM Peter Maydell wrote:
> On 10 April 2015 at 00:46, Paul Moore <address@hidden> wrote:
> > On Thursday, April 09, 2015 11:32:51 PM Peter Maydell wrote:
> >> On 9 April 2015 at 22:27, Paul Moore <address@hidden> wrote:
> >> > Regardless, I think I see what the problem is, and if I'm correct it
> >> > affects time, umount, stime, alarm, utime, getrlimit, select, readdir,
> >> > mmap, socketcall, syscall, and ipc.  I'm traveling at the moment so a
> >> > patch may be a bit delayed, but I'll be sure to CC you on the fix in
> >> > case
> >> > you are able to do some testing.
> >> 
> >> I was expecting seccomp 2.2.x to fix this by not requiring the
> >> existence in particular of *any* __NR_* define.
> > 
> > I'm sorry to tell you that it doesn't work that way.
> > 
> >> If you don't make the header cope with any of them being missing then
> >> this is going to continue to be fragile and liable to breakage on new
> >> architectures into the future, I suspect :-(
> > 
> > There are always going to be teething problems with support for new
> > architectures, especially ones that I do not personally have in front of
> > me for testing.
> 
> I appreciate the testing issue, but ARM is not a new architecture.
> 32-bit ARM has been around for decades, and 64-bit ARM now for
> several years.

ARM support is relatively new to libseccomp; I assumed we all recognized that 
ARM as an architecture/ABI has been around for some time.

> If in practice the only architecture you can test and support is i386/x86_64
> then it might be better to ensure you only build for that, so distros don't 
> auto-build and ship unusable versions of the library ... {snip}

Both your tone and unsolicited advice have been noted.

> It's not clear to me how the current APIs QEMU is using would
> cope with trying to whitelist a new syscall that the system's
> libseccomp didn't know about; presumably SCMP_SYS(fancy_new_thing)
> will be a compile failure. Is there a runtime function we can
> call to pass it a string "fancy_new_thing" so we can get a runtime
> check on whether the syscall is supported by seccomp instead?

I would suggest looking at the libseccomp man pages and header file.  
Admittedly our documentation could be better (what project couldn't improve on 
their documentation?), but it should answer your questions about runtime 
detection.

Also, if anyone even cares, I just committed a fix for the syscall problem 
Andreas reported:

https://github.com/seccomp/libseccomp/commit/d1019115acdc8460c9a1f8a878768001a3c32431

-- 
paul moore
security @ redhat