[Qemu-devel] seccomp breakage on arm

[Qemu-devel] seccomp breakage on arm

[Andreas Färber]

Hello,

I am seeing the following build failure on openSUSE Tumbleweed armv7l
with --enable-seccomp in v2.3.0-rc2:

[  551s] In file included from qemu-seccomp.c:16:0:
[  551s] /usr/include/libseccomp/seccomp.h:177:23: error: '__NR_mmap'
undeclared here (not in a function)
[  551s]  #define SCMP_SYS(x)  (__NR_##x)
[  551s]                        ^
[  551s] qemu-seccomp.c:36:7: note: in expansion of macro 'SCMP_SYS'
[  551s]      { SCMP_SYS(mmap), 247 },
[  551s]        ^
[  551s] /usr/include/libseccomp/seccomp.h:177:23: error:
'__NR_getrlimit' undeclared here (not in a function)
[  551s]  #define SCMP_SYS(x)  (__NR_##x)
[  551s]                        ^
[  551s] qemu-seccomp.c:57:7: note: in expansion of macro 'SCMP_SYS'
[  551s]      { SCMP_SYS(getrlimit), 245 },
[  551s]        ^
[  551s] /home/abuild/rpmbuild/BUILD/qemu-2.3.0-rc2/rules.mak:57: recipe
for target 'qemu-seccomp.o' failed
[  551s] make: *** [qemu-seccomp.o] Error 1

Is this a problem with libseccomp 2.2.0 / master and needs to be fixed
in the library? Or do we need to #ifdef some syscalls in qemu-seccomp.c?

aarch64 builds fine. For ppc and ppc64 we're carrying a libseccomp patch
in openSUSE, those build okay then; ppc64le is still missing in libseccomp.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)

Re: [Qemu-devel] seccomp breakage on arm

[Eduardo Otubo]

[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]

On Thu, Apr 09, 2015 at 05=01=31AM +0200, Andreas Färber wrote:
> Hello,
> 
> I am seeing the following build failure on openSUSE Tumbleweed armv7l
> with --enable-seccomp in v2.3.0-rc2:
> 
> [  551s] In file included from qemu-seccomp.c:16:0:
> [  551s] /usr/include/libseccomp/seccomp.h:177:23: error: '__NR_mmap'
> undeclared here (not in a function)
> [  551s]  #define SCMP_SYS(x)  (__NR_##x)
> [  551s]                        ^
> [  551s] qemu-seccomp.c:36:7: note: in expansion of macro 'SCMP_SYS'
> [  551s]      { SCMP_SYS(mmap), 247 },
> [  551s]        ^
> [  551s] /usr/include/libseccomp/seccomp.h:177:23: error:
> '__NR_getrlimit' undeclared here (not in a function)
> [  551s]  #define SCMP_SYS(x)  (__NR_##x)
> [  551s]                        ^
> [  551s] qemu-seccomp.c:57:7: note: in expansion of macro 'SCMP_SYS'
> [  551s]      { SCMP_SYS(getrlimit), 245 },
> [  551s]        ^
> [  551s] /home/abuild/rpmbuild/BUILD/qemu-2.3.0-rc2/rules.mak:57: recipe
> for target 'qemu-seccomp.o' failed
> [  551s] make: *** [qemu-seccomp.o] Error 1
> 
> Is this a problem with libseccomp 2.2.0 / master and needs to be fixed
> in the library? Or do we need to #ifdef some syscalls in qemu-seccomp.c?

This should be already fixed in the library as mentioned by the
maintainer in this[0] thread. Adding Paul Moore in CC. There's also a
bug entry on launchpad[1] for that. I provided the patch (before the
pull reuqest) requesting for some review and testing but never heard
back again. Also CC'ing Karl-Philipp Richter (bug owner) for some
opinions on that as well.

Regards,

[0] http://sourceforge.net/p/libseccomp/mailman/message/32955831/
[1] https://bugs.launchpad.net/qemu/+bug/1363641

-- 
Eduardo Otubo
ProfitBricks GmbH

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] seccomp breakage on arm

[Paul Moore]

