Apply an initial seccomp filter policy for Pepper Flash.

Apply an initial seccomp filter policy for Pepper Flash.

I'll send out a separate mail about the shmat() situation -- for now, a
shipping seccomp filter sandbox is better than no filtering.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=132501

[Chris Evans, 2012-04-16 21:54:23]

Hey guys, any chance one (or more) of you can have a quick look at this Flash
sandboxing? Ideally I'd like to land it before 2am tonight to get a whirl on the
next dev channel.

[Kees Cook, 2012-04-16 22:08:57]

lgtm

[Markus (顧孟勤), 2012-04-16 22:09:23]

lgtm

https://chromiumcodereview.appspot.com/10105009/diff/1/content/common/sandbox...
File content/common/sandbox_init_linux.cc (right):

https://chromiumcodereview.appspot.com/10105009/diff/1/content/common/sandbox...
content/common/sandbox_init_linux.cc:238: // These are under investigation, and
hopefully not here for the long term.
SysV shared memory is really broken and dangerous as it can probably be used to
screenscrape renderers. I have an implementation in my code, that allows
restricting this system call. But it is unfortunately quite complicated. I wish
we could get kernel support.

For now, I don't have any problem with you checking in your code as is, since it
is strictly an improvement over what we had before. But in the long-run, we do
need a better solution.

https://chromiumcodereview.appspot.com/10105009/diff/1/content/common/sandbox...
content/common/sandbox_init_linux.cc:243: EmitFailSyscall(__NR_open, ENOENT,
program);
Why do you need to explicitly fail some system calls. Wouldn't they fail,
because of a default policy that denies all system calls that aren't explicitly
whitelisted?

And I assume, this probably breaks some Flash features, doesn't it? Things like
accessing the microphone and camera would spring to mind. Or maybe, storing
persistent Flash cookies.

[Kees Cook, 2012-04-16 22:13:35]

https://chromiumcodereview.appspot.com/10105009/diff/1/content/common/sandbox...
File content/common/sandbox_init_linux.cc (right):

https://chromiumcodereview.appspot.com/10105009/diff/1/content/common/sandbox...
content/common/sandbox_init_linux.cc:243: EmitFailSyscall(__NR_open, ENOENT,
program);
AIUI, the difference here is between "Fail" and "Kill". Unlisted syscalls kill
the process, but these syscalls are used for no good reason, and can just be
denied instead of doing a full kill.

[cevans, 2012-04-16 22:21:56]

On Mon, Apr 16, 2012 at 3:09 PM, <markus@chromium.org> wrote:

> lgtm
>
>
>
>
> https://chromiumcodereview.**appspot.com/10105009/diff/1/**
>
content/common/sandbox_init_**linux.cc<https://chromiumcodereview.appspot.com/10105009/diff/1/content/common/sandbox_init_linux.cc>
> File content/common/sandbox_init_**linux.cc (right):
>
> https://chromiumcodereview.**appspot.com/10105009/diff/1/**
>
content/common/sandbox_init_**linux.cc#newcode238<https://chromiumcodereview.appspot.com/10105009/diff/1/content/common/sandbox_init_linux.cc#newcode238>
> content/common/sandbox_init_**linux.cc:238: // These are under
>
> investigation, and hopefully not here for the long term.
> SysV shared memory is really broken and dangerous as it can probably be
> used to screenscrape renderers. I have an implementation in my code,
> that allows restricting this system call. But it is unfortunately quite
> complicated. I wish we could get kernel support.
>

Yes, I'll start a separate thread. I spend a few hours last night
investigating options.


