JavaScript内核与高级编程之：`JavaScript`的`SharedArrayBuffer`：其在`Chrome`和`Firefox`中的安全限制。 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

大家好，今天我们来聊聊 JavaScript 里一个相当有趣，也相当有争议的东西：SharedArrayBuffer。这玩意儿就像一个在多个线程之间共享的秘密基地，但因为一些历史遗留问题，它也戴上了一些“安全帽”，变得有点难伺候。

开场白：多线程的美好愿景与现实的骨感

在 JavaScript 的世界里，我们通常活在一个单线程的舒适区里。这意味着我们的代码像一条直线一样执行，一次只做一件事。但有时候，我们需要同时处理多个任务，比如并行计算大量的图像数据，或者在不阻塞主线程的情况下进行复杂的动画渲染。这时候，多线程就成了救星。

Web Workers 给了我们创建“子线程”的能力，但这些子线程之间默认是完全隔离的，只能通过消息传递来交换数据。这就像两个国家，只能通过外交信件来交流，效率不高。SharedArrayBuffer 就是为了打破这种限制而生的，它允许我们在主线程和 Web Workers 之间共享内存，实现真正的并行计算。

SharedArrayBuffer：共享内存的钥匙

SharedArrayBuffer 本质上是一个 ArrayBuffer 对象，但它可以在多个线程之间共享。这意味着我们可以让不同的线程同时访问和修改同一块内存区域，从而实现更高效的并发。

// 创建一个 SharedArrayBuffer
const sab = new SharedArrayBuffer(1024); // 1KB 的共享内存

// 在主线程中创建一个 Int32Array 视图
const view1 = new Int32Array(sab);

// 创建一个 Web Worker
const worker = new Worker('worker.js');

// 将 SharedArrayBuffer 发送给 Web Worker
worker.postMessage(sab);

// 接收来自 Web Worker 的消息
worker.onmessage = function(event) {
  console.log('主线程接收到消息:', event.data);
  console.log('SharedArrayBuffer 的值:', view1[0]);
};

// 在主线程中修改 SharedArrayBuffer 的值
view1[0] = 42;
console.log('主线程修改 SharedArrayBuffer 的值:', view1[0]);
worker.postMessage("change");

在 worker.js 中：

// 接收来自主线程的 SharedArrayBuffer
onmessage = function(event) {
  if(event.data instanceof SharedArrayBuffer){
    const sab = event.data;
    const view2 = new Int32Array(sab);
    console.log('Worker 线程接收到 SharedArrayBuffer:', view2[0]); // 应该输出 42

    onmessage = function(event){
      if(event.data == "change"){
         view2[0] = 100;
         console.log('Worker 线程修改 SharedArrayBuffer 的值:', view2[0]);
         postMessage("changed");
      }

    }

  } else{
    console.log('Worker 线程接收到消息:', event.data);
  }
};

在这个例子中，我们首先创建了一个 SharedArrayBuffer，然后在主线程和 Web Worker 中分别创建了 Int32Array 视图。通过 postMessage 将 SharedArrayBuffer 发送给 Web Worker 后，两个线程就可以同时访问和修改同一块内存区域了。

原子操作：保证数据一致性的护盾

当多个线程同时访问和修改共享内存时，可能会出现数据竞争的问题。例如，如果两个线程同时尝试修改同一个变量，可能会导致最终的结果不正确。为了解决这个问题，JavaScript 提供了原子操作。

原子操作是一组不可分割的操作，它们要么全部执行，要么全部不执行。这意味着在原子操作执行期间，其他线程无法访问和修改相关的数据，从而保证了数据的一致性。

JavaScript 中提供了 Atomics 对象，它包含了一系列原子操作方法，例如 Atomics.add(), Atomics.sub(), Atomics.load(), Atomics.store() 等。

// 使用原子操作增加 SharedArrayBuffer 中的值
Atomics.add(view1, 0, 1); // 将 view1[0] 的值原子地增加 1
console.log('主线程使用原子操作修改 SharedArrayBuffer 的值:', view1[0]);

安全限制：幽灵的阴影

SharedArrayBuffer 的出现原本是一件好事，但因为一些安全漏洞，它也经历了一段坎坷的道路。其中最著名的就是“幽灵（Spectre）”漏洞。

幽灵漏洞是一种利用 CPU 推测执行机制的侧信道攻击。简单来说，CPU 为了提高效率，会提前猜测程序的执行路径，并执行相应的指令。如果猜测错误，CPU 会回滚操作，但在这个过程中，可能会留下一些痕迹，攻击者可以利用这些痕迹来推断出程序的敏感数据。

SharedArrayBuffer 与高精度计时器（如 performance.now()）结合使用时，可以放大幽灵漏洞的影响。攻击者可以通过测量访问 SharedArrayBuffer 的时间来推断出其他进程的内存布局和数据。

Chrome 和 Firefox 的应对措施

为了应对幽灵漏洞，Chrome 和 Firefox 都采取了一些安全措施，限制了 SharedArrayBuffer 的使用。

