[Qemu-devel] [PULL for v2.3 00/01] seccomp branch queue

[Qemu-devel] [PULL for v2.3 00/01] seccomp branch queue

[Eduardo Otubo]

The following changes since commit 054903a832b865eb5432d79b5c9d1e1ff31b58d7:

  Update version for v2.3.0-rc1 release (2015-03-24 16:34:16 +0000)

are available in the git repository at:

  git://github.com/otubo/qemu.git tags/pull-seccomp-20150325

for you to fetch changes up to 8e27fc200457e3f2473d0069263774d4ba17bd85:

  seccomp: update libseccomp version and remove arch restriction (2015-03-25 11:03:27 +0100)

----------------------------------------------------------------
seccomp: update libseccomp version and remove arch restriction
----------------------------------------------------------------
Eduardo Otubo (1):
      seccomp: update libseccomp version and remove arch restriction

 configure | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

-- 
1.9.1

[Qemu-devel] [PULL for v2.3 01/01] seccomp: update libseccomp version and remove arch restriction

[Eduardo Otubo]

Libseccomp version updated to 2.2.0 and arch restriction to x86/x86_64
is now removed. It's supposed to work on armv7l as well.

Related bug: https://bugs.launchpad.net/qemu/+bug/1363641

Signed-off-by: Eduardo Otubo <eduardo.otubo@profitbricks.com>
---
 configure | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index 589798e..cbe6495 100755
--- a/configure
+++ b/configure
@@ -1848,14 +1848,13 @@ fi
 # libseccomp check
 
 if test "$seccomp" != "no" ; then
-    if test "$cpu" = "i386" || test "$cpu" = "x86_64" &&
-        $pkg_config --atleast-version=2.1.1 libseccomp; then
+    if $pkg_config --atleast-version=2.2.0 libseccomp; then
         libs_softmmu="$libs_softmmu `$pkg_config --libs libseccomp`"
         QEMU_CFLAGS="$QEMU_CFLAGS `$pkg_config --cflags libseccomp`"
 	seccomp="yes"
     else
 	if test "$seccomp" = "yes"; then
-            feature_not_found "libseccomp" "Install libseccomp devel >= 2.1.1"
+            feature_not_found "libseccomp" "Install libseccomp devel >= 2.2.0"
 	fi
 	seccomp="no"
     fi
-- 
1.9.1

Re: [Qemu-devel] [PULL for v2.3 00/01] seccomp branch queue

[Peter Maydell]

On 25 March 2015 at 10:26, Eduardo Otubo <eduardo.otubo@profitbricks.com> wrote:
> The following changes since commit 054903a832b865eb5432d79b5c9d1e1ff31b58d7:
>
>   Update version for v2.3.0-rc1 release (2015-03-24 16:34:16 +0000)
>
> are available in the git repository at:
>
>   git://github.com/otubo/qemu.git tags/pull-seccomp-20150325
>
> for you to fetch changes up to 8e27fc200457e3f2473d0069263774d4ba17bd85:
>
>   seccomp: update libseccomp version and remove arch restriction (2015-03-25 11:03:27 +0100)
>
> ----------------------------------------------------------------
> seccomp: update libseccomp version and remove arch restriction
> ----------------------------------------------------------------
> Eduardo Otubo (1):
>       seccomp: update libseccomp version and remove arch restriction
>
>  configure | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)

Applied, thanks.

-- PMM

Re: [Qemu-devel] [PULL for v2.3 01/01] seccomp: update libseccomp version and remove arch restriction

[Juan Quintela]

Eduardo Otubo <eduardo.otubo@profitbricks.com> wrote:
> Libseccomp version updated to 2.2.0 and arch restriction to x86/x86_64
> is now removed. It's supposed to work on armv7l as well.
>
> Related bug: https://bugs.launchpad.net/qemu/+bug/1363641
>
> Signed-off-by: Eduardo Otubo <eduardo.otubo@profitbricks.com>

This prevent compliation on x86_64 on Fedora 21.

(migration/next)$ make -j5 -C /scratch/tmp/next/all/
make: Entering directory '/scratch/tmp/next/all'
config-host.mak is out-of-date, running configure

ERROR: User requested feature libseccomp
       configure was not able to find it.
       Install libseccomp devel >= 2.2.0

Makefile:30: recipe for target 'config-host.mak' failed
make: *** [config-host.mak] Error 1
make: Leaving directory '/scratch/tmp/next/all'
(migration/next)$ rpm -qa | grep seccomp
libseccomp-2.1.1-5.fc21.x86_64
libseccomp-devel-2.1.1-5.fc21.x86_64
libseccomp-debuginfo-2.1.1-5.fc21.x86_64
(migration/next)$ 

