qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] seccomp: remove unused syscalls - for 1.6


From: Paul Moore
Subject: Re: [Qemu-devel] seccomp: remove unused syscalls - for 1.6
Date: Thu, 18 Jul 2013 15:39:14 -0400
User-agent: KMail/4.10.5 (Linux/3.9.5-gentoo; KDE/4.10.5; x86_64; ; )

On Thursday, July 18, 2013 06:37:15 PM Paolo Bonzini wrote:
> Il 18/07/2013 18:35, Eduardo Otubo ha scritto:
> > On 07/18/2013 01:28 PM, Anthony Liguori wrote:
> >> Eduardo Otubo <address@hidden> writes:
> >>> Hello all,
> >> 
> >>> In this small patch series I basically:
> >> Cover letter should be marked [PATCH 0/2].  Otherwise it defeats
> >> filtering.
> >> 
> >> Would like to see a Reviewed-by from someone before applying this.
> > 
> > I'm running some tests with qemu && xen, I'll post a v3 by the end of
> > the day. I'll format the cover letter in the correct way next time.
> 
> I feel that, at some point, grep and code review must trump experiments...
> 
> Paul, how did you guys handle this in other projects?

To the best of my knowledge QEMU currently stands alone with its complexity 
and use of seccomp filtering.  There are other applications, but they are 
either of the syscall sandboxing type where the users define the filters, or 
the rigid, smaller, well defined filter type.  QEMU is both large and has a 
huge number of options which affect the syscalls used.

At some point it would be nice to develop a mechanism to do some static 
analysis on a binary and its associated libraries to come up with a worst case 
filter (worst case because you might not want all the syscalls that a library 
uses, e.g. glibc).  Unfortunately, we don't have such a tool the moment - it's 
hard enough generating correct filters with a nice architecture agnostic 
manner :)

On the plus side, I think libseccomp is very close to being pretty much 
feature complete (excluding new architectures that may pop up, at present we 
are only x86, x86_64, x32, and ARM) so I'll be able to start turning some 
effort towards better tools and patches for existing applications.

-- 
paul moore
security and virtualization @ redhat




reply via email to

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