On Thursday, April 09, 2015 10:21:52 AM Eduardo Otubo wrote:
> On Thu, Apr 09, 2015 at 05=01=31AM +0200, Andreas Färber wrote:
> > Hello,
> > 
> > I am seeing the following build failure on openSUSE Tumbleweed armv7l
> > with --enable-seccomp in v2.3.0-rc2:
> > 
> > [  551s] In file included from qemu-seccomp.c:16:0:
> > [  551s] /usr/include/libseccomp/seccomp.h:177:23: error: '__NR_mmap'
> > undeclared here (not in a function)
> > [  551s]  #define SCMP_SYS(x)  (__NR_##x)
> > [  551s]                        ^
> > [  551s] qemu-seccomp.c:36:7: note: in expansion of macro 'SCMP_SYS'
> > [  551s]      { SCMP_SYS(mmap), 247 },
> > [  551s]        ^
> > [  551s] /usr/include/libseccomp/seccomp.h:177:23: error:
> > '__NR_getrlimit' undeclared here (not in a function)
> > [  551s]  #define SCMP_SYS(x)  (__NR_##x)
> > [  551s]                        ^
> > [  551s] qemu-seccomp.c:57:7: note: in expansion of macro 'SCMP_SYS'
> > [  551s]      { SCMP_SYS(getrlimit), 245 },
> > [  551s]        ^
> > [  551s] /home/abuild/rpmbuild/BUILD/qemu-2.3.0-rc2/rules.mak:57: recipe
> > for target 'qemu-seccomp.o' failed
> > [  551s] make: *** [qemu-seccomp.o] Error 1
> > 
> > Is this a problem with libseccomp 2.2.0 / master and needs to be fixed
> > in the library? Or do we need to #ifdef some syscalls in qemu-seccomp.c?
> 
> This should be already fixed in the library as mentioned by the
> maintainer in this[0] thread. Adding Paul Moore in CC. There's also a
> bug entry on launchpad[1] for that. I provided the patch (before the
> pull reuqest) requesting for some review and testing but never heard
> back again. Also CC'ing Karl-Philipp Richter (bug owner) for some
> opinions on that as well.
> 
> Regards,
> 
> [0] http://sourceforge.net/p/libseccomp/mailman/message/32955831/
> [1] https://bugs.launchpad.net/qemu/+bug/1363641

This should be fixed with libseccomp v2.2.0; if you are still seeing problems 
using v2.2.0 let me know.

-- 
paul moore
security @ redhat

Re: [Qemu-devel] seccomp breakage on arm

[Andreas Färber]

Am 09.04.2015 um 11:10 schrieb Paul Moore:
> On Thursday, April 09, 2015 10:21:52 AM Eduardo Otubo wrote:
>> On Thu, Apr 09, 2015 at 05=01=31AM +0200, Andreas Färber wrote:
>>> Hello,
>>>
>>> I am seeing the following build failure on openSUSE Tumbleweed armv7l
>>> with --enable-seccomp in v2.3.0-rc2:
>>>
>>> [  551s] In file included from qemu-seccomp.c:16:0:
>>> [  551s] /usr/include/libseccomp/seccomp.h:177:23: error: '__NR_mmap'
>>> undeclared here (not in a function)
>>> [  551s]  #define SCMP_SYS(x)  (__NR_##x)
>>> [  551s]                        ^
>>> [  551s] qemu-seccomp.c:36:7: note: in expansion of macro 'SCMP_SYS'
>>> [  551s]      { SCMP_SYS(mmap), 247 },
>>> [  551s]        ^
>>> [  551s] /usr/include/libseccomp/seccomp.h:177:23: error:
>>> '__NR_getrlimit' undeclared here (not in a function)
>>> [  551s]  #define SCMP_SYS(x)  (__NR_##x)
>>> [  551s]                        ^
>>> [  551s] qemu-seccomp.c:57:7: note: in expansion of macro 'SCMP_SYS'
>>> [  551s]      { SCMP_SYS(getrlimit), 245 },
>>> [  551s]        ^
>>> [  551s] /home/abuild/rpmbuild/BUILD/qemu-2.3.0-rc2/rules.mak:57: recipe
>>> for target 'qemu-seccomp.o' failed
>>> [  551s] make: *** [qemu-seccomp.o] Error 1
>>>
>>> Is this a problem with libseccomp 2.2.0 / master and needs to be fixed
>>> in the library? Or do we need to #ifdef some syscalls in qemu-seccomp.c?
>>
>> This should be already fixed in the library as mentioned by the
>> maintainer in this[0] thread. Adding Paul Moore in CC. There's also a
>> bug entry on launchpad[1] for that. I provided the patch (before the
>> pull reuqest) requesting for some review and testing but never heard
>> back again. Also CC'ing Karl-Philipp Richter (bug owner) for some
>> opinions on that as well.
>>
>> Regards,
>>
>> [0] http://sourceforge.net/p/libseccomp/mailman/message/32955831/
>> [1] https://bugs.launchpad.net/qemu/+bug/1363641
> 
> This should be fixed with libseccomp v2.2.0; if you are still seeing problems 
> using v2.2.0 let me know.

