On Friday, April 10, 2015 05:40:40 PM Andreas Färber wrote: > My main concern - that you apparently misunderstood - was whether this > is a QEMU or a libseccomp issue. If it's on libseccomp's side then it's > less urgent for QEMU and any new configure checks are just candy IMO.
My opinion is that the 32-bit ARM build issue you described is a libseccomp bug (see the bug fix I sent a few hours ago); QEMU's usage of libseccomp is perfectly reasonable. That said, the libseccomp bug clearly affected QEMU in a bad way. Making matters worse is that the problem wasn't caught until late in the QEMU release process, nobody likes surprises like this. We've corrected the issue in libseccomp, and it looks like the QEMU folks are reverting ARM/seccomp support so I think we've resolved this for the immediate future. Long term I think the libseccomp project can look at adding some additional automated tests so these issues will be caught at build/packaging time, further, I think the QEMU project can restore ARM/seccomp support in the next release and look at its own testing procedures to understand why this issue wasn't caught earlier as well. -- paul moore security @ redhat
