Rust's Real World Wins in Blink [BlinkOn 21]

Overview (Rust in Blink/Chrome)

The talk (BlinkOn 21) covers Rust projects already shipping in Blink/Chrome, plus tooling and process for integrating Rust, focusing on real-world performance and security outcomes.

---

Shipping Rust projects in Blink/Chrome

1) Fontations (memory-safe font stack)

• Goal: Provide a memory-safe, open-source web font stack in Rust, replacing parts of the FreeType-based pipeline.
• What shipped / status:
  • FreeType removal is gradual:
    • Not fully gone yet because PDFium still requires FreeType.
    • FreeType has been removed from Blink files; Android already ships without FreeType.
    • In Chrome H25, FreeType was removed from Blink.
• Security impact: Ending a stream of security issues previously associated with FreeType.
• Performance:
  • No stated regression.
  • Font behaviors differ slightly (e.g., auto-hinting may be slower).
• Unsafe handling:
  • Some functionality uses encapsulated unsafe, reportedly limited to specific areas (e.g., encapsulated into a bitemark crate; most higher-level code is safe).

2) XML parsing in Rust (XML document parser)

• Problem: libxml2 / libxslt were not well maintained (maintainer stepped back).
• Browser response: Blink and other vendors deprecate XSLT and improve XML parsing security.
• Rust approach:
  • Implemented xml document parser rs (a Rust analog of XMLDocumentParser-style functionality) to:
    • Parse raw XML strings into DOM structures used by Blink.
• Performance: Currently shows a regression in Blink microbenchmarks, under evaluation for “guardrail metrics” / shippability (mentioned example figure: ~1% stable at ~147).
• Security impact: Moves parsing to memory-safe code, aiming to eliminate libxml2 XML parsing-related memory corruption concerns after broader deprecation.

3) Rust PNG decoding (replacing libpng in multiple components)

• Scope: Replace libpng in:
  • Blink
  • then also Chromium
  • and PDFium
• Performance results at ship time:
  • Windows: decoding ~15% faster
  • Android: slightly slower
• Follow-ups: Later performance improvements, including SIMD on ARM in select places.
• Security posture (pragmatic reasoning):
  • Initial motivation wasn’t primarily security.
  • They cite prior PNG CVs as mostly not exploitable (e.g., DoS-like), noting difficulty in predicting security based only on historical CV presence.
  • Key Rust claim: memory safety reduces risk of undefined behavior / memory safety issues.
• Coordination: Cooperation between Chrome security and Skia teams; Skia provided guidance/review and long-term maintenance via upstream crate quality.

4) Additional Rust-related work mentioned

• Microsoft/Edge security team contributions:
  • Transitioning BMP decoder to Rust
  • Work on ICO decoder
  • Using a Rust crate for ICC/Color profile parsing
  • Exploring other areas like the brotli decompression library (referred to as a “broadly decompression library”)

---

Tooling & process for integrating Rust into Chrome

Relaxed approval process for Rust usage

Rust usage in Chrome was eased from:

• requiring approval of every Rust usage by ATLS to:

• not requiring an FYI email to engineering director

• trusting code owners who maintain/own the code to decide if Rust is appropriate

Still required:

• Third-party library review for non-Rust-specific concerns (e.g., binary size impact).
• Rust-specific checks are lighter because:
  • Licensing checked by tooling
  • Security review mostly waived
  • Lightweight unsafe review
  • Updates handled via “guardian rotation”

Importing a Rust crate into Chromium (3 steps)

1. Edit cargo.toml in the Chromium repo Example: add a dependency on the Rust crate (e.g., xml crate), selecting allowed versions and optionally enabling/disabling crate features to avoid unused deps. Cargo config supports typical Rust tooling workflows (like dependency inspection).

2. Vendor the crate / download into a vendor directory Ensures Chromium and related second-party projects (e.g., V8, ANGLE, PDFium) use unified crate versions and features, avoiding duplicated crate versions across repos.

3. Generate build files Uses templates (e.g., handlebars + supplementary TOML) so tweaks don’t necessarily require changes to tooling itself.

Calling Rust from C++: cxxbridge

The recommended integration path in Chrome is cxx bridge tool.

Key characteristics:

• #[cxxbridge] declares which Rust items are exposed to C++.
• Bridge macro expansion generates Rust-side bindings; a separate tool generates the C++ side.
• Communicates via a C ABI layer.

---

FFI design learnings / constraints (C++ ↔ Rust)

Restrictions of the CXX bridge tool

• Limited support for deeply nested Rust structures to be represented on the C++ side.

Practical patterns

• Use POD-like structs (non-nested) for shared data.
• For Rust Result<T, E>:
  • No direct mapping to CXX exceptions (Blink C++ avoids exceptions)
  • Prefer C-style status codes / patterns.
• For Rust Option<T>:
  • No built-in mapping; prefer boolean/integer status or wrapper patterns.
• For complex/nested or variable-sized data:
  • Often invert control: Rust calls into C++ “producer” functions to build nested structures on the C++ side (example: passing font parsing info into Skia structures).
• For iterators:
  • Use opaque Rust handles plus explicit next() functions over an FFI iterator.
  • Iterators can’t be restarted without reconstructing/initializing them.

---

Unsafe in Rust: performance and policy

Does Rust require unsafe for performance?

• Not necessarily.
• They argue you can get good performance without unsafe, depending on crates and implementation choices.
• Examples mentioned:
  • PNG/deflate crates avoid unsafe; SIMD may use safe/declarative approaches (e.g., auto-vectorization).
  • XML crate performance issues were attributed to architecture/history differences rather than unsafe usage.

Why unsafe still appears

• In Fontations, some unsafe is needed for interoperability/casting/transmute-like operations.
• Approach: encapsulate unsafe inside narrow internal crates/APIs, exposing safe public APIs.

Policy for first-party use of unsafe

• Ultimate responsibility is delegated to code owners.
• Chrome added support for running Clippy lints for Rust, including:
  • requiring safety documentation for functions marked unsafe/traits/etc.
  • requiring call sites to include concise comments explaining why safety requirements are met
• They reference an official Rust policy document (“docs rust … unsafe code …”), but emphasize delegation/auditing in practice.

---

Supply-chain risk discussion (crates.io poisoning)

A question was raised about supply chain attacks (malicious/hijacked crates). The response highlights:

• Chromium takes snapshots:
  • crates are downloaded initially, then uploaded and copied into Chromium’s repository.
• Crate versions don’t auto-roll every build:
  • updates use manual team rotation and review steps.
• There is an inherent implicit trust model, but trusted crates may come from teams already trusted in other parts of the stack (e.g., for Rust compiler/standard library components).

---

Main speaker/source list

• Dominic — works in Blink style and fonts team; involved in Rust font stack and XML security integration.
• Lucas — Chrome Rust team (Security); discussed Rust PNG decoding integration, tooling process, and unsafe/performance/security considerations.