This *is* with libseccomp v2.2.0, as mentioned above, and I had checked
that there were no related changes beyond v2.2.0 on your master branch.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)

Re: [Qemu-devel] seccomp breakage on arm

[Paul Moore]

On Thursday, April 09, 2015 02:28:24 PM Andreas Färber wrote:
> Am 09.04.2015 um 11:10 schrieb Paul Moore:
> > On Thursday, April 09, 2015 10:21:52 AM Eduardo Otubo wrote:
> >> On Thu, Apr 09, 2015 at 05=01=31AM +0200, Andreas Färber wrote:
> >>> Hello,
> >>> 
> >>> I am seeing the following build failure on openSUSE Tumbleweed armv7l
> >>> with --enable-seccomp in v2.3.0-rc2:
> >>> 
> >>> [  551s] In file included from qemu-seccomp.c:16:0:
> >>> [  551s] /usr/include/libseccomp/seccomp.h:177:23: error: '__NR_mmap'
> >>> undeclared here (not in a function)
> >>> [  551s]  #define SCMP_SYS(x)  (__NR_##x)
> >>> [  551s]                        ^
> >>> [  551s] qemu-seccomp.c:36:7: note: in expansion of macro 'SCMP_SYS'
> >>> [  551s]      { SCMP_SYS(mmap), 247 },
> >>> [  551s]        ^
> >>> [  551s] /usr/include/libseccomp/seccomp.h:177:23: error:
> >>> '__NR_getrlimit' undeclared here (not in a function)
> >>> [  551s]  #define SCMP_SYS(x)  (__NR_##x)
> >>> [  551s]                        ^
> >>> [  551s] qemu-seccomp.c:57:7: note: in expansion of macro 'SCMP_SYS'
> >>> [  551s]      { SCMP_SYS(getrlimit), 245 },
> >>> [  551s]        ^
> >>> [  551s] /home/abuild/rpmbuild/BUILD/qemu-2.3.0-rc2/rules.mak:57: recipe
> >>> for target 'qemu-seccomp.o' failed
> >>> [  551s] make: *** [qemu-seccomp.o] Error 1
> >>> 
> >>> Is this a problem with libseccomp 2.2.0 / master and needs to be fixed
> >>> in the library? Or do we need to #ifdef some syscalls in qemu-seccomp.c?
> >> 
> >> This should be already fixed in the library as mentioned by the
> >> maintainer in this[0] thread. Adding Paul Moore in CC. There's also a
> >> bug entry on launchpad[1] for that. I provided the patch (before the
> >> pull reuqest) requesting for some review and testing but never heard
> >> back again. Also CC'ing Karl-Philipp Richter (bug owner) for some
> >> opinions on that as well.
> >> 
> >> Regards,
> >> 
> >> [0] http://sourceforge.net/p/libseccomp/mailman/message/32955831/
> >> [1] https://bugs.launchpad.net/qemu/+bug/1363641
> > 
> > This should be fixed with libseccomp v2.2.0; if you are still seeing
> > problems using v2.2.0 let me know.
> 
> This *is* with libseccomp v2.2.0, as mentioned above, and I had checked
> that there were no related changes beyond v2.2.0 on your master branch.

I saw were you were *asking* if this was a problem with libseccomp v2.2.0, not 
stating that you were seeing a problem with v2.2.0; I interpreted your 
comments as running a version of libseccomp < v2.2.0 and you were asking if 
the problem had been fixed before your upgraded your copy of libseccomp.

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.