This was compiling correctly until this patch got in.  And virt-test
uses seccomp by default.

Fedora 21 is less than 3 months old.  Do we really want to avoid
compilation there?

Thanks, Juan.


> ---
>  configure | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/configure b/configure
> index 589798e..cbe6495 100755
> --- a/configure
> +++ b/configure
> @@ -1848,14 +1848,13 @@ fi
>  # libseccomp check
>  
>  if test "$seccomp" != "no" ; then
> -    if test "$cpu" = "i386" || test "$cpu" = "x86_64" &&
> -        $pkg_config --atleast-version=2.1.1 libseccomp; then
> +    if $pkg_config --atleast-version=2.2.0 libseccomp; then
>          libs_softmmu="$libs_softmmu `$pkg_config --libs libseccomp`"
>          QEMU_CFLAGS="$QEMU_CFLAGS `$pkg_config --cflags libseccomp`"
>  	seccomp="yes"
>      else
>  	if test "$seccomp" = "yes"; then
> -            feature_not_found "libseccomp" "Install libseccomp devel >= 2.1.1"
> +            feature_not_found "libseccomp" "Install libseccomp devel >= 2.2.0"
>  	fi
>  	seccomp="no"
>      fi

Re: [Qemu-devel] [PULL for v2.3 01/01] seccomp: update libseccomp version and remove arch restriction

[Juan Quintela]

Juan Quintela <quintela@redhat.com> wrote:
> Eduardo Otubo <eduardo.otubo@profitbricks.com> wrote:
>> Libseccomp version updated to 2.2.0 and arch restriction to x86/x86_64
>> is now removed. It's supposed to work on armv7l as well.
>>
>> Related bug: https://bugs.launchpad.net/qemu/+bug/1363641
>>
>> Signed-off-by: Eduardo Otubo <eduardo.otubo@profitbricks.com>


Just in case anyone is interested, default virt-test output with current
qemu


15:05:01 ERROR| Qemu output:
15:05:01 ERROR| qemu-system-x86_64: -sandbox on: sandboxing request but seccomp 
is not compiled into this build
15:05:01 ERROR| 
15:05:01 ERROR| 
15:05:01 ERROR| FAIL type_specific.io-github-autotest-qemu.migrate.default.tcp -> VMStartError: VM 'virt-tests-vm1' failed to start: Qemu is defunct.
Qemu output:
qemu-system-x86_64: -sandbox on: sandboxing request but seccomp is not compiled into this build



Notice that you can "fix" the problem running with --qemu_sandbox=off,
but breaking the main test suite just before release looks wrong?

Later, Juan.

>
> This prevent compliation on x86_64 on Fedora 21.
>
> (migration/next)$ make -j5 -C /scratch/tmp/next/all/
> make: Entering directory '/scratch/tmp/next/all'
> config-host.mak is out-of-date, running configure
>
> ERROR: User requested feature libseccomp
>        configure was not able to find it.
>        Install libseccomp devel >= 2.2.0
>
> Makefile:30: recipe for target 'config-host.mak' failed
> make: *** [config-host.mak] Error 1
> make: Leaving directory '/scratch/tmp/next/all'
> (migration/next)$ rpm -qa | grep seccomp
> libseccomp-2.1.1-5.fc21.x86_64
> libseccomp-devel-2.1.1-5.fc21.x86_64
> libseccomp-debuginfo-2.1.1-5.fc21.x86_64
> (migration/next)$ 
>
> This was compiling correctly until this patch got in.  And virt-test
> uses seccomp by default.
>
> Fedora 21 is less than 3 months old.  Do we really want to avoid
> compilation there?
>
> Thanks, Juan.
>
>
>> ---
>>  configure | 5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/configure b/configure
>> index 589798e..cbe6495 100755
>> --- a/configure
>> +++ b/configure
>> @@ -1848,14 +1848,13 @@ fi
>>  # libseccomp check
>>  
>>  if test "$seccomp" != "no" ; then
>> -    if test "$cpu" = "i386" || test "$cpu" = "x86_64" &&
>> -        $pkg_config --atleast-version=2.1.1 libseccomp; then
>> +    if $pkg_config --atleast-version=2.2.0 libseccomp; then
>>          libs_softmmu="$libs_softmmu `$pkg_config --libs libseccomp`"
>>          QEMU_CFLAGS="$QEMU_CFLAGS `$pkg_config --cflags libseccomp`"
>>  	seccomp="yes"
>>      else
>>  	if test "$seccomp" = "yes"; then
>> -            feature_not_found "libseccomp" "Install libseccomp devel >= 2.1.1"
>> +            feature_not_found "libseccomp" "Install libseccomp devel >= 2.2.0"
>>  	fi
>>  	seccomp="no"
>>      fi

