qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Continuous work on sandboxing


From: Paul Moore
Subject: Re: [Qemu-devel] [RFC] Continuous work on sandboxing
Date: Mon, 29 Apr 2013 15:24:15 -0400
User-agent: KMail/4.10.2 (Linux/3.8.5-gentoo; KDE/4.10.2; x86_64; ; )

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 via email to

[Prev in Thread] Current Thread [Next in Thread]