> For now, I don't have any problem with you checking in your code as is,
> since it is strictly an improvement over what we had before. But in the
> long-run, we do need a better solution.
>
> https://chromiumcodereview.**appspot.com/10105009/diff/1/**
>
content/common/sandbox_init_**linux.cc#newcode243<https://chromiumcodereview.appspot.com/10105009/diff/1/content/common/sandbox_init_linux.cc#newcode243>
> content/common/sandbox_init_**linux.cc:243: EmitFailSyscall(__NR_open,
> ENOENT, program);
> Why do you need to explicitly fail some system calls. Wouldn't they
> fail, because of a default policy that denies all system calls that
> aren't explicitly whitelisted?
>

"fail" permits the program to continue, but with an errno for the syscall,
which does not execute. A lot of code needs this sort of thing. For example
the Flash plug-in does "sh -c 'echo "NOT SANDBOXED"'" so that hopefully
someone will notice the message if the sandboxing goes wrong.


>
> And I assume, this probably breaks some Flash features, doesn't it?
>

No. Pepper plug-ins are architected such that all system access (files,
devices, etc) is brokered via APIs.
open() and execve() are also guaranteed to get ENOENT in the existing suid
sandbox due to the chroot().

Things like accessing the microphone and camera would spring to mind. Or
> maybe, storing persistent Flash cookies.
>
>
https://chromiumcodereview.**appspot.com/10105009/<https://chromiumcodereview...
>

[Markus (顧孟勤), 2012-04-16 22:22:02]

I see. That makes some sense. Although in reality it is just annoying.
An actual attacker can presumably carefully design the attack so that
it is aware of the filters and avoids killing the process. But a
genuine users (or developer) is going to be confused why the process
just disappears without any trace and without the ability to debug it
(i.e. gdb gets disconnected, no exit handlers run, and no core file is
generated).

I generally find a default policy or returning a suitable errno value
to be more useful. But feel free to convince me otherwise.


Markus

On Mon, Apr 16, 2012 at 15:13,  <keescook@chromium.org> wrote:
>
>
https://chromiumcodereview.appspot.com/10105009/diff/1/content/common/sandbox...
> File content/common/sandbox_init_linux.cc (right):
>
>
https://chromiumcodereview.appspot.com/10105009/diff/1/content/common/sandbox...
> content/common/sandbox_init_linux.cc:243: EmitFailSyscall(__NR_open,
> ENOENT, program);
> AIUI, the difference here is between "Fail" and "Kill". Unlisted
> syscalls kill the process, but these syscalls are used for no good
> reason, and can just be denied instead of doing a full kill.
>
> https://chromiumcodereview.appspot.com/10105009/

[piman, 2012-04-16 22:31:44]

Before shipping this, have we measured the performance impact on Flash? Last
time seccomp was turned on on Chrome OS, we measured a 2x perf impact on Flash
(e.g. videos) which is unacceptable, and we had to revert.

[Markus (顧孟勤), 2012-04-16 22:38:32]

I think, somebody actually investigated and discovered that Flash
sends a file descriptor for each video frame. In a tight sandbox (and
with the current kernel API) that is an expensive operation and should
probably be fixed in Flash. Even without the sandbox, this is rather
inefficient.

But in the current changelist, sendmsg() is unrestricted. So, there
shouldn't be any performance penalty above and beyond the penalty that
the kernel always imposes -- there also won't be the full sandboxing
that we would eventually like to achieve.


Markus

On Mon, Apr 16, 2012 at 15:31,  <piman@chromium.org> wrote:
> Before shipping this, have we measured the performance impact on Flash? Last
> time seccomp was turned on on Chrome OS, we measured a 2x perf impact on
> Flash
> (e.g. videos) which is unacceptable, and we had to revert.
>
> https://chromiumcodereview.appspot.com/10105009/

[piman, 2012-04-16 22:43:19]

On Mon, Apr 16, 2012 at 3:38 PM, Markus Gutschke <markus@chromium.org>wrote:

> I think, somebody actually investigated and discovered that Flash
> sends a file descriptor for each video frame. In a tight sandbox (and
> with the current kernel API) that is an expensive operation and should
> probably be fixed in Flash. Even without the sandbox, this is rather
> inefficient.
>