Re: [Qemu-devel] [PULL for v2.3 01/01] seccomp: update libseccomp version and remove arch restriction

[Peter Maydell]

On 26 March 2015 at 14:09, Juan Quintela <quintela@redhat.com> wrote:
> Notice that you can "fix" the problem running with --qemu_sandbox=off,
> but breaking the main test suite just before release looks wrong?

The main test suite is "make check" :-)

-- PMM

Re: [Qemu-devel] [PULL for v2.3 01/01] seccomp: update libseccomp version and remove arch restriction

[Eduardo Otubo]

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

On Thu, Mar 26, 2015 at 02=38=55PM +0100, Juan Quintela wrote:
> Eduardo Otubo <eduardo.otubo@profitbricks.com> wrote:
> > Libseccomp version updated to 2.2.0 and arch restriction to x86/x86_64
> > is now removed. It's supposed to work on armv7l as well.
> >
> > Related bug: https://bugs.launchpad.net/qemu/+bug/1363641
> >
> > Signed-off-by: Eduardo Otubo <eduardo.otubo@profitbricks.com>
> 
> This prevent compliation on x86_64 on Fedora 21.
> 
> (migration/next)$ make -j5 -C /scratch/tmp/next/all/
> make: Entering directory '/scratch/tmp/next/all'
> config-host.mak is out-of-date, running configure
> 
> ERROR: User requested feature libseccomp
>        configure was not able to find it.
>        Install libseccomp devel >= 2.2.0
> 
> Makefile:30: recipe for target 'config-host.mak' failed
> make: *** [config-host.mak] Error 1
> make: Leaving directory '/scratch/tmp/next/all'
> (migration/next)$ rpm -qa | grep seccomp
> libseccomp-2.1.1-5.fc21.x86_64
> libseccomp-devel-2.1.1-5.fc21.x86_64
> libseccomp-debuginfo-2.1.1-5.fc21.x86_64
> (migration/next)$ 
> 
> This was compiling correctly until this patch got in.  And virt-test
> uses seccomp by default.
> 
> Fedora 21 is less than 3 months old.  Do we really want to avoid
> compilation there?

Hello Juan,

I completely understand your concern. Perhaps a ping on libseccomp
Fedora package maintainer would be a better way to tackle this issue
instead of reverting this commit. Libseccomp 2.2.0 is released since Feb
12th and I actually gave it a little time frame for other distros to
update their packages so we don't run into issues like this.

It's important to remember that this patch is also the proper fix for
this bug: https://bugs.launchpad.net/qemu/+bug/1363641

Regards,

-- 
Eduardo Otubo
ProfitBricks GmbH

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

Re: [Qemu-devel] [PULL for v2.3 01/01] seccomp: update libseccomp version and remove arch restriction

[Eduardo Otubo]

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

On Thu, Mar 26, 2015 at 03=09=19PM +0100, Juan Quintela wrote:
> Juan Quintela <quintela@redhat.com> wrote:
> > Eduardo Otubo <eduardo.otubo@profitbricks.com> wrote:
> >> Libseccomp version updated to 2.2.0 and arch restriction to x86/x86_64
> >> is now removed. It's supposed to work on armv7l as well.
> >>
> >> Related bug: https://bugs.launchpad.net/qemu/+bug/1363641
> >>
> >> Signed-off-by: Eduardo Otubo <eduardo.otubo@profitbricks.com>
> 
> 
> Just in case anyone is interested, default virt-test output with current
> qemu
> 
> 
> 15:05:01 ERROR| Qemu output:
> 15:05:01 ERROR| qemu-system-x86_64: -sandbox on: sandboxing request but seccomp 
> is not compiled into this build
> 15:05:01 ERROR| 
> 15:05:01 ERROR| 
> 15:05:01 ERROR| FAIL type_specific.io-github-autotest-qemu.migrate.default.tcp -> VMStartError: VM 'virt-tests-vm1' failed to start: Qemu is defunct.
> Qemu output:
> qemu-system-x86_64: -sandbox on: sandboxing request but seccomp is not compiled into this build
> 
> 
> 
> Notice that you can "fix" the problem running with --qemu_sandbox=off,
> but breaking the main test suite just before release looks wrong?

Is it possible to temporarely disable this feature in your testing
environment while libseccomp is not updated?

Regards,

> 
> Later, Juan.
> 
> >
> > This prevent compliation on x86_64 on Fedora 21.
> >
> > (migration/next)$ make -j5 -C /scratch/tmp/next/all/
> > make: Entering directory '/scratch/tmp/next/all'
> > config-host.mak is out-of-date, running configure
> >
> > ERROR: User requested feature libseccomp
> >        configure was not able to find it.
> >        Install libseccomp devel >= 2.2.0
> >
> > Makefile:30: recipe for target 'config-host.mak' failed
> > make: *** [config-host.mak] Error 1
> > make: Leaving directory '/scratch/tmp/next/all'
> > (migration/next)$ rpm -qa | grep seccomp
> > libseccomp-2.1.1-5.fc21.x86_64
> > libseccomp-devel-2.1.1-5.fc21.x86_64
> > libseccomp-debuginfo-2.1.1-5.fc21.x86_64
> > (migration/next)$ 
> >
> > This was compiling correctly until this patch got in.  And virt-test
> > uses seccomp by default.
> >
> > Fedora 21 is less than 3 months old.  Do we really want to avoid
> > compilation there?
> >
> > Thanks, Juan.
> >
> >
> >> ---
> >>  configure | 5 ++---
> >>  1 file changed, 2 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/configure b/configure
> >> index 589798e..cbe6495 100755
> >> --- a/configure
> >> +++ b/configure
> >> @@ -1848,14 +1848,13 @@ fi
> >>  # libseccomp check
> >>  
> >>  if test "$seccomp" != "no" ; then
> >> -    if test "$cpu" = "i386" || test "$cpu" = "x86_64" &&
> >> -        $pkg_config --atleast-version=2.1.1 libseccomp; then
> >> +    if $pkg_config --atleast-version=2.2.0 libseccomp; then
> >>          libs_softmmu="$libs_softmmu `$pkg_config --libs libseccomp`"
> >>          QEMU_CFLAGS="$QEMU_CFLAGS `$pkg_config --cflags libseccomp`"
> >>  	seccomp="yes"
> >>      else
> >>  	if test "$seccomp" = "yes"; then
> >> -            feature_not_found "libseccomp" "Install libseccomp devel >= 2.1.1"
> >> +            feature_not_found "libseccomp" "Install libseccomp devel >= 2.2.0"
> >>  	fi
> >>  	seccomp="no"
> >>      fi

-- 
Eduardo Otubo
ProfitBricks GmbH

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

Re: [Qemu-devel] [PULL for v2.3 01/01] seccomp: update libseccomp version and remove arch restriction

[Peter Maydell]

On 26 March 2015 at 14:37, Eduardo Otubo <eduardo.otubo@profitbricks.com> wrote:
> I completely understand your concern. Perhaps a ping on libseccomp
> Fedora package maintainer would be a better way to tackle this issue
> instead of reverting this commit. Libseccomp 2.2.0 is released since Feb
> 12th and I actually gave it a little time frame for other distros to
> update their packages so we don't run into issues like this.

Well, we shouldn't really be mandating latest-and-greatest versions
of our upstream dependencies unless the maintainer of those dependencies
feels the earlier versions are so badly broken that it would be better
to refuse to use them at all.

> It's important to remember that this patch is also the proper fix for
> this bug: https://bugs.launchpad.net/qemu/+bug/1363641

If that only applies to certain architectures we can make the
dependency version vary depending on which arch we're building
for, I suppose.

-- PMM

Re: [Qemu-devel] [PULL for v2.3 01/01] seccomp: update libseccomp version and remove arch restriction

[Juan Quintela]

Peter Maydell <peter.maydell@linaro.org> wrote:
> On 26 March 2015 at 14:37, Eduardo Otubo <eduardo.otubo@profitbricks.com> wrote:
>> I completely understand your concern. Perhaps a ping on libseccomp
>> Fedora package maintainer would be a better way to tackle this issue
>> instead of reverting this commit. Libseccomp 2.2.0 is released since Feb
>> 12th and I actually gave it a little time frame for other distros to
>> update their packages so we don't run into issues like this.
>
> Well, we shouldn't really be mandating latest-and-greatest versions
> of our upstream dependencies unless the maintainer of those dependencies
> feels the earlier versions are so badly broken that it would be better
> to refuse to use them at all.

+1

>> It's important to remember that this patch is also the proper fix for
>> this bug: https://bugs.launchpad.net/qemu/+bug/1363641
>
> If that only applies to certain architectures we can make the
> dependency version vary depending on which arch we're building
> for, I suppose.

I will go for this.

My concern is that virt-test will stop working until distributins gets
updated.  I can update it myself, or running with --qemu_sandbox=off,
that is what I just did for the pull request just sent.  But I feel bad
that people on recent distributions are not able to use important
features.

Thanks, Juan.

Re: [Qemu-devel] [PULL for v2.3 01/01] seccomp: update libseccomp version and remove arch restriction

[Peter Maydell]

On 26 March 2015 at 14:37, Eduardo Otubo <eduardo.otubo@profitbricks.com> wrote:
> Libseccomp 2.2.0 is released since Feb
> 12th and I actually gave it a little time frame for other distros to
> update their packages so we don't run into issues like this.

Incidentally, "about two months" is actually a very short
time between upstream-release and mandating it for QEMU.
Consider that our glib dependency is 2.12, which was released
in 2006, and we're still debating whether to move forward
to 2.24 (released in 2010). Distro release schedules are
often on a scale of years, especially for long-term-support
distros, and we want to support as wide a range of them
as we reasonably can.

-- PMM

Re: [Qemu-devel] [PULL for v2.3 01/01] seccomp: update libseccomp version and remove arch restriction

[Eduardo Otubo]

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

On Thu, Mar 26, 2015 at 02=44=14PM +0000, Peter Maydell wrote:
> On 26 March 2015 at 14:37, Eduardo Otubo <eduardo.otubo@profitbricks.com> wrote:
> > I completely understand your concern. Perhaps a ping on libseccomp
> > Fedora package maintainer would be a better way to tackle this issue
> > instead of reverting this commit. Libseccomp 2.2.0 is released since Feb
> > 12th and I actually gave it a little time frame for other distros to
> > update their packages so we don't run into issues like this.
> 
> Well, we shouldn't really be mandating latest-and-greatest versions
> of our upstream dependencies unless the maintainer of those dependencies
> feels the earlier versions are so badly broken that it would be better
> to refuse to use them at all.
> 
> > It's important to remember that this patch is also the proper fix for
> > this bug: https://bugs.launchpad.net/qemu/+bug/1363641
> 
> If that only applies to certain architectures we can make the
> dependency version vary depending on which arch we're building
> for, I suppose.
> 

This sounds more like a reasonable approach that could solve the above
mentioned problem and also making virt-test to be able to keep using
this feature as well -- which is also very important in order to get
more important system calls for the whitelist. I'll roll out a new patch
for that.

Thanks for the idea, Paul.
Sorry for the trouble on your side, Juan.

Regards,

-- 
Eduardo Otubo
ProfitBricks GmbH

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

Re: [Qemu-devel] [PULL for v2.3 01/01] seccomp: update libseccomp version and remove arch restriction

[Juan Quintela]

Eduardo Otubo <eduardo.otubo@profitbricks.com> wrote:
> On Thu, Mar 26, 2015 at 02=44=14PM +0000, Peter Maydell wrote:
>> On 26 March 2015 at 14:37, Eduardo Otubo <eduardo.otubo@profitbricks.com> wrote:
>> > I completely understand your concern. Perhaps a ping on libseccomp
>> > Fedora package maintainer would be a better way to tackle this issue
>> > instead of reverting this commit. Libseccomp 2.2.0 is released since Feb
>> > 12th and I actually gave it a little time frame for other distros to
>> > update their packages so we don't run into issues like this.
>> 
>> Well, we shouldn't really be mandating latest-and-greatest versions
>> of our upstream dependencies unless the maintainer of those dependencies
>> feels the earlier versions are so badly broken that it would be better
>> to refuse to use them at all.
>> 
>> > It's important to remember that this patch is also the proper fix for
>> > this bug: https://bugs.launchpad.net/qemu/+bug/1363641
>> 
>> If that only applies to certain architectures we can make the
>> dependency version vary depending on which arch we're building
>> for, I suppose.
>> 
>
> This sounds more like a reasonable approach that could solve the above
> mentioned problem and also making virt-test to be able to keep using
> this feature as well -- which is also very important in order to get
> more important system calls for the whitelist. I'll roll out a new patch
> for that.
>
> Thanks for the idea, Paul.
> Sorry for the trouble on your side, Juan.

You are welcome.  I was just trying to fix the prob0lem before somebody
else hit it O:-)

Later, Juan.