All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <pmoore@redhat.com>
To: Eduardo Otubo <otubo@linux.vnet.ibm.com>
Cc: qemu-devel@nongnu.org, Eric Paris <eparis@redhat.com>
Subject: Re: [Qemu-devel] [RFC] Continuous work on sandboxing
Date: Mon, 29 Apr 2013 15:24:15 -0400	[thread overview]
Message-ID: <1752415.n4lqG2Muub@sifl> (raw)
In-Reply-To: <517EBE7D.4020100@linux.vnet.ibm.com>

On Monday, April 29, 2013 03:39:57 PM Eduardo Otubo wrote:
> On 04/26/2013 06:07 PM, Paul Moore wrote:
> > On Friday, April 26, 2013 03:39:33 PM Eduardo Otubo wrote:
> > Also, looking a bit further ahead, it might be interesting to look at
> > removing some of the arch dependent stuff in qemu-seccomp.c.  The latest
> > version of libseccomp should remove the need for many, if not all, of the
> > arch specific #ifdefs and the next version of libseccomp will add support
> > for x32 and ARM.
>
> Tell me more about this. You're saying I can remove the #ifdefs and keep
> the lines like "{ SCMP_SYS(getresuid32), 241 }, " or address these
> syscalls in another way?

Yes.  If you are using libseccomp 2.x you shouldn't need any of the #ifdefs in 
the seccomp_whitelist[] variable like there are at present.  As long as you 
aren't using the *_exact() versions of the libseccomp APIs, which QEMU is not, 
the library will do the right thing for the current architecture: syscalls 
that don't exist will be ignored, those that need translation, e.g. socket() 
on x86, will be translated, and those that do exist normally will be handled 
normally.  Anything else I would consider a bug in libseccomp.

There is more to it if you are generating a seccomp filter to support multiple 
simultaneous architectures, e.g. x86 and x86_64, but that doesn't really apply 
with QEMU.

-- 
paul moore
security and virtualization @ redhat

  reply	other threads:[~2013-04-29 19:24 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-26 18:39 [Qemu-devel] [RFC] Continuous work on sandboxing Eduardo Otubo
2013-04-26 21:07 ` Paul Moore
2013-04-26 22:17   ` Paolo Bonzini
2013-04-29 19:57     ` Eduardo Otubo
2013-04-29 21:06       ` Paolo Bonzini
2013-04-29 18:39   ` Eduardo Otubo
2013-04-29 19:24     ` Paul Moore [this message]
2013-04-29 22:02     ` Corey Bryant
2013-04-30 18:47       ` Eduardo Otubo
2013-04-30 20:28         ` Corey Bryant
2013-05-01 14:13           ` Paul Moore
2013-05-01 15:30             ` Corey Bryant
2013-04-29 21:52   ` Corey Bryant
2013-04-30 15:24     ` Paul Moore
2013-05-01 17:25       ` Eduardo Otubo
2013-05-01 18:04         ` Corey Bryant

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=1752415.n4lqG2Muub@sifl \
    --to=pmoore@redhat.com \
    --cc=eparis@redhat.com \
    --cc=otubo@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /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.