内存安全的 WebP 解码器

# 发布 wpd | Halide Compression Source: https://halide.cx/blog/wpd/ 我们构建的 wpd 是一个比 libwebp 更快、更安全的 WebP 解码器，旨在帮助加固网络，抵御类似 CVE-2023-4863 (https://nvd.nist.gov/vuln/detail/cve-2023-4863) 这类漏洞的威胁。与此同时，wpd 并不只是维持原有的速度水准；它在单线程性能上更胜一筹，并且在多线程场景下相比其他替代方案有更好的并行扩展能力。 源代码：https://github.com/halidecx/wpd ## 安全性 图像解码器和其他图像处理库无处不在，从操作系统层面到沙箱化的浏览器进程都在使用它们。它们处理的往往是复杂的、不可信的输入数据，这使得它们容易受到内存安全缺陷的影响。CVE-2023-4863 影响了运行着 Chrome、Firefox、Signal、Microsoft Teams 等软件的潜在数十亿台设备——CISA 证实该漏洞已被在野利用，并随后将其列入已知被利用漏洞（Known Exploited Vulnerabilities）目录。此类漏洞几乎对所有消费级硬件都会造成严重后果。 虽然 libwebp 相比过去很可能更加安全，但仅靠大量模糊测试（fuzzing）并不能"解决"内存安全问题。根据 Chromium 团队的说法，约 70% (https://www.chromium.org/Home/chromium-security/memory-safety/) 的高危安全问题来自内存安全缺陷。 为此，wpd 使用 Rust 编写，并为性能手工编写了汇编例程。解码器中的手写 SIMD 经过仔细的作用域界定与正确性校验，且主要存在于风险较低的位置。即便如此，对于希望进一步加固自身环境的使用者，wpd 也可以在不包含手写汇例程的情况下编译；这样一来，我们编写的非 SIMD 代码就完全可验证地具备内存安全性，唯一的 unsafe 代码位于经过审核的 zerocopy (https://docs.rs/zerocopy/latest/zerocopy/) crate 中。相比完全由 unsafe C 加 SIMD intrinsic 编写的 libwebp，这是一处显著的改进。 ### 性能 仅仅更安全是不够的；image-webp (https://crates.io/crates/image-webp) 在这一点上已经做到了。我们还需要让 wpd 更快，因此安全性并没有以牺牲性能为代价。 我们在自己的开发者测试数据（https://github.com/halidecx/wpd-test-data）的一个子集上对 wpd 进行了基准测试，与 libwebp 相比，wpd 的速度是： - 单线程、有损：**1.19 倍** 更快 - 单线程、无损：**2.74 倍** 更快 - 多线程、有损：**2.68 倍** 更快 - 多线程、无损：**3.19 倍** 更快 由于我们的测试套件混合了动画 WebP 内容与静态内容，多线程结果得益于并行图像解码，因此在这一项上的提升更为亮眼。而我们的单线程优势则是纯粹的算法改进。 这些数字来自 wpd 仓库中的基准测试框架，使用 image-webp 0.2.4 和 libwebp`a1d89ff` 得出。 ### 特性 与 libwebp 达到特性对等同样是 wpd 的目标，因为每一个依赖 libwebp 的使用场景都值得一次升级。与 image-webp 相比，wpd 是一个名副其实的 libwebp 替代品，并在其基础上提供了一些额外功能： | 解码器特性 | image-webp | libwebp | wpd | | --- | --- | --- | --- | | 有损 WebP | ☑ | ☑ | ☑ | | 无损 WebP | ☑ | ☑ | ☑ | | Alpha 透明 | ☑ | ☑ | ☑ | | 合成帧动画 | ☑ | ☑ | ☑ | | 动画时长与循环次数 | ☑ | ☑ | ☑ | | 动画回退/重置 | ☑ | ☑ | ☑ | | 原始动画子帧解码 | ☐ | ⚠¹ | ☑ | | 不解码即可检查每帧几何、混合与处置信息 | ☐ | ☑ | ☑ | | 不解码即可检查图像尺寸与 alpha | ☑ | ☑ | ☑ | | ICC、EXIF 与 XMP 提取 | ☑ | ☑ | ☑ | | RGB/RGBA 输出 | ☑ | ☑ | ☑ | | BGR/BGRA/ARGB 输出 | ☐ | ☑ | ☑ | | 预乘 alpha 输出 | ☐ | ☑ | ☑ | | YUV420P 输出 | ⚠² | ☑ | ☑ | | YUVA420P 输出 | ☐ | ☑ | ☑ | | RGB565 与 RGBA4444 输出 | ☐ | ☑ | ☑ | | BGR565 与 BGRA4444 输出 | ☐ | ☐ | ☑ | | 内置裁剪 | ☐ | ☑ | ☑ | | 内置缩放 | ☐ | ☑ | ☑ | | 自动保持纵横比的缩放 | ☐ | ☑ | ☑ | | 垂直翻转 | ☐ | ☑ | ☑ | | 可选简单/精细色度上采样 | ☑ | ☑ | ☑ | | 可选跳过有损环路内滤波 | ☑ | ☑ | ☑ | | 颜色/alpha 抖动控制 | ☑ | ☐ | ☑ | | 通过追加字节进行增量解码 | ☑ | ☑ | ☑ | | 通过累积借用缓冲区进行增量解码 | ☐ | ☑ | ☑ | | 在静态图像解码完成前访问已完成的行 | ☐ | ☑ | ☑ | | 调用方自有输出缓冲区 | ☐ | ☑ | ☑ | | 可配置输出行跨度（含负跨度） | ☐ | ☑ | ☑ | | 内部多线程解码 | ☐ | ☑ | ☑ | | 显式线程数设置 | ☐ | ☐³ | ☑ | | 动画帧并行预取解码 | ☐ | ☐ | ☑ | | 帧分配/解码前可配置的像素数量上限 | ☐ | ☐ | ☑ | | 显式优化的 SIMD 实现 | ☐ | ☐ | ☑ | | C ABI | ☐ | ☑ | ☑ | | Rust API | ☑ | ☐ | ☑ | 1. 需要先对帧负载进行解封装（demux），再将其传给图像解码器。它的动画解码器返回合成后的画布。 2. 由其底层 VP8 解码器暴露；调用方必须自行从 WebP 容器中提取 VP8 负载。它完整的 WebP 解码器输出 RGB/RGBA。 3. 只暴露一个用于启用多线程的布尔开关，而非请求的线程数。 「格式」与「处理」两栏描述的是静态图像相关能力。libwebp 包含 libwebpdemux；其合成动画 API 支持的格式和选项更少。wpd 的子帧模式不包含裁剪/缩放/翻转，其部分行 API 则不支持动画和变换后的输出。 ### 目标 我们希望尽可能多地回馈开源。这个项目是我们开源目录中的第三个成员，与 fcvvdp (https://halide.cx/blog/fcvvdp) 和 fmetrics (https://halide.cx/blog/fmetrics) 并列。wpd 的发布意味着我们拥有的主要开源项目数量正式超过了闭源项目（Iris-WebP 和目前尚未发布的 Aperture）。我们希望这一比例未来能进一步向开源倾斜，而我们也始终承诺将我们的开源作品作为一等支持目标来维护，与我们的闭源编码器并无二致。 为了进一步推进 wpd 的安全目标，我们正在与那些有兴趣加固全球最关键软件的网络安全公司探讨合作。我们希望每个人今天就能免费使用 wpd；如果有什么阻碍了你，请随时告诉我们那是什么，我们会去解决（或者，你也可以自己提交一些代码！） 我们期待看到人们开始使用 wpd。它采用我们所能争取到的最宽松的开源许可——BSD 2-Clause。如果你一直在关注我们的进展，我们很快还会再与你联系，敬请期待——希望你会觉得 wpd 有价值！