I don't think that's true today...


>
> But in the current changelist, sendmsg() is unrestricted. So, there
> shouldn't be any performance penalty above and beyond the penalty that
> the kernel always imposes -- there also won't be the full sandboxing
> that we would eventually like to achieve.
>

Sure, it all should be fine in theory, but like it was last time... we
still saw significant regression.
Can anyone show supporting data?

Antoine


>
>
> Markus
>
> On Mon, Apr 16, 2012 at 15:31,  <piman@chromium.org> wrote:
> > Before shipping this, have we measured the performance impact on Flash?
> Last
> > time seccomp was turned on on Chrome OS, we measured a 2x perf impact on
> > Flash
> > (e.g. videos) which is unacceptable, and we had to revert.
> >
> > https://chromiumcodereview.appspot.com/10105009/
>

[Markus (顧孟勤), 2012-04-16 22:50:42]

I believe, Will has some performance numbers for exactly how much
impact there is when you install seccomp filters in the kernel. I am
sure, the numbers are somewhere in the LKML archives, but he can
probably dig them up faster than I would find them.


Markus

On Mon, Apr 16, 2012 at 15:42, Antoine Labour <piman@chromium.org> wrote:
> On Mon, Apr 16, 2012 at 3:38 PM, Markus Gutschke <markus@chromium.org>
> wrote:
>>
>> I think, somebody actually investigated and discovered that Flash
>> sends a file descriptor for each video frame. In a tight sandbox (and
>> with the current kernel API) that is an expensive operation and should
>> probably be fixed in Flash. Even without the sandbox, this is rather
>> inefficient.
>
>
> I don't think that's true today...
>
>>
>>
>> But in the current changelist, sendmsg() is unrestricted. So, there
>> shouldn't be any performance penalty above and beyond the penalty that
>> the kernel always imposes -- there also won't be the full sandboxing
>> that we would eventually like to achieve.
>
>
> Sure, it all should be fine in theory, but like it was last time... we still
> saw significant regression.
> Can anyone show supporting data?
>
> Antoine
>
>>
>>
>>
>> Markus
>>
>> On Mon, Apr 16, 2012 at 15:31,  <piman@chromium.org> wrote:
>> > Before shipping this, have we measured the performance impact on Flash?
>> > Last
>> > time seccomp was turned on on Chrome OS, we measured a 2x perf impact on
>> > Flash
>> > (e.g. videos) which is unacceptable, and we had to revert.
>> >
>> > https://chromiumcodereview.appspot.com/10105009/
>
>

[cevans, 2012-04-16 22:54:25]

On Mon, Apr 16, 2012 at 3:31 PM, <piman@chromium.org> wrote:

> Before shipping this, have we measured the performance impact on Flash?
> Last
> time seccomp was turned on on Chrome OS, we measured a 2x perf impact on
> Flash
> (e.g. videos) which is unacceptable, and we had to revert.
>

This new seccomp is based on a new kernel facility and it is fast. There
are no per-syscall context switches and no syscall serialization issues.

I ran a few Flash benchmarks (e.g. FPS measurements of heavy GFX loads) and
was unable to discern any difference in speed. If you had a specific
benchmark you wanted me to check, I'd be happy to do so -- but knowing how
seccomp filter works, I'd be surprised if we had any trouble.


>
https://chromiumcodereview.**appspot.com/10105009/<https://chromiumcodereview...
>

[piman, 2012-04-16 22:54:39]

On Mon, Apr 16, 2012 at 3:50 PM, Markus Gutschke <markus@chromium.org>wrote:

> I believe, Will has some performance numbers for exactly how much
> impact there is when you install seccomp filters in the kernel. I am
> sure, the numbers are somewhere in the LKML archives, but he can
> probably dig them up faster than I would find them.
>

I am talking Flash specifically.

Antoine


>
>
> Markus
>
> On Mon, Apr 16, 2012 at 15:42, Antoine Labour <piman@chromium.org> wrote:
> > On Mon, Apr 16, 2012 at 3:38 PM, Markus Gutschke <markus@chromium.org>
> > wrote:
> >>
> >> I think, somebody actually investigated and discovered that Flash
> >> sends a file descriptor for each video frame. In a tight sandbox (and
> >> with the current kernel API) that is an expensive operation and should
> >> probably be fixed in Flash. Even without the sandbox, this is rather
> >> inefficient.
> >
> >
> > I don't think that's true today...
> >
> >>
> >>
> >> But in the current changelist, sendmsg() is unrestricted. So, there
> >> shouldn't be any performance penalty above and beyond the penalty that
> >> the kernel always imposes -- there also won't be the full sandboxing
> >> that we would eventually like to achieve.
> >
> >
> > Sure, it all should be fine in theory, but like it was last time... we
> still
> > saw significant regression.
> > Can anyone show supporting data?
> >
> > Antoine
> >
> >>
> >>
> >>
> >> Markus
> >>
> >> On Mon, Apr 16, 2012 at 15:31,  <piman@chromium.org> wrote:
> >> > Before shipping this, have we measured the performance impact on
> Flash?
> >> > Last
> >> > time seccomp was turned on on Chrome OS, we measured a 2x perf impact
> on
> >> > Flash
> >> > (e.g. videos) which is unacceptable, and we had to revert.
> >> >
> >> > https://chromiumcodereview.appspot.com/10105009/
> >
> >
>

[cevans, 2012-04-16 22:58:05]

On Mon, Apr 16, 2012 at 3:42 PM, Antoine Labour <piman@chromium.org> wrote:

> On Mon, Apr 16, 2012 at 3:38 PM, Markus Gutschke <markus@chromium.org>wrote:
>
>> I think, somebody actually investigated and discovered that Flash
>> sends a file descriptor for each video frame. In a tight sandbox (and
>> with the current kernel API)
>
>
Just to be clear, I believe Markus is referring to the "old" seccomp
sandbox when he calls this expensive. The "new" seccomp sandbox has a very
low per-syscall overhead.

that is an expensive operation and should
>> probably be fixed in Flash. Even without the sandbox, this is rather
>> inefficient.
>>
>
> I don't think that's true today...
>

The general problem with Flash is that it spews out many syscalls (perhaps
1000?) per second. The new seccomp sandbox doesn't have a problem with such
rates.


>
>>
>> But in the current changelist, sendmsg() is unrestricted. So, there
>> shouldn't be any performance penalty above and beyond the penalty that
>> the kernel always imposes -- there also won't be the full sandboxing
>> that we would eventually like to achieve.
>>
>
> Sure, it all should be fine in theory, but like it was last time... we
> still saw significant regression.
> Can anyone show supporting data?
>
> Antoine
>
>
>>
>>
>> Markus
>>
>> On Mon, Apr 16, 2012 at 15:31,  <piman@chromium.org> wrote:
>> > Before shipping this, have we measured the performance impact on Flash?
>> Last
>> > time seccomp was turned on on Chrome OS, we measured a 2x perf impact on
>> > Flash
>> > (e.g. videos) which is unacceptable, and we had to revert.
>> >
>> > https://chromiumcodereview.appspot.com/10105009/
>>
>
>

[piman, 2012-04-16 23:05:04]

On Mon, Apr 16, 2012 at 3:54 PM, Chris Evans <cevans@google.com> wrote:

> On Mon, Apr 16, 2012 at 3:31 PM, <piman@chromium.org> wrote:
>
>> Before shipping this, have we measured the performance impact on Flash?
>> Last
>> time seccomp was turned on on Chrome OS, we measured a 2x perf impact on
>> Flash
>> (e.g. videos) which is unacceptable, and we had to revert.
>>
>
> This new seccomp is based on a new kernel facility and it is fast. There
> are no per-syscall context switches and no syscall serialization issues.
>
> I ran a few Flash benchmarks (e.g. FPS measurements of heavy GFX loads)
> and was unable to discern any difference in speed. If you had a specific
> benchmark you wanted me to check, I'd be happy to do so -- but knowing how
> seccomp filter works, I'd be surprised if we had any trouble.
>

Part of the problems in the previous implementation was the serialization
of the handling of calls necessitating the trusted process.
If that is gone, and you verified that Flash doesn't regress, then great.
The one benchmark I would like to check is running 720p youtube videos on
Alex. Checking dropped frames in the "show video info" option in the
context menu (and making sure it doesn't grow significantly over time).

In any case, please make sure we still have a flag to disable it.

Antoine


>
>
>>
https://chromiumcodereview.**appspot.com/10105009/<https://chromiumcodereview...
>>
>
>

[cevans, 2012-04-16 23:12:08]

On Mon, Apr 16, 2012 at 4:04 PM, Antoine Labour <piman@chromium.org> wrote:

>
>
> On Mon, Apr 16, 2012 at 3:54 PM, Chris Evans <cevans@google.com> wrote:
>
>> On Mon, Apr 16, 2012 at 3:31 PM, <piman@chromium.org> wrote:
>>
>>> Before shipping this, have we measured the performance impact on Flash?
>>> Last
>>> time seccomp was turned on on Chrome OS, we measured a 2x perf impact on
>>> Flash
>>> (e.g. videos) which is unacceptable, and we had to revert.
>>>
>>
>> This new seccomp is based on a new kernel facility and it is fast. There
>> are no per-syscall context switches and no syscall serialization issues.
>>
>> I ran a few Flash benchmarks (e.g. FPS measurements of heavy GFX loads)
>> and was unable to discern any difference in speed. If you had a specific
>> benchmark you wanted me to check, I'd be happy to do so -- but knowing how
>> seccomp filter works, I'd be surprised if we had any trouble.
>>
>
> Part of the problems in the previous implementation was the serialization
> of the handling of calls necessitating the trusted process.
> If that is gone, and you verified that Flash doesn't regress, then great.
> The one benchmark I would like to check is running 720p youtube videos on
> Alex. Checking dropped frames in the "show video info" option in the
> context menu (and making sure it doesn't grow significantly over time).
>

1080p runs @70% CPU on my desktop, both with and without the sandbox.


> In any case, please make sure we still have a flag to disable it.
>

--no-sandbox covers this, but based on your suggestion, I think I'll wire
up --disable-seccomp-sandbox to cover the new seccomp sandbox too, it's a
good idea.


Cheers
Chris


> Antoine
>
>
>>
>>
>>>
https://chromiumcodereview.**appspot.com/10105009/<https://chromiumcodereview...
>>>
>>
>>
>

[cevans, 2012-04-16 23:24:28]

On Mon, Apr 16, 2012 at 4:12 PM, Chris Evans <cevans@google.com> wrote:

> On Mon, Apr 16, 2012 at 4:04 PM, Antoine Labour <piman@chromium.org>wrote:
>
>>
>>
>> On Mon, Apr 16, 2012 at 3:54 PM, Chris Evans <cevans@google.com> wrote:
>>
>>> On Mon, Apr 16, 2012 at 3:31 PM, <piman@chromium.org> wrote:
>>>
>>>> Before shipping this, have we measured the performance impact on Flash?
>>>> Last
>>>> time seccomp was turned on on Chrome OS, we measured a 2x perf impact
>>>> on Flash
>>>> (e.g. videos) which is unacceptable, and we had to revert.
>>>>
>>>
>>> This new seccomp is based on a new kernel facility and it is fast. There
>>> are no per-syscall context switches and no syscall serialization issues.
>>>
>>> I ran a few Flash benchmarks (e.g. FPS measurements of heavy GFX loads)
>>> and was unable to discern any difference in speed. If you had a specific
>>> benchmark you wanted me to check, I'd be happy to do so -- but knowing how
>>> seccomp filter works, I'd be surprised if we had any trouble.
>>>
>>
>> Part of the problems in the previous implementation was the serialization
>> of the handling of calls necessitating the trusted process.
>> If that is gone, and you verified that Flash doesn't regress, then great.
>> The one benchmark I would like to check is running 720p youtube videos on
>> Alex. Checking dropped frames in the "show video info" option in the
>> context menu (and making sure it doesn't grow significantly over time).
>>
>
> 1080p runs @70% CPU on my desktop, both with and without the sandbox.
>

BTW, the kernel support for the new seccomp filter isn't yet in CrOS. Will
and Jorge won't turn it on without careful checks.


>
>> In any case, please make sure we still have a flag to disable it.
>>
>
> --no-sandbox covers this, but based on your suggestion, I think I'll wire
> up --disable-seccomp-sandbox to cover the new seccomp sandbox too, it's a
> good idea.
>
>
> Cheers
> Chris
>
>
>> Antoine
>>
>>
>>>
>>>
>>>>
https://chromiumcodereview.**appspot.com/10105009/<https://chromiumcodereview...
>>>>
>>>
>>>
>>
>

[Will Drewry, 2012-04-16 23:29:51]

bpf program lgtm

Timing-wise, the last benchmarks put a base overhead at about 260ns. Doing a
number load and a simple jump table adds about 60ns. (On an N570 in 64bit mode)

There is some fixed time overhead per jeq too, but I haven't done a recent test
to give a good number.  In general, this avoids all the serialization and
context switching overhead of the traditional seccompsandbox.

[piman, 2012-04-16 23:41:42]

On Mon, Apr 16, 2012 at 4:12 PM, Chris Evans <cevans@google.com> wrote:

> On Mon, Apr 16, 2012 at 4:04 PM, Antoine Labour <piman@chromium.org>wrote:
>
>>
>>
>> On Mon, Apr 16, 2012 at 3:54 PM, Chris Evans <cevans@google.com> wrote:
>>
>>> On Mon, Apr 16, 2012 at 3:31 PM, <piman@chromium.org> wrote:
>>>
>>>> Before shipping this, have we measured the performance impact on Flash?
>>>> Last
>>>> time seccomp was turned on on Chrome OS, we measured a 2x perf impact
>>>> on Flash
>>>> (e.g. videos) which is unacceptable, and we had to revert.
>>>>
>>>
>>> This new seccomp is based on a new kernel facility and it is fast. There
>>> are no per-syscall context switches and no syscall serialization issues.
>>>
>>> I ran a few Flash benchmarks (e.g. FPS measurements of heavy GFX loads)
>>> and was unable to discern any difference in speed. If you had a specific
>>> benchmark you wanted me to check, I'd be happy to do so -- but knowing how
>>> seccomp filter works, I'd be surprised if we had any trouble.
>>>
>>
>> Part of the problems in the previous implementation was the serialization
>> of the handling of calls necessitating the trusted process.
>> If that is gone, and you verified that Flash doesn't regress, then great.
>> The one benchmark I would like to check is running 720p youtube videos on
>> Alex. Checking dropped frames in the "show video info" option in the
>> context menu (and making sure it doesn't grow significantly over time).
>>
>
> 1080p runs @70% CPU on my desktop, both with and without the sandbox.
>

Please make sure to test on the Chrome OS devices. 720p@30fps barely runs
on Alex, a 5-10% perf drop (which could be in the noise of your desktop
tests) could make it fall below the line - and the degradation mode makes
you easily half the frame rate if not more. Also the previous perf problems
were not in terms of significant CPU increase but in terms of call blocking
for much longer (e.g from a few µs to 9-10ms).


>
>> In any case, please make sure we still have a flag to disable it.
>>
>
> --no-sandbox covers this, but based on your suggestion, I think I'll wire
> up --disable-seccomp-sandbox to cover the new seccomp sandbox too, it's a
> good idea.
>

Yes, we don't want to have to disable the suid sandbox because of a problem
(perf or not) in the seccomp one.


>
>
> Cheers
> Chris
>
>
>>  Antoine
>>
>>
>>>
>>>
>>>>
https://chromiumcodereview.**appspot.com/10105009/<https://chromiumcodereview...
>>>>
>>>
>>>
>>
>

[Chris Evans, 2012-04-17 00:01:31]

On 2012/04/16 23:41:42, piman wrote:
> On Mon, Apr 16, 2012 at 4:12 PM, Chris Evans <mailto:cevans@google.com> wrote:
> 
> > On Mon, Apr 16, 2012 at 4:04 PM, Antoine Labour <piman@chromium.org>wrote:
> >
> >>
> >>
> >> On Mon, Apr 16, 2012 at 3:54 PM, Chris Evans <mailto:cevans@google.com>
wrote:
> >>
> >>> On Mon, Apr 16, 2012 at 3:31 PM, <mailto:piman@chromium.org> wrote:
> >>>
> >>>> Before shipping this, have we measured the performance impact on Flash?
> >>>> Last
> >>>> time seccomp was turned on on Chrome OS, we measured a 2x perf impact
> >>>> on Flash
> >>>> (e.g. videos) which is unacceptable, and we had to revert.
> >>>>
> >>>
> >>> This new seccomp is based on a new kernel facility and it is fast. There
> >>> are no per-syscall context switches and no syscall serialization issues.
> >>>
> >>> I ran a few Flash benchmarks (e.g. FPS measurements of heavy GFX loads)
> >>> and was unable to discern any difference in speed. If you had a specific
> >>> benchmark you wanted me to check, I'd be happy to do so -- but knowing how
> >>> seccomp filter works, I'd be surprised if we had any trouble.
> >>>
> >>
> >> Part of the problems in the previous implementation was the serialization
> >> of the handling of calls necessitating the trusted process.
> >> If that is gone, and you verified that Flash doesn't regress, then great.
> >> The one benchmark I would like to check is running 720p youtube videos on
> >> Alex. Checking dropped frames in the "show video info" option in the
> >> context menu (and making sure it doesn't grow significantly over time).
> >>
> >
> > 1080p runs @70% CPU on my desktop, both with and without the sandbox.
> >
> 
> Please make sure to test on the Chrome OS devices

I talked to Jorge and he has committed to doing this as part of updating the
ChromeOS kernel.

> 720p@30fps barely runs
> on Alex, a 5-10% perf drop (which could be in the noise of your desktop
> tests) could make it fall below the line - and the degradation mode makes
> you easily half the frame rate if not more. Also the previous perf problems
> were not in terms of significant CPU increase but in terms of call blocking
> for much longer (e.g from a few µs to 9-10ms).
> 
> 
> >
> >> In any case, please make sure we still have a flag to disable it.
> >>
> >
> > --no-sandbox covers this, but based on your suggestion, I think I'll wire
> > up --disable-seccomp-sandbox to cover the new seccomp sandbox too, it's a
> > good idea.
> >
> 
> Yes, we don't want to have to disable the suid sandbox because of a problem
> (perf or not) in the seccomp one.

Done.

> 
> 
> >
> >
> > Cheers
> > Chris
> >
> >
> >>  Antoine
> >>
> >>
> >>>
> >>>
> >>>>
>
https://chromiumcodereview.**appspot.com/10105009/%3Chttps://chromiumcoderevi...>
> >>>>
> >>>
> >>>
> >>
> >

[Jorge Lucangeli Obes, 2012-04-17 00:05:54]

lgtm

[piman, 2012-04-17 00:31:49]

LGTM