Seccomp BPF: initial structure for unittests

Seccomp BPF: initial structure for unittests

- On Linux, support a new sandbox_linux_unittests target
- Add a new seccomp_bpf_unittests target as a dependency of the global
  sandbox_linux_unittests target.
- Integrate globally as a chromium_builder_tests dependency


BUG=
TEST=


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=143549

[jln (very slow on Chromium), 2012-06-21 19:33:40]

Basic boilerplate for Seccomp BPF unittests.

[Markus (顧孟勤), 2012-06-21 21:01:07]

lgtm

https://chromiumcodereview.appspot.com/10635006/diff/6001/sandbox/linux/secco...
File sandbox/linux/seccomp-bpf/sandbox_bpf_unittest.cc (right):

https://chromiumcodereview.appspot.com/10635006/diff/6001/sandbox/linux/secco...
sandbox/linux/seccomp-bpf/sandbox_bpf_unittest.cc:10:
playground2::Sandbox::supportsSeccompSandbox(-1);
Maybe add a comment that we are not actually checking the return value, because
it is acceptable for the kernel to have not seccomp/BPF support.

https://chromiumcodereview.appspot.com/10635006/diff/6001/sandbox/sandbox_lin...
File sandbox/sandbox_linux.gypi (right):

https://chromiumcodereview.appspot.com/10635006/diff/6001/sandbox/sandbox_lin...
sandbox/sandbox_linux.gypi:10: # and is its own target.
I am really not a GYP expert by a long shot, so you probably need somebody else
to think about the implications what we are doing here.

But I just want to double-check that we can ultimately extend this test so that
it tests all of the different sandboxes on Linux with just a single unittest
binary.

This could include seccomp mode 1, seccomp mode 2, suid, SELinux and possibly
others.

Also check with somebody like tc whether it is OK to have a Linux-specific
unittest. Or whether there should be single binary for all platforms.

I guess, this really depends on whether we think this test will ever be run
automatically by the buildbots. For seccomp/BPF that might actually be possible
at some point, whereas for setuid and SELinux that probably won't ever be the
case.

[jln (very slow on Chromium), 2012-06-21 21:10:45]

https://chromiumcodereview.appspot.com/10635006/diff/6001/sandbox/sandbox_lin...
File sandbox/sandbox_linux.gypi (right):

https://chromiumcodereview.appspot.com/10635006/diff/6001/sandbox/sandbox_lin...
sandbox/sandbox_linux.gypi:10: # and is its own target.
On 2012/06/21 21:01:07, Markus (顧孟勤) wrote:
> I am really not a GYP expert by a long shot, so you probably need somebody
else
> to think about the implications what we are doing here.
> 
> But I just want to double-check that we can ultimately extend this test so
that
> it tests all of the different sandboxes on Linux with just a single unittest
> binary.
> 
> This could include seccomp mode 1, seccomp mode 2, suid, SELinux and possibly
> others.
> 
> Also check with somebody like tc whether it is OK to have a Linux-specific
> unittest. Or whether there should be single binary for all platforms.
> 
> I guess, this really depends on whether we think this test will ever be run
> automatically by the buildbots. For seccomp/BPF that might actually be
possible
> at some point, whereas for setuid and SELinux that probably won't ever be the
> case.

Yes, this is what this does: we always build tests/unit_tests.cc and, depending
on conditions, we sometimes link specific unittests to it.

It's fine to have our own unittest binary, this is what most people do. Note
that with just this change, this won't run automatically on build bots just yet
(build bots don't even have BPF support so it's not urgent ATM), but at least
it'll get built.

If that's fine with you, I'll land this as-is when I can (this depends on a
bunch of CLs that have been reverted), and I'll look into how getting the test
to actually run automatically on the buildbots later. The sandbox GYP is a bit
of a nightmare ATM, I'm trying to clean things up and I need to move very
slowly.

[Markus (顧孟勤), 2012-06-21 21:13:50]

Sounds like a plan to me.

I agree that this is a good first step, and I like where you are planning
to go.

On Thu, Jun 21, 2012 at 2:10 PM, <jln@chromium.org> wrote:

>
> https://chromiumcodereview.**appspot.com/10635006/diff/**
>
6001/sandbox/sandbox_linux.**gypi<https://chromiumcodereview.appspot.com/10635006/diff/6001/sandbox/sandbox_linux.gypi>
> File sandbox/sandbox_linux.gypi (right):
>
> https://chromiumcodereview.**appspot.com/10635006/diff/**
>
6001/sandbox/sandbox_linux.**gypi#newcode10<https://chromiumcodereview.appspot.com/10635006/diff/6001/sandbox/sandbox_linux.gypi#newcode10>
> sandbox/sandbox_linux.gypi:10: # and is its own target.
> On 2012/06/21 21:01:07, Markus (顧孟勤) wrote:
>
>> I am really not a GYP expert by a long shot, so you probably need
>>
> somebody else
>
>> to think about the implications what we are doing here.
>>
>
>  But I just want to double-check that we can ultimately extend this
>>
> test so that
>
>> it tests all of the different sandboxes on Linux with just a single
>>
> unittest
>
>> binary.
>>
>
>  This could include seccomp mode 1, seccomp mode 2, suid, SELinux and
>>
> possibly
>
>> others.
>>
>
>  Also check with somebody like tc whether it is OK to have a
>>
> Linux-specific
>
>> unittest. Or whether there should be single binary for all platforms.
>>
>
>  I guess, this really depends on whether we think this test will ever
>>
> be run
>
>> automatically by the buildbots. For seccomp/BPF that might actually be
>>
> possible
>
>> at some point, whereas for setuid and SELinux that probably won't ever
>>
> be the
>
>> case.
>>
>
> Yes, this is what this does: we always build tests/unit_tests.cc and,
> depending on conditions, we sometimes link specific unittests to it.
>
> It's fine to have our own unittest binary, this is what most people do.
> Note that with just this change, this won't run automatically on build
> bots just yet (build bots don't even have BPF support so it's not urgent
> ATM), but at least it'll get built.
>
> If that's fine with you, I'll land this as-is when I can (this depends
> on a bunch of CLs that have been reverted), and I'll look into how
> getting the test to actually run automatically on the buildbots later.
> The sandbox GYP is a bit of a nightmare ATM, I'm trying to clean things
> up and I need to move very slowly.
>
>
https://chromiumcodereview.**appspot.com/10635006/<https://chromiumcodereview...
>

[commit-bot: I haz the power, 2012-06-22 02:03:38]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jln@chromium.org/10635006/6001

[commit-bot: I haz the power, 2012-06-22 03:17:35]

Try job failure for 10635006-6001 (retry) (retry) on mac_rel for step
"browser_tests".
It's a second try, previously, step "browser_tests" failed.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...

[commit-bot: I haz the power, 2012-06-22 04:26:54]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jln@chromium.org/10635006/6001

[commit-bot: I haz the power, 2012-06-22 06:36:03]

Change committed as 143549