Thanks for the report, I'm sorry about the initial confusion.

-Paul

-- 
paul moore
security @ redhat

Re: [Qemu-devel] seccomp breakage on arm

[Peter Maydell]

On 9 April 2015 at 22:27, Paul Moore <pmoore@redhat.com> 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. 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 :-(

For the moment I think we should revert the "2.2 is OK on
ARM" QEMU configure patch for QEMU's 2.3 release, and go
back to the status-quo of "assume this only works on x86".

thanks
-- PMM

Re: [Qemu-devel] seccomp breakage on arm

[Paul Moore]

On Thursday, April 09, 2015 11:32:51 PM Peter Maydell wrote:
> On 9 April 2015 at 22:27, Paul Moore <pmoore@redhat.com> 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.  Due to the nature of syscall filtering and the libseccomp API, 
the libseccomp library needs to maintain its own list of syscalls for each 
architecture/ABI; while this list is fairly static and doesn't often change, 
there are situations (e.g. adding a new ABI) that cause significant change and 
take some time to sort out.  If you feel that you have a better design for 
libseccomp you are always welcome to submit patches, I'm happy to review code.

I can't promise you there won't ever be bugs, but I think I've demonstrated 
that we take these things seriously and address the issues as we are made 
aware of them.  Surely libseccomp isn't the only project to have bugs ;)

> For the moment I think we should revert the "2.2 is OK on
> ARM" QEMU configure patch for QEMU's 2.3 release, and go
> back to the status-quo of "assume this only works on x86".

The QEMU developers can do whatever they feel is best for the project; my main 
concern is maintaining libseccomp.

-- 
paul moore
security @ redhat

Re: [Qemu-devel] seccomp breakage on arm

[Peter Maydell]

On 10 April 2015 at 00:46, Paul Moore <pmoore@redhat.com> wrote:
> On Thursday, April 09, 2015 11:32:51 PM Peter Maydell wrote:
>> On 9 April 2015 at 22:27, Paul Moore <pmoore@redhat.com> 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. 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 on other architectures. Otherwise every
project using seccomp has to manually say "don't try to use this
on non-x86". If seccomp failed to build on the other architectures
you'd find out about problems from distro packagers without unusable
packages escaping into the wild. (QEMU's use case doesn't seem to
be particularly complex so it would be possible to write a
compile-only seccomp test case that made sure SCMP_SYS(foo)
worked for every 'foo' seccomp has ever supported on any arch.)

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?

thanks
-- PMM

Re: [Qemu-devel] 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 <pmoore@redhat.com> wrote:
> > On Thursday, April 09, 2015 11:32:51 PM Peter Maydell wrote:
> >> On 9 April 2015 at 22:27, Paul Moore <pmoore@redhat.com> 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

Re: [Qemu-devel] seccomp breakage on arm

[Peter Maydell]

On 10 April 2015 at 16:16, Paul Moore <pmoore@redhat.com> wrote:
> Both your tone and unsolicited advice have been noted.

Sorry. Looking back you're correct that I was out of line here.
One of my aspirations for QEMU as a project is that we can
maintain a polite and civil level of conversation on
our mailing list, and I fell below that this time. I'll
try to do better in future.

I have put looking at the libseccomp documentation on my
todo list.

-- PMM

Re: [Qemu-devel] seccomp breakage on arm

[Andreas Färber]

Am 10.04.2015 um 17:16 schrieb Paul Moore:
> On Friday, April 10, 2015 01:44:32 PM Peter Maydell wrote:
>> On 10 April 2015 at 00:46, Paul Moore <pmoore@redhat.com> wrote:
>>> On Thursday, April 09, 2015 11:32:51 PM Peter Maydell wrote:
>>>> On 9 April 2015 at 22:27, Paul Moore <pmoore@redhat.com> 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

Appreciated, I was already looking into patching our package.

Maybe it helps your understanding that Peter is about to release QEMU
v2.3.0, so everyone is on edge when build issues get found last minute.

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.

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)

Re: [Qemu-devel] seccomp breakage on arm

[Paul Moore]

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