COOP/COEP 策略：
- COOP (Cross-Origin-Opener-Policy): 控制不同源的文档如何互相访问。
- COEP (Cross-Origin-Embedder-Policy): 限制页面可以嵌入的跨域资源。
要启用 SharedArrayBuffer，你需要确保你的网站使用了 Cross-Origin-Opener-Policy: same-origin 和 Cross-Origin-Embedder-Policy: require-corp 这两个 HTTP 头部。简单理解，就是你需要告诉浏览器：“嘿，我这个网站很安全，只允许同源的访问，并且只嵌入明确声明的跨域资源。”

如果不设置这些头部，SharedArrayBuffer 将会被禁用，你会看到类似这样的错误信息：

SharedArrayBuffer will require cross-origin isolation as of M92, which requires the Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp headers.
时间精度限制：

为了防止利用高精度计时器进行攻击，浏览器降低了 performance.now() 的精度。这意味着攻击者无法精确地测量访问 SharedArrayBuffer 的时间，从而降低了攻击的成功率。

如何正确使用 SharedArrayBuffer？

虽然 SharedArrayBuffer 的使用受到了一些限制，但只要遵循一些最佳实践，仍然可以在安全的前提下使用它。

启用 COOP/COEP： 这是使用 SharedArrayBuffer 的前提条件。确保你的服务器正确设置了 Cross-Origin-Opener-Policy 和 Cross-Origin-Embedder-Policy 头部。

例如，在 Nginx 中可以这样配置：
```
location / {
    add_header "Cross-Origin-Opener-Policy" "same-origin";
    add_header "Cross-Origin-Embedder-Policy" "require-corp";
    # ... 其他配置
}
```
谨慎使用高精度计时器： 尽量避免在需要保护敏感数据的代码中使用 performance.now()。如果必须使用，考虑使用一些方法来降低计时器的精度，例如添加一些随机延迟。
使用原子操作： 当多个线程同时访问和修改共享内存时，务必使用原子操作来保证数据的一致性。
进行代码审查： 仔细审查你的代码，确保没有潜在的安全漏洞。

示例：使用 COOP/COEP 的简单例子

假设你有一个简单的 HTML 文件 index.html 和一个 JavaScript 文件 script.js，以及一个 Web Worker 文件 worker.js。

index.html:

<!DOCTYPE html>
<html>
<head>
  <title>SharedArrayBuffer Example</title>
</head>
<body>
  <h1>SharedArrayBuffer Example</h1>
  <script src="script.js"></script>
</body>
</html>

script.js:

const sab = new SharedArrayBuffer(1024);
const view = new Int32Array(sab);
view[0] = 1;

const worker = new Worker('worker.js');
worker.postMessage(sab);

worker.onmessage = function(event) {
  console.log('主线程接收到消息:', event.data);
  console.log('SharedArrayBuffer 的值:', view[0]);
};

worker.js:

onmessage = function(event) {
  const sab = event.data;
  const view = new Int32Array(sab);
  console.log('Worker 线程接收到 SharedArrayBuffer:', view[0]);
  view[0] = 2;
  postMessage('Worker 线程修改了 SharedArrayBuffer');
};

要让这个例子正常工作，你需要配置你的服务器，添加 COOP 和 COEP 头部。如果你使用 Node.js 和 Express，可以这样做：

const express = require('express');
const app = express();
const port = 3000;

app.use(function(req, res, next) {
  res.setHeader("Cross-Origin-Opener-Policy", "same-origin");
  res.setHeader("Cross-Origin-Embedder-Policy", "require-corp");
  next();
});

app.use(express.static('.')); // 假设你的文件都在当前目录下

app.listen(port, () => {
  console.log(`Example app listening at http://localhost:${port}`);
});

SharedArrayBuffer 的替代方案

如果由于安全限制或其他原因，你无法使用 SharedArrayBuffer，还有一些替代方案可以考虑：

方案	优点	缺点
Message Passing	安全性高，易于理解和调试	效率较低，需要进行数据序列化和反序列化
Offscreen Canvas	可以将复杂的图形渲染任务转移到 Web Worker 中，避免阻塞主线程	仍然需要使用 Message Passing 来交换数据，不如 `SharedArrayBuffer` 灵活
WebAssembly (WASM)	可以使用多线程，性能高	学习曲线较陡峭，需要使用 C/C++ 或 Rust 等语言编写代码

总结：拥抱挑战，安全前行

SharedArrayBuffer 是一把双刃剑。它带来了多线程编程的可能性，但也引入了新的安全风险。我们需要认真对待这些风险，并采取相应的措施来保证代码的安全性。

虽然 Chrome 和 Firefox 的安全限制给 SharedArrayBuffer 的使用带来了一些麻烦，但这并不意味着我们应该放弃它。只要我们理解了这些限制，并遵循最佳实践，仍然可以安全地使用 SharedArrayBuffer，并从中受益。记住，技术的进步总是伴随着挑战，而我们需要做的就是拥抱挑战，不断学习，安全前行。

好了，今天的讲座就到这里。希望大家有所收获！下次有机会再和大家聊聊其他有趣的 JavaScript 话题。

发表回复 取消回复

发表回复取消回复