Re: Logging sandbox failures

[Sunny Sachanandani]

+security-dev

On Fri, Aug 14, 2015 at 5:18 PM, Sunny Sachanandani <sun...@chromium.org> wrote:

Hi chromium-dev,

I'm trying to debug a performance issue with glx on linux. This issue only happens with the chrome sandbox turned on. Is there a way to log what the sandbox is doing on linux like the "--enable-sandbox-logging" flag on os x. I've tried the "--gpu-sandbox-failures-fatal" flag which is supposed to crash the gpu process when a sandbox failure happens but that doesn't appear to work.

Thanks!

- Sunny

[Ricky Zhou]

From glancing through that code, that flag seems to only enable a
single LOG(FATAL) at sandbox initialization time. Unfortunately, due
to implementation details of the Linux sandbox, there are certain
types of failures which we cannot easily log (the biggest example
being attempts to open files which do not exist inside of the chroot).

I would probably try to strace the GPU process and see if there are
any failed attempts to open files that look like they might be
performance-sensitive - for example, opening /proc/cpuinfo to
determine whether some optimizations might be enabled. Failing that,
we can also try to selectively disable parts of the sandbox
(unfortunately not easily flag controlled) to try and narrow down
which restrictions are causing the performance issue. Happy to help
look deeper if there isn't an easy cause!

Thanks,
Ricky

On Mon, Aug 17, 2015 at 12:24 PM, Sunny Sachanandani

[Ricky Zhou]

From glancing through that code, that flag seems to only enable a
single LOG(FATAL) at sandbox initialization time. Unfortunately, due
to implementation details of the Linux sandbox, there are certain
types of failures which we cannot easily log (the biggest example
being attempts to open files which do not exist inside of the chroot).

I would probably try to strace the GPU process and see if there are
any failed attempts to open files that look like they might be
performance-sensitive - for example, opening /proc/cpuinfo to
determine whether some optimizations might be enabled. Failing that,
we can also try to selectively disable parts of the sandbox
(unfortunately not easily flag controlled) to try and narrow down
which restrictions are causing the performance issue. Happy to help
look deeper if there isn't an easy cause!

Thanks,
Ricky

On Mon, Aug 17, 2015 at 12:24 PM, Sunny Sachanandani

[Sunny Sachanandani]

To provide some more context about this, we're seeing high cpu usage on calling a GLX extension function (glXWaitVideoSyncSGI) in the nvidia linux GLX library. That function writes to a file descriptor and calls recvmsg on it. I imagine the nvidia kernel driver sets up the file descriptor. There's strace output for the thread that shows high cpu usage on this bug. In that trace it looks like each call to recvmsg fails.