| Message ID | 20190403124948.GA14129@ls3530.dellerweb.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | configure: Relax check for libseccomp | expand |
On Wed, 3 Apr 2019 at 19:51, Helge Deller <deller@gmx.de> wrote: [cc'ing Eduardo as the seccomp submaintainer] > On a non-release architecture, the configure program aborts if the > --enable-seccomp flag was given (with no way to work around it on the > command line): > > ERROR: User requested feature libseccomp > configure was not able to find it. > libseccomp is not supported for host cpu parisc64 Surely the workaround is "don't pass --enable-seccomp on the configure command line" ? Our general approach with configure arguments is: --disable-foo means "don't try to look for or use foo" --enable-foo means "use foo, and stop with an error if we can't use foo for any reason (eg not found, version too old)" passing nothing means "look for foo, use it if we can, but if we can't then just silently don't use foo" So I think if the user specifically asks us to use seccomp on a host architecture where it won't work then configure should fail. Is the underlying problem here: * we use a whitelist of host architectures to enable seccomp for and we should not do that (eg blacklist instead, or just allow it for any host architecture)? * using a whitelist is ok, but we should add some more host archs to it? * something else? What particular host arch are you using? thanks -- PMM
On Wed, 3 Apr 2019 at 22:16, Peter Maydell <peter.maydell@linaro.org> wrote: > > On Wed, 3 Apr 2019 at 19:51, Helge Deller <deller@gmx.de> wrote: > > [cc'ing Eduardo as the seccomp submaintainer] > > > On a non-release architecture, the configure program aborts if the > > --enable-seccomp flag was given (with no way to work around it on the > > command line): > > > > ERROR: User requested feature libseccomp > > configure was not able to find it. > > libseccomp is not supported for host cpu parisc64 > What particular host arch are you using? Doh, just noticed that the error message has the answer to this! thanks - PMM
On 03.04.19 17:16, Peter Maydell wrote: > On Wed, 3 Apr 2019 at 19:51, Helge Deller <deller@gmx.de> wrote: > > [cc'ing Eduardo as the seccomp submaintainer] > >> On a non-release architecture, the configure program aborts if the >> --enable-seccomp flag was given (with no way to work around it on the >> command line): >> >> ERROR: User requested feature libseccomp >> configure was not able to find it. >> libseccomp is not supported for host cpu parisc64 > > Surely the workaround is "don't pass --enable-seccomp on > the configure command line" ? Sure, that's the easy solution but doesn't work for me. The only reason why I come up with this patch, is that on Debian the qemu package fails to build on parisc because of this issue, as can be seen here: https://buildd.debian.org/status/logs.php?pkg=qemu&arch=hppa Debian sets the -enable-seccomp flags, so it fails on parisc (already in the qemu 1.3 release). > Our general approach with configure arguments is: > --disable-foo means "don't try to look for or use foo" > --enable-foo means "use foo, and stop with an error if we can't use > foo for any reason (eg not found, version too old)" Yes, that's OK. > passing nothing means "look for foo, use it if we can, > but if we can't then just silently don't use foo" > > So I think if the user specifically asks us to use seccomp on a > host architecture where it won't work then configure should fail. True, it should fail if it's not useable. But In my case, latest libseccomp is avaialble & functional, but nevertheless configure fails because parisc is not in the white list. > Is the underlying problem here: > * we use a whitelist of host architectures to enable seccomp for > and we should not do that (eg blacklist instead, or just allow it > for any host architecture)? Yes, that's one option. My patch partly does that by allowing -enble-seccomp as long as a libseccomp package is found. > * using a whitelist is ok, but we should add some more host archs to it? I think for non-release architectures there is no need to be too strict. If something is available, just use it, independend of the architecture. This solves it not just for parisc... I'm fine with any solution as long as it works :-) > What particular host arch are you using? You already found out in your other mail: hppa/parisc. Helge
On Wed, Apr 03, 2019 at 02:49:48PM +0200, Helge Deller wrote: > On a non-release architecture, the configure program aborts if the > --enable-seccomp flag was given (with no way to work around it on the > command line): > > ERROR: User requested feature libseccomp > configure was not able to find it. > libseccomp is not supported for host cpu parisc64 > > Instead of aborting, fall back to require libseccomp version 2.2.0 > (or any higher version currently installed) which should be OK for > non-release architectures. > > Signed-off-by: Helge Deller <deller@gmx.de> > > diff --git a/configure b/configure > index 1c563a7027..8632267049 100755 > --- a/configure > +++ b/configure > @@ -2389,7 +2389,6 @@ if test "$seccomp" != "no" ; then > libseccomp_minver="2.3.0" > ;; > *) > - libseccomp_minver="" > ;; > esac This makes sense to me. From a QEMU source POV we are able to build with libseccomp >= 2.2.0, which our default libseccomp_minver= env expresses a few lines earlier. If libseccomp isn't supported on a platform, then I think we should just assume that libseccomp won't be present in the OS install we are building against. I don't think QEMU needs to second-guess whether or not it is supported on the given architecture. In fact I'd go as far as to say we could probably just remove all this per-arch checking and just have a generic >= 2.2.0 check, and just rely on fact libseccomp won't exist on a s390/ppc/etc host if the distro had version < 2.3.0 Anyway, this particular patch is better than what we have so on that basis I think we can just apply this as-is: Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Regards, Daniel
CCing the right Eduardo. :) On Wed, Apr 03, 2019 at 10:16:15PM +0700, Peter Maydell wrote: > On Wed, 3 Apr 2019 at 19:51, Helge Deller <deller@gmx.de> wrote: > > [cc'ing Eduardo as the seccomp submaintainer] > > > On a non-release architecture, the configure program aborts if the > > --enable-seccomp flag was given (with no way to work around it on the > > command line): > > > > ERROR: User requested feature libseccomp > > configure was not able to find it. > > libseccomp is not supported for host cpu parisc64 > > Surely the workaround is "don't pass --enable-seccomp on > the configure command line" ? > > Our general approach with configure arguments is: > --disable-foo means "don't try to look for or use foo" > --enable-foo means "use foo, and stop with an error if we can't use > foo for any reason (eg not found, version too old)" > passing nothing means "look for foo, use it if we can, > but if we can't then just silently don't use foo" > > So I think if the user specifically asks us to use seccomp on a > host architecture where it won't work then configure should fail. > > Is the underlying problem here: > * we use a whitelist of host architectures to enable seccomp for > and we should not do that (eg blacklist instead, or just allow it > for any host architecture)? > * using a whitelist is ok, but we should add some more host archs to it? > * something else? > > What particular host arch are you using? > > thanks > -- PMM
On Thu, 4 Apr 2019 at 04:05, Eduardo Habkost <ehabkost@redhat.com> wrote: > > > CCing the right Eduardo. :) Oops, sorry! Can I blame my email client's autocompletion? :-) -- PMM
On Wed, 3 Apr 2019 at 23:27, Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Wed, Apr 03, 2019 at 02:49:48PM +0200, Helge Deller wrote: > > diff --git a/configure b/configure > > index 1c563a7027..8632267049 100755 > > --- a/configure > > +++ b/configure > > @@ -2389,7 +2389,6 @@ if test "$seccomp" != "no" ; then > > libseccomp_minver="2.3.0" > > ;; > > *) > > - libseccomp_minver="" > > ;; > > esac > > This makes sense to me. From a QEMU source POV we are able to build with > libseccomp >= 2.2.0, which our default libseccomp_minver= env expresses > a few lines earlier. > > If libseccomp isn't supported on a platform, then I think we should just > assume that libseccomp won't be present in the OS install we are building > against. I don't think QEMU needs to second-guess whether or not it is > supported on the given architecture. If we want to do this then we should handle all the archs which don't need to special case the seccomp version identically, ie remove the x86/mips case which with this patch would be the same as the default case. > In fact I'd go as far as to say we > could probably just remove all this per-arch checking and just have a > generic >= 2.2.0 check, and just rely on fact libseccomp won't exist > on a s390/ppc/etc host if the distro had version < 2.3.0 The arm case at least is present because libseccomp 2.2.0 was being built but didn't actually work for us. See commit ae6e8ef11e6cb43ec83. thanks -- PMM
On 04/04/2019 03.53, Peter Maydell wrote: > On Wed, 3 Apr 2019 at 23:27, Daniel P. Berrangé <berrange@redhat.com> wrote: >> >> On Wed, Apr 03, 2019 at 02:49:48PM +0200, Helge Deller wrote: >>> diff --git a/configure b/configure >>> index 1c563a7027..8632267049 100755 >>> --- a/configure >>> +++ b/configure >>> @@ -2389,7 +2389,6 @@ if test "$seccomp" != "no" ; then >>> libseccomp_minver="2.3.0" >>> ;; >>> *) >>> - libseccomp_minver="" >>> ;; >>> esac >> >> This makes sense to me. From a QEMU source POV we are able to build with >> libseccomp >= 2.2.0, which our default libseccomp_minver= env expresses >> a few lines earlier. >> >> If libseccomp isn't supported on a platform, then I think we should just >> assume that libseccomp won't be present in the OS install we are building >> against. I don't think QEMU needs to second-guess whether or not it is >> supported on the given architecture. > > If we want to do this then we should handle all the archs which > don't need to special case the seccomp version identically, ie > remove the x86/mips case which with this patch would be the > same as the default case. > >> In fact I'd go as far as to say we >> could probably just remove all this per-arch checking and just have a >> generic >= 2.2.0 check, and just rely on fact libseccomp won't exist >> on a s390/ppc/etc host if the distro had version < 2.3.0 > > The arm case at least is present because libseccomp 2.2.0 was > being built but didn't actually work for us. See commit ae6e8ef11e6cb43ec83. Looking at https://repology.org/project/libseccomp/versions it seems like all major distro versions that we want to support feature at least version 2.3.0 ... so I think we can simplify the check here for all architectures and only test for a version >= 2.3.0. Thomas
On Thu, Apr 04, 2019 at 08:59:14AM +0200, Thomas Huth wrote: > On 04/04/2019 03.53, Peter Maydell wrote: > > On Wed, 3 Apr 2019 at 23:27, Daniel P. Berrangé <berrange@redhat.com> wrote: > >> > >> On Wed, Apr 03, 2019 at 02:49:48PM +0200, Helge Deller wrote: > >>> diff --git a/configure b/configure > >>> index 1c563a7027..8632267049 100755 > >>> --- a/configure > >>> +++ b/configure > >>> @@ -2389,7 +2389,6 @@ if test "$seccomp" != "no" ; then > >>> libseccomp_minver="2.3.0" > >>> ;; > >>> *) > >>> - libseccomp_minver="" > >>> ;; > >>> esac > >> > >> This makes sense to me. From a QEMU source POV we are able to build with > >> libseccomp >= 2.2.0, which our default libseccomp_minver= env expresses > >> a few lines earlier. > >> > >> If libseccomp isn't supported on a platform, then I think we should just > >> assume that libseccomp won't be present in the OS install we are building > >> against. I don't think QEMU needs to second-guess whether or not it is > >> supported on the given architecture. > > > > If we want to do this then we should handle all the archs which > > don't need to special case the seccomp version identically, ie > > remove the x86/mips case which with this patch would be the > > same as the default case. > > > >> In fact I'd go as far as to say we > >> could probably just remove all this per-arch checking and just have a > >> generic >= 2.2.0 check, and just rely on fact libseccomp won't exist > >> on a s390/ppc/etc host if the distro had version < 2.3.0 > > > > The arm case at least is present because libseccomp 2.2.0 was > > being built but didn't actually work for us. See commit ae6e8ef11e6cb43ec83. > > Looking at https://repology.org/project/libseccomp/versions it seems > like all major distro versions that we want to support feature at least > version 2.3.0 ... so I think we can simplify the check here for all > architectures and only test for a version >= 2.3.0. That sounds good to me. Regards, Daniel
diff --git a/configure b/configure index 1c563a7027..8632267049 100755 --- a/configure +++ b/configure @@ -2389,7 +2389,6 @@ if test "$seccomp" != "no" ; then libseccomp_minver="2.3.0" ;; *) - libseccomp_minver="" ;; esac
On a non-release architecture, the configure program aborts if the --enable-seccomp flag was given (with no way to work around it on the command line): ERROR: User requested feature libseccomp configure was not able to find it. libseccomp is not supported for host cpu parisc64 Instead of aborting, fall back to require libseccomp version 2.2.0 (or any higher version currently installed) which should be OK for non-release architectures. Signed-off-by: Helge Deller <deller@gmx.de>