Chromium side of RequestDeviceOptions implementation.

device/bluetooth/bluetooth_uuid.cc

 // Copyright 2014 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 "device/bluetooth/bluetooth_uuid.h"
 
 #include "base/basictypes.h"
 #include "base/logging.h"
 #include "base/strings/string_util.h"
+#include "ipc/ipc_message.h"
 
 namespace device {
 
 namespace {
 
 const char* kCommonUuidPostfix = "-0000-1000-8000-00805f9b34fb";
 const char* kCommonUuidPrefix = "0000";
 
 // Returns the canonical, 128-bit canonical, and the format of the UUID
 // in |canonical|, |canonical_128|, and |format| based on |uuid|.
@@ skipping 66 matching lines @@
 
 bool BluetoothUUID::operator!=(const BluetoothUUID& uuid) const {
   return canonical_value_ != uuid.canonical_value_;
 }
 
 void PrintTo(const BluetoothUUID& uuid, std::ostream* out) {
   *out << uuid.canonical_value();
 }
 
 }  // namespace device
+
+void IPC::ParamTraits<device::BluetoothUUID>::Write(Message* m,
+                                                    const param_type& p) {
+  m->WriteString(p.canonical_value());
+}
+
+bool IPC::ParamTraits<device::BluetoothUUID>::Read(const Message* m,
+                                                   base::PickleIterator* iter,
+                                                   param_type* r) {
+  std::string value;
+  if (!iter->ReadString(&value))
+    return false;
+  *r = device::BluetoothUUID(value);
+  // If the format isn't 128-bit, .value() would return a different answer than
+  // .canonical_value(). Then if browser-side code accidentally checks .value()
+  // against a 128-bit string literal, a hostile renderer could use the 16- or
+  // 32-bit format and evade the check.
+  return r->format() == device::BluetoothUUID::kFormat128Bit;

[armansito, 2015/06/23 18:24:28]

I'm not fully understanding the necessity for this check for readers who aren't
familiar with the IPC code? Why not always construct and return a BluetoothUUID
in 128-bit format?

[scheib, 2015/06/23 18:33:27]

A correctly running renderer will construct a 128bit format above. However, a
compromised renderer can send whatever data it pleases. This check verifies that
an attacking renderer is not intentionally sending another format to confuse the
browser.

[Jeffrey Yasskin, 2015/06/24 21:04:25]

Yeah, we could recover from a non-128-bit message by writing "*r =
device::BluetoothUUID(r->canonical_value())", but since only a broken renderer
would send that, it doesn't seem worth the extra code. 

Even if we didn't check for the 128-bit format, we have to check for
r->IsValid() somewhere, and it may as well be while receiving the IPC instead of
every place in the browser that tries to use the data.

[armansito, 2015/06/24 21:26:43]

Got it. If that's the consensus on what the IPC behavior should be, then sgtm.

+}
+
+void IPC::ParamTraits<device::BluetoothUUID>::Log(const param_type& p,
+                                                  std::string* l) {
+  l->append(p.canonical_value());
+}