Impl mus::mojom::GpuService to enable using Chrome IPC version gpu CmdBuf in mus

components/mus/public/interfaces/gpu_service.mojom

Index: components/mus/public/interfaces/gpu_service.mojom
diff --git a/components/mus/public/interfaces/gpu_service.mojom b/components/mus/public/interfaces/gpu_service.mojom
index f7f4cf4af657060ec870816cdb3fe2bd63db7eaa..caeb528e5feb360f76b62162b4b2aeebb433eb23 100644
--- a/components/mus/public/interfaces/gpu_service.mojom
+++ b/components/mus/public/interfaces/gpu_service.mojom
@@ -14,10 +14,8 @@ interface GpuService {
   // Tells the GPU service to create a new channel for communication with a
   // client. The GPU service responds asynchronously with IPC handle and
   // GPUInfo.
-  EstablishGpuChannel(bool prempts,
-                      bool allow_view_command_buffers,
-                      bool allow_real_time_streams)
-      => (ChannelHandle channel_handle, GpuInfo gpu_info);
+  EstablishGpuChannel()
+      => (int32 client_id, ChannelHandle channel_handle, GpuInfo? gpu_info);

[Tom Sepez, 2016/06/03 17:11:11]

How does it know that its less trustworthy client is telling the truth about its
client_id and isn't trying to create a conflict with an existing unrelated
client?

[dcheng, 2016/06/03 17:34:48]

Is GpuInfo nullable only because it's not yet implemented? Why add that
parameter at all? Why would the receiver ever want to not return GpuInfo?

[Peng, 2016/06/03 18:34:07]

Yes. I changed it to nullbale because we don't have struct traits for
gpu::GPUInfo right now.

Change GPUInfo back. And use a empty GpuInfo for now.

Done

[Peng, 2016/06/03 18:34:07]

With chrome IPC command buffer, the client_id is used by client to generate a
unique command buffer id, the command buffer id is used for generating
SyncToken. I think the gpu process should be able to verify synctoken in the
command buffer.

piman@, Could you please comment on it? Thanks.

[piman, 2016/06/03 19:20:46]

The sync token is meant to indicate a particular point in the command stream of
a given client. client_id/command_buffer_id/release_id is the "path" to that
point. This is used to allow synchronization between different command streams -
a given command stream can "wait" for a particular point (represented by the
sync token) in another command stream - which means the later commands of the
first command stream will only execute after the commands of the second stream
before that particular point.

The goal is to allow the browser compositor to present a fully formed frame from
its client. Missing synchronization would mean that the graphics resources from
that client would appear corrupted: unfinished rendering, or early reuse of the
resource. But it doesn't give that client access to resources it shouldn't have
access to, or allow it to elevate privilege or anything.

If an untrusted client generates a sync token with an invalid client id, one of
2 things could happen:
- the token references an invalid stream, in which case the wait is ignored
(i.e. no worse than missing synchronization)
- the wait creates a dependency loop. the code detects this, by guaranteeing a
global order, where a wait is ignored if it references a point that is not
before it in the global order. So again, no worse than missing synchronization.

See
https://docs.google.com/document/d/1XwBYFuTcINI84ShNvqifkPREs3sw5NdaKzKqDDxye...
for more details.

 
   // Tells the GPU service to create a new GPU memory buffer.
   CreateGpuMemoryBuffer(GpuMemoryBufferId id,