arc: enable Android tracing in verified-boot mode

components/arc/common/trace.mojom

+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+// Next MinVersion: 1
+
+module arc.mojom;
+
+interface TraceInstance {
+  // Queries available tracing categories in the container.
+  QueryAvailableCategories@0() => (array<string> categories);
+
+  // Starts tracing in the container with the given categories.
+  StartTracing@1(array<string> categories) => (bool success);
+
+  // Stops tracing in the container.
+  StopTracing@2() => (string report);

[Luis Héctor Chávez, 2017/01/17 19:20:32]

What happens if the user lets the collection proceed for a very long time? Would
there be any issues returning an arbitrarily long report? Will the other side
have a circular buffer and start dropping events? Is it difficult to have
StartTracing() return a handle to a pipe that streams the JSON chunks and have
Chrome read from that pipe and hand over the chunks to the tracing controller?

In any case, the comment should explain a bit more about what |report| contains.

[Earl Ou, 2017/01/18 09:13:21]

I added more comment here.

Actually I tried to used a handle as following during my developing.

// in trace.mojom
StopTracing@2(handle report_write_handle)

// in arc_trace_bridge.cc
int fds[2];
DCHECK_EQ(0, pipe(fds));
...
trace_instance->StopTracing(mojo::WrapPlatformFile(fds[1]));
...

So we can write report through the pipe.

However, in Android, StopTracing() of trace instance (ArcTraceService) never get
called.

If I set ArcTraceService to permissive mode than the problem get solved, so I
think there is something wrong in my sepolicy settings. However, I could not
find any logs about this in logcat and dmesg and don't know how to debug it.

Did you see this issue before?

In the end I choose to use a string. As mentioned in the comment, the size of
the report is limited in ArcTraceService by 16MB.

[Luis Héctor Chávez, 2017/01/18 17:31:32]

Depending on the context in which an SELinux denial happens, it will get
reported to different places. Some of them are logged in /var/log/messages
instead of the other two locations. Let's follow up offline to fix the
underlying issue instead of resorting to workarounds.

The reason I'd prefer to have Chrome handle this is to centralize everything and
have a potentially simpler implementation, so that events can be bumped out of
the circular buffer more or less in order. Otherwise, a good chunk of
Chrome-side events will have a very large probability of getting evicted if the
16MB comes at once from Android, which will be very confusing for users since
they'll lose some correlation.

+};