From: Paul Moore <pmoore@redhat.com>
To: Andrew Jones <drjones@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Marcus Meissner" <meissner@suse.de>,
"Eduardo Otubo" <eduardo.otubo@profitbricks.com>,
"Patch Tracking" <patches@linaro.org>,
"Riku Voipio" <riku.voipio@iki.fi>,
"Alexander Graf" <agraf@suse.de>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Karl-Philipp Richter" <krichter722@aol.de>,
"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH for-2.3] Revert seccomp tests that allow it to be used on non-x86 architectures
Date: Tue, 30 Jun 2015 13:01:29 -0400 [thread overview]
Message-ID: <2877592.aNXnatIRsp@sifl> (raw)
In-Reply-To: <20150630083934.GA3016@hawk.localdomain>
On Tuesday, June 30, 2015 10:39:34 AM Andrew Jones wrote:
> On Mon, Jun 29, 2015 at 04:24:55PM -0400, Paul Moore wrote:
> > Hmm, so either the kernel is screwing up with the seccomp filter for this
> > particular syscall (unlikely) or libseccomp is screwing up the filter
> > creation (more likely). I don't have an ARM system handy at the moment,
> > but could you use the seccomp_export_pfc() and seccomp_export_bpf()
> > functions to dump the PFC/BPF filter code to a file and send it out?
>
> Attached
Thanks.
> I looked at the pfc file and compared all the syscalls in it vs. the list
> in qemu-seccomp.c. The pfc file is missing cacheflush, and has an 'UNKNOWN'
> instead.
Yeah, the associated syscall number is showing -10104 which is the pseudo
syscall number for architectures that don't support cacheflush(). That is
obviously wrong
> Also, I think there may be another problem with the filter (or pfc)
> generation. Several of the syscalls have weird syscall numbers. For
> example, I would expect mmap to be 90, but instead it's -10181.
That is intentional. According to the Linux kernel sources mmap() isn't
defined for 32-bit ARM EABI so you are seeing libseccomp's pseudo syscall
number for mmap().
> And, since there was something weird, and not related to cacheflush, in the
> arm32 pfc, I decided to check it on my mustang too. The output there gets
> "cacheflush" for the name instead of UNKNOWN, but has the same weird
> number (-10104) that the midway has. It also has several other weird
> numbers. The output from the mustang is in the attached tarball as well.
I would expect aarch64 to have a pseudo syscall number for cacheflush() as
that syscall isn't defined for 64-bit ARM. What I don't understand is why
libseccomp doesn't recognize cacheflush() in this particular case.
I'm starting to wonder if the 32-bit ARM build system didn't have
__NR_cacheflush defined in the system headers; that might explain some of the
behavior. Could you check your system to see if it has __NR_cacheflush
defined (try /usr/include/asm/unistd.h)? If it does, could you try rebuilding
the libseccomp package on your system and seeing if it resolves the problem?
--
paul moore
security @ redhat
next prev parent reply other threads:[~2015-06-30 17:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-10 12:58 [Qemu-devel] [PATCH for-2.3] Revert seccomp tests that allow it to be used on non-x86 architectures Peter Maydell
2015-06-16 13:12 ` Andrew Jones
2015-06-16 13:16 ` Peter Maydell
2015-06-26 16:03 ` Andrew Jones
2015-06-26 20:26 ` Paul Moore
2015-06-29 7:50 ` Andrew Jones
2015-06-29 14:53 ` Paul Moore
2015-06-29 17:47 ` Andrew Jones
2015-06-29 20:24 ` Paul Moore
2015-06-30 8:39 ` Andrew Jones
2015-06-30 17:01 ` Paul Moore [this message]
2015-06-30 17:07 ` Peter Maydell
2015-06-30 17:18 ` Paul Moore
2015-07-01 12:07 ` Andrew Jones
2015-07-01 17:08 ` 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=2877592.aNXnatIRsp@sifl \
--to=pmoore@redhat.com \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=drjones@redhat.com \
--cc=eduardo.otubo@profitbricks.com \
--cc=krichter722@aol.de \
--cc=meissner@suse.de \
--cc=patches@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.