[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] seccomp: change configure to avoid arm 32 to br
From: |
Paul Moore |
Subject: |
Re: [Qemu-devel] [PATCH] seccomp: change configure to avoid arm 32 to break |
Date: |
Wed, 05 Nov 2014 15:35:09 -0500 |
User-agent: |
KMail/4.14.2 (Linux/3.16.7-gentoo; KDE/4.14.2; x86_64; ; ) |
On Wednesday, November 05, 2014 08:08:06 PM Peter Maydell wrote:
> On 5 November 2014 19:46, Paul Moore <address@hidden> wrote:
> > On Wednesday, November 05, 2014 05:08:20 PM Peter Maydell wrote:
> >> On 5 November 2014 16:47, Eduardo Otubo wrote:
> >> > Right now seccomp is breaking the compilation of Qemu on armv7l due
> >> > to libsecomp current lack of support for this arch. This problem is
> >> > already fixed on libseccomp upstream but no release date for that is
> >> > scheduled to far. This patch disables support for seccomp on armv7l
> >> > temporarily until libseccomp does a new release. Then I'll remove the
> >> > hack and update libseccomp dependency on configure script.
> >> >
> >> > Related bug: https://bugs.launchpad.net/qemu/+bug/1363641
> >
> > ...
> >
> >> (How are upstream proposing to fix this anyway? I couldn't
> >> figure that out from the mailing list thread.)
> >
> > The problem was that the released version of libseccomp has some "holes"
> > in
> > the internal syscall table for 32-bit ARM with respect to all of the other
> > supported architectures. The current libseccomp upstream has some
> > additional tooling and checks to ensure that the different ABI syscall
> > tables are kept in sync to prevent something like this from happening in
> > the future.
>
> OK. So should we make QEMU say "if x86_64 or i386, require
> seccomp 2.1 or better, else require 2.2 or better"?
I would probably just limit QEMU/seccomp to x86_64 and x86. Once we have the
new release that fixes everything we can start worrying about versions and
different ABIs.
> If our current source will build with seccomp 2.2 then that seems like a
> better check to put in our configure script than a simple disabling of
> the functionality on ARM hosts; it means that if distros end up
> with QEMU 2.2 plus seccomp 2.2 the functionality won't be
> unnecessarily disabled. (Please correct me if I have your
> next-release numbering wrong!)
Well, technically we don't have libseccomp v2.2 yet so I can't say for certain
what it will look like and how it will behave.
> > I'm more than happy to discuss how libseccomp handles the different
> > architectures, but that's probably a bit off-topic for this thread.
>
> I guess the only thing that matters for us is that there wasn't
> an API break required for the fix.
Nope, the API is solid, just some internal fixes.
--
paul moore
security and virtualization @ redhat