memory safety

Bilingual

Google fixed more Chrome bugs in June than over the past two years, thanks to AI
2 months ago
- Chrome uses AI-powered vulnerability detection, including LLMs like Gemini, to find and fix security bugs faster, with examples like Big Sleep and a sandbox escape bug that lasted 13 years.
- AI systems operate with safety guardrails: locked-down machines, no internet access, strict network allowlists, and no unrestricted mode.
- Automated triage processes filter noise, reproduce bugs, enrich metadata, and assign issues, saving hundreds of developer hours per month.
- Multi-agent workflows generate candidate fixes, evaluate them, and write tests, leading to 1072 security bugs fixed in Chrome 149/150, surpassing the previous 23 milestones combined.
- Release cadence is accelerating to two security updates per week, with dynamic patching to eliminate full browser restarts and auto-restart on macOS when no windows are open.
- Memory safety improvements include MiraclePtr, spanification, and structural hardening, alongside a shift to Rust for long-term resilience.
- AI-powered bug-finding is integrated into the commit queue to catch vulnerabilities before they land, including latent security issues from complex interactions.
- Chrome supports open source security via donations to Alpha-Omega and the Akrites project, and automates third-party dependency updates to reduce risk.
First CHERIoT Silicon
2 months ago
- SCI Semiconductor has produced the first silicon implementation of CHERIoT, called ICENI, moving beyond previous software and FPGA simulations.
- The ICENI chip is a complete CHERIoT system with core CHERI properties (spatial memory safety, no pointer injection) and extensions for deterministic use-after-free protection and interrupt control.
- It uses the CHERIoT Ibex core at up to 250 MHz, with features that accelerate temporal safety and improve interrupt determinism.
- Porting from CHERIoT SAFE or Sonata to ICENI for production use is straightforward, and software simulators should work without changes.
- The chip will be demonstrated at Embedded World, CHERI Blossoms, and the CHERI 15th anniversary exhibit in Cambridge.
"No way to prevent this" say users of only language where this regularly happens
2 months ago
- A critical vulnerability (CVE-2026-55200) in libssh2 causes heap corruption and remote code execution due to a missing upper bound check in the C code.
- The article satirically notes that such vulnerabilities occur only in C, which is responsible for 90% of memory safety vulnerabilities over the last 50 years.
- Programmers using C describe the situation as helpless, with no way to prevent these issues, echoing a common sentiment among the language's users.
Memory Safety’s Hardest Problem
2 months ago
- The hardest memory safety issue involves tagged unions where a pointer to internals of one variant is used after overwriting the union with a different variant, causing type confusion.
- This type confusion problem also affects Ada, as shown in an example link.
- In practice, the most exploitable memory errors are buffer overflows, which are trivially fixed with compiler-inserted bounds checks.
- The industry's major missed opportunity was not adopting Walter Bright's proposed array syntax (e.g., char a[..]) earlier, which could have prevented many issues.
"No way to prevent this" say users of only language where this regularly happens
2 months ago
- CVE-2026-8461 affects FFmpeg's MagicYUV decoder due to improper bounds checking in C code.
- The vulnerability causes heap corruption, denial of service, and potential remote code execution.
- The article satirically notes that C is the only language where such memory safety issues regularly occur.
- Programmers express helplessness, claiming nothing can prevent these vulnerabilities despite their frequency.
Memory Safety Absolutists
2 months ago
- The article discusses the claim that Rust is unsafe due to its 'unsafe' keyword, despite its drastically lower memory safety vulnerability density (0.2 per MLOC) compared to C/C++ (1000 per MLOC).
- Fil-C, a new technology, can make C/C++ code memory safe by using GC and InvisiCaps, but it has trade-offs like ABI incompatibility, potential slowdowns, and reliance on garbage collection.
- The author criticizes memory safety absolutists, especially Fil-C's creator and Zig's developer, who dismiss Rust as unsafe while promoting Fil-C, ignoring practical trade-offs and Rust's proven safety in real-world projects.
- A pragmatic approach is advocated: using Rust for programs that cannot adopt Fil-C (e.g., due to GC or ABI issues), and encouraging Fil-C for projects where its trade-offs are acceptable, rather than forcing a single solution.
- The author argues that memory safety absolutism should apply consistently, criticizing C/C++ and non-Fil Zig as much as Rust, and that preventing most issues in most programs is better than demanding perfection.
- Even with Fil-C turning vulnerabilities into crashes, the high crash rate from C/C++ code (1000 per MLOC) highlights that Rust's balance of safety and practicality is valuable for many use cases.
InvisiCaps: The Fil-C Capability Model
2 months ago
- Fil-C ensures memory safety via a capability system for pointers, dynamically tracking allowed objects and prohibiting out-of-bounds, use-after-free, and other unsafe accesses.
- InvisiCaps are the latest capability model, replacing PLUT, SideCaps, and MonoCaps, offering 64-bit pointers on 64-bit systems and reduced performance overhead to about 4x.
- InvisiCaps support meaningful union usage, thread safety, and flexible memory type reinterpretation without compromising safety.
- Each flight pointer has a trusted lower bound (for bounds checks) and an untrusted intval (the raw C pointer value); lower is immutable by the program.
- When pointers are stored to heap, the intval goes in the object payload and the lower in a separate aux allocation, keeping capabilities invisible to the program.
- Atomic pointers use atomic boxes for lock-free operations, while non-atomic pointers use a cheaper approach with aux allocations.
- Use-after-free is detected deterministically by setting the upper bound equal to the lower, causing a panic on access.
- The model is fanatically compatible, supporting even undefined behavior idioms, and is inspired by SoftBound and CHERI but with better thread safety and compatibility.
Introduce a memory safe compilation mode inspired by Fil-C
2 months ago
- Introduces a memory-safe compilation mode inspired by Fil-C, which differs from Rust by offering stronger memory safety guarantees without relying on unsafe code or escape hatches.
- Proposes a new ABI named 'fil' to implement Fil-C techniques, including invisicaps and syscall interception, for full memory safety across Zig and C/C++ dependencies.
- Aims to achieve memory safety with a performance penalty of 1-6x, preventing use-after-free and type confusion through unique type IDs and runtime pointer provenance checks.
- Discusses challenges such as intercepting all syscalls and inline assembly, while avoiding language changes by using compiler and standard library modifications.
- Highlights the potential for Zig to become a leading toolchain for memory-safe executables, even with C/C++ dependencies, surpassing Rust's safety in practice.
Clang: Hardware-Assisted AddressSanitizer Design Documentation
2 months ago
- HWASAN is a hardware-assisted memory safety tool similar to AddressSanitizer.
- It uses address tagging to tag memory objects and pointers with random tags.
- Memory accesses are instrumented to compare pointer tags with memory tags to detect mismatches.
- Short granules handle memory objects smaller than the tagging granularity by storing their tag in the last byte.
- Heap, stack, and global memory objects are tagged with specific strategies for each.
- HWASAN relies on hardware address tagging (AArch64) or page aliasing (x86_64), limiting its portability.
- It offers probabilistic bug detection with lower memory overhead compared to AddressSanitizer.
Returning to Zig
3 months ago
- The author was initially drawn to Zig in 2020 as a promising replacement for C, appreciating its compile-time code execution and simple abstractions.
- They left Zig due to instability, frequent breaking changes, and an immature ecosystem, switching to Rust for its stability and strong tooling.
- Concerns about Rust's governance, including corporate influence and slow response to LLM-generated code policies, led the author to reconsider Zig.
- In 2026, Zig remains unstable but familiar, with added features like a package manager, though its ecosystem is still limited compared to others.
- Zig prioritizes simplicity over Rust-like memory safety, using release modes and testing to ensure safety, which the author finds acceptable for certain use cases.
Memory Safe Context Switching
3 months ago
- Fil-C supports memory-safe context switching via longjmp/setjmp and ucontext APIs, preventing stack corruption.
- setjmp/longjmp are used for exception handling, while ucontext APIs (getcontext, setcontext, makecontext, swapcontext) implement coroutines/fibers.
- Fil-C makes setjmp/longjmp safe by storing jmp_buf as an opaque zjmp_buf, restricting direct calls, and validating stack frame ancestry.
- ucontext safety is achieved using opaque zfiber_context objects, a strict state machine, thread affinity, and GC integration with grey fiber tracking.
- The implementation ensures no misuse leads to dangling stack execution; unsafe operations cause panics or compile-time errors.
- GC integration handles fiber stacks during marking via grey fiber lists to prevent race conditions in on-the-fly garbage collection.
- Fil-C's ucontext support is available in glibc builds (from source after version 0.680), with setjmp/longjmp being more mature.
- Examples demonstrate how volatile variables and compiler optimizations affect setjmp behavior, emphasizing Fil-C's compliance with C semantics.

memory safety

Google fixed more Chrome bugs in June than over the past two years, thanks to AI

First CHERIoT Silicon

"No way to prevent this" say users of only language where this regularly happens

Memory Safety’s Hardest Problem

"No way to prevent this" say users of only language where this regularly happens

Memory Safety Absolutists

InvisiCaps: The Fil-C Capability Model

Introduce a memory safe compilation mode inspired by Fil-C

Clang: Hardware-Assisted AddressSanitizer Design Documentation

Returning to Zig

Memory Safe Context Switching