From: Paul Moore <pmoore@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Marcus Meissner" <meissner@suse.de>,
"Karl-Philipp Richter" <krichter722@aol.de>,
"Riku Voipio" <riku.voipio@iki.fi>,
"Alexander Graf" <agraf@suse.de>,
qemu-devel <qemu-devel@nongnu.org>,
qemu-ppc <qemu-ppc@nongnu.org>,
"Eduardo Otubo" <eduardo.otubo@profitbricks.com>,
"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] seccomp breakage on arm
Date: Thu, 09 Apr 2015 19:46:51 -0400 [thread overview]
Message-ID: <2186908.62XuPTZaqu@sifl> (raw)
In-Reply-To: <CAFEAcA-OV4N_4x7O+wM9iC3S=D-u5PjW4zgnzOKMye-zue6VVg@mail.gmail.com>
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
next prev parent reply other threads:[~2015-04-09 23:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-09 3:01 [Qemu-devel] seccomp breakage on arm Andreas Färber
2015-04-09 8:21 ` Eduardo Otubo
2015-04-09 9:10 ` Paul Moore
2015-04-09 12:28 ` Andreas Färber
2015-04-09 21:27 ` Paul Moore
2015-04-09 22:32 ` Peter Maydell
2015-04-09 23:46 ` Paul Moore [this message]
2015-04-10 12:44 ` Peter Maydell
2015-04-10 15:16 ` Paul Moore
2015-04-10 15:38 ` Peter Maydell
2015-04-10 15:40 ` Andreas Färber
2015-04-10 22:56 ` Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2186908.62XuPTZaqu@sifl \
--to=pmoore@redhat.com \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=eduardo.otubo@profitbricks.com \
--cc=krichter722@aol.de \
--cc=meissner@suse.de \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=riku.voipio@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).