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

2013-07-15 Thread Eduardo Otubo
Hello all,

In this small patch series I basically:

1) Remove the ifdef's for the (not so) new libseccomp version that does 
a
  best effort and translates x86_32 syscalls into x86_64 when possible.

  2) Remove unused syscalls on the seccomp whitelist. For that removal, I've 
been
  running several instances of Qemu using a script written on top of
  virt-test[0]. After some weeks testing I could come up with this small list,
  and safely remove them without breaking anything.

[0] - https://github.com/autotest/virt-test/wiki

GIT: [PATCH 1/2] seccomp: no need to check arch in syscall whitelist
GIT: [PATCH 2/2] seccomp: removing unused syscalls gtom whitelist




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

2013-07-15 Thread Eduardo Otubo
Hello all,

In this small patch series I basically:

1) Remove the ifdef's for the (not so) new libseccomp version that does 
a
  best effort and translates x86_32 syscalls into x86_64 when possible.

  2) Remove unused syscalls on the seccomp whitelist. For that removal, I've 
been
  running several instances of Qemu using a script written on top of
  virt-test[0]. After some weeks testing I could come up with this small list,
  and safely remove them without breaking anything.

[0] - https://github.com/autotest/virt-test/wiki




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

2013-07-16 Thread Eduardo Otubo
Hello all,

In this small patch series I basically:

  v2 update:
  - set libseccomp 2.1.0 as requirement on configure script.
  - removed setrlimit and added sendfile64 to the whitelist.

1) Remove the ifdef's for the (not so) new libseccomp version that does 
a
  best effort and translates x86_32 syscalls into x86_64 when possible.

  2) Remove unused syscalls on the seccomp whitelist. For that removal, I've 
been
  running several instances of Qemu using a script written on top of
  virt-test[0]. After some weeks testing I could come up with this small list,
  and safely remove them without breaking anything.

[0] - https://github.com/autotest/virt-test/wiki




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

2013-07-18 Thread Anthony Liguori
Eduardo Otubo  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.

Regards,

Anthony Liguori

>
>   v2 update:
>   - set libseccomp 2.1.0 as requirement on configure script.
>   - removed setrlimit and added sendfile64 to the whitelist.
>
>   1) Remove the ifdef's for the (not so) new libseccomp version that does 
> a
>   best effort and translates x86_32 syscalls into x86_64 when possible.
>
>   2) Remove unused syscalls on the seccomp whitelist. For that removal, I've 
> been
>   running several instances of Qemu using a script written on top of
>   virt-test[0]. After some weeks testing I could come up with this small list,
>   and safely remove them without breaking anything.
>
> [0] - https://github.com/autotest/virt-test/wiki



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

2013-07-18 Thread Eduardo Otubo



On 07/18/2013 01:28 PM, Anthony Liguori wrote:

Eduardo Otubo  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.


Thanks,



Regards,

Anthony Liguori



   v2 update:
   - set libseccomp 2.1.0 as requirement on configure script.
   - removed setrlimit and added sendfile64 to the whitelist.

1) Remove the ifdef's for the (not so) new libseccomp version that does 
a
   best effort and translates x86_32 syscalls into x86_64 when possible.

   2) Remove unused syscalls on the seccomp whitelist. For that removal, I've 
been
   running several instances of Qemu using a script written on top of
   virt-test[0]. After some weeks testing I could come up with this small list,
   and safely remove them without breaking anything.

[0] - https://github.com/autotest/virt-test/wiki




--
Eduardo Otubo
IBM Linux Technology Center




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

2013-07-18 Thread Paolo Bonzini
Il 18/07/2013 18:35, Eduardo Otubo ha scritto:
> 
> 
> On 07/18/2013 01:28 PM, Anthony Liguori wrote:
>> Eduardo Otubo  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?

Paolo




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

2013-07-18 Thread Paul Moore
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  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




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

2013-07-18 Thread Peter Maydell
On 18 July 2013 20:39, Paul Moore  wrote:
> 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)

...AArch64 ? :-)

-- PMM



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

2013-07-18 Thread Paul Moore
On Thursday, July 18, 2013 08:48:10 PM Peter Maydell wrote:
> On 18 July 2013 20:39, Paul Moore  wrote:
> > 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)
> 
> ...AArch64 ? :-)
> 

Not yet, just 32-bit ARM EABI.

If you've got a working system and are willing to so some hacking or run some 
tests we could work on it for a future libseccomp release.  An emulated 
AArch64 VM would also work, but that route can be slow/annoying.

-- 
paul moore
security and virtualization @ redhat




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

2013-07-18 Thread Peter Maydell
On 18 July 2013 21:05, Paul Moore  wrote:
> On Thursday, July 18, 2013 08:48:10 PM Peter Maydell wrote:
>> On 18 July 2013 20:39, Paul Moore  wrote:
>> > 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)
>>
>> ...AArch64 ? :-)
>>
>
> Not yet, just 32-bit ARM EABI.
>
> If you've got a working system and are willing to so some hacking or run some
> tests we could work on it for a future libseccomp release.  An emulated
> AArch64 VM would also work, but that route can be slow/annoying.

Simulators are all we have right now (we're juuust getting to the
point where hardware is starting to become available). I wasn't
being serious really, though I'm sure somebody (possibly even
somebody at Red Hat :-)) will work around to it at some point.

-- PMM



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

2013-07-18 Thread Paul Moore
On Thursday, July 18, 2013 10:31:46 PM Peter Maydell wrote:
> On 18 July 2013 21:05, Paul Moore  wrote:
> > On Thursday, July 18, 2013 08:48:10 PM Peter Maydell wrote:
> >> On 18 July 2013 20:39, Paul Moore  wrote:
> >> > 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)
> >> 
> >> ...AArch64 ? :-)
> > 
> > Not yet, just 32-bit ARM EABI.
> > 
> > If you've got a working system and are willing to so some hacking or run
> > some tests we could work on it for a future libseccomp release.  An
> > emulated AArch64 VM would also work, but that route can be slow/annoying.
> 
> Simulators are all we have right now (we're juuust getting to the
> point where hardware is starting to become available). I wasn't
> being serious really, though I'm sure somebody (possibly even
> somebody at Red Hat :-)) will work around to it at some point.

Regardless, consider it a standing offer.

-- 
paul moore
security and virtualization @ redhat