Adds Mojo IDL.

third_party/WebKit/Source/core/mojo/Mojo.cpp

+// 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.
+
+#include "core/mojo/Mojo.h"
+
+#include "bindings/core/v8/ArrayBufferOrArrayBufferView.h"
+#include "core/dom/DOMArrayBuffer.h"
+#include "core/dom/DOMArrayBufferView.h"
+#include "core/mojo/MojoCreateMessagePipeOptions.h"
+#include "core/mojo/MojoCreateMessagePipeResult.h"
+#include "core/mojo/MojoHandle.h"
+#include "core/mojo/MojoReadMessageResult.h"
+#include "core/mojo/MojoWatcher.h"
+
+// Mojo messages typically do not contain many handles. In fact most
+// messages do not contain any handle. An inline capacity of 4 should avoid
+// heap allocation in vast majority of cases.
+static const size_t kHandleVectorInlineCapacity = 4;
+
+namespace blink {
+
+Mojo* Mojo::create() {
+  return new Mojo();
+}
+
+MojoWatcher* Mojo::watch(ScriptState* scriptState,
+                         MojoHandle* handle,
+                         MojoHandleSignals signals,
+                         MojoWatchCallback* callback) {
+  return MojoWatcher::create(handle->get(), signals, scriptState, callback);
+}
+
+void Mojo::createMessagePipe(const MojoCreateMessagePipeOptions& optionsDict,
+                             MojoCreateMessagePipeResult& resultDict) {
+  ::MojoCreateMessagePipeOptions options = {0};
+  options.struct_size = sizeof(::MojoCreateMessagePipeOptions);
+  options.flags = optionsDict.flags();
+
+  mojo::ScopedMessagePipeHandle handle0, handle1;
+  MojoResult result = mojo::CreateMessagePipe(&options, &handle0, &handle1);
+
+  resultDict.setResult(result);
+  if (result == MOJO_RESULT_OK) {
+    resultDict.setHandle0(
+        MojoHandle::create(mojo::ScopedHandle::From(std::move(handle0))));
+    resultDict.setHandle1(
+        MojoHandle::create(mojo::ScopedHandle::From(std::move(handle1))));
+  }
+}
+
+MojoResult Mojo::writeMessage(MojoHandle* pipe,
+                              ArrayBufferOrArrayBufferView& buffer,
+                              const HeapVector<Member<MojoHandle>>& handles,
+                              MojoWriteMessageFlags flags) {
+  // MojoWriteMessage takes ownership of the handles, so release them here.
+  Vector<::MojoHandle, kHandleVectorInlineCapacity> rawHandles(handles.size());
+  for (auto& handle : handles)
+    rawHandles.append(handle->release().value());

[jbroman, 2016/12/20 23:21:57]

I don't think this does what you want. This creates a vector with
|handles.size()| zero-initialized handles followed by |handles.size()| released
from |handles|. I think you want to do something like below: either using a for
loop over the indices, or (my personal preference) std::transform from
<algorithm>.

[alokp, 2017/01/09 23:33:09]

good catch - done.

+
+  const void* bytes = nullptr;
+  uint32_t numBytes = 0;
+  if (buffer.isArrayBuffer()) {
+    DOMArrayBuffer* array = buffer.getAsArrayBuffer();
+    bytes = array->data();
+    numBytes = array->byteLength();
+  } else {
+    DCHECK(buffer.isArrayBufferView());

[jbroman, 2016/12/20 23:21:57]

For what it's worth, this is already DCHECKed inside getAsArrayBufferView.

[alokp, 2017/01/09 23:33:09]

Removed redundant DCHECK

+    DOMArrayBufferView* view = buffer.getAsArrayBufferView();
+    bytes = view->baseAddress();
+    numBytes = view->byteLength();
+  }
+
+  return MojoWriteMessage(pipe->value(), bytes, numBytes, rawHandles.data(),
+                          rawHandles.size(), flags);

[jbroman, 2016/12/20 23:21:57]

Here and elsewhere: this exposes access to pass arbitrary parameters to the Mojo
EDK. I am assuming this is an interface that will only be used in contexts
running only trusted script? If not, has security team signed off on allowing
whatever scripts this interface is available in to send arbitrary IPC messages
with arbitrary flags?

[alokp, 2017/01/09 23:33:09]

This will only be used for trusted script. I would still be curious to know
about the security implications. IIUC the service side closes the pipe upon
receiving invalid messages.

[jbroman, 2017/01/10 20:46:30]

I'm not a security engineer, but yes, I think that will protect the service
side. Escaping from JavaScript to compromise the renderer would still be bad.
I'm concerned about whether these core Mojo methods could corrupt state inside
the process if given invalid arguments, and whether that might possible allow
the script to compromise the renderer. A compromised renderer is still fairly
powerful (e.g. it may hold some cross-origin cookies).

Generally our C++ API methods don't assume an adversarial caller, but calls from
JS script contexts (notably those that may have untrusted script running in
them) must be treated with greater suspicion.

[alokp, 2017/01/11 21:53:01]

Acknowledged. I will add tsepez@ as reviewer once this patch is ready for
security review.

+}
+
+void Mojo::readMessage(MojoHandle* pipe,
+                       MojoReadMessageFlags flags,
+                       MojoReadMessageResult& resultDict) {
+  uint32_t numBytes = 0, numHandles = 0;
+  MojoResult result = MojoReadMessage(pipe->value(), nullptr, &numBytes,
+                                      nullptr, &numHandles, flags);
+  if (result != MOJO_RESULT_RESOURCE_EXHAUSTED) {
+    resultDict.setResult(result);
+    return;
+  }
+
+  DCHECK_GT(numBytes, 0u);
+  DOMArrayBuffer* buffer = DOMArrayBuffer::createUninitialized(numBytes, 1);
+  Vector<::MojoHandle, kHandleVectorInlineCapacity> rawHandles(numHandles);
+  result = MojoReadMessage(pipe->value(), buffer->data(), &numBytes,
+                           rawHandles.data(), &numHandles, flags);
+
+  HeapVector<Member<MojoHandle>> handles(numHandles);
+  for (size_t i = 0; i < numHandles; ++i) {
+    handles[i] =
+        MojoHandle::create(mojo::MakeScopedHandle(mojo::Handle(rawHandles[i])));
+  }
+
+  resultDict.setResult(result);
+  resultDict.setBuffer(buffer);
+  resultDict.setHandles(handles);
+}
+
+}  // namespace blink