From: Leah Rowe <info@minifree.org>
Subject: Re: mozilla port hardening, part II
To: "ports@openbsd.org" <ports@openbsd.org>
Date: Sat, 5 Sep 2026 19:29:51 +0100


tl;dr the patch is still garbage. stl-hardening option though is useful, 
and i don't think openbsd otherwise compensates for it being missing; it 
might be worth turning on. i haven't checked whether mozilla's codebases 
turns it on by default, but adding it can't hurt.

logically, i consider that if stl-hardening is present, then the normal 
hardening option might be as well, but i think probably it might be 
better to just directly audit the various mozilla build systems 
(thunderbird, firefox, seamonkey, tor browser) to see exactly what these 
options enable, and i mean surgically. and then add any of those to 
openbsd as desired, rather than --enable-hardening; this is because it's 
quite possible that --enable-hardening might be enabling options that 
reduce security, if openbsd is already being strict about that (via its 
modifications to llvm).

mach build system is just a mess in general imo. honestly, i'd just 
ignore the patch, if i were you. i'm just being thorough by sending it. 
merge it or don't :)


Am 05.09.26 um 17:11 schrieb Leah Rowe:
> Hi everyone!
>
> Here is a new version of the hardening patch I sent earlier, after 
> feedback on the original version. This adds the following options to 
> mozilla ports, where available:
>
> --enable-hardening
>
> --enable-stl-hardening
>
> --enable-rust-simd
>
> the rust simd and stl hardening options can be toggled, in this new 
> patch. i suppose a toggle could be added for --enable-hardening, but i 
> didn't bother
>
> Pros and cons of each is written inside the patch. I'll just paste 
> here what's written in my patch:
>
>     enable hardening flags in mozilla projects
>
>     there is also a rust-sized easter egg.
>
>     --enable-hardening appends these flags to CFLAGS, CXXFLAGS and 
> LDFLAGS at
>     build time:
>     * -fstack-protector-strong or -fstack-protector-all depending on 
> target
>     * -D_FORTIFY_SOURCE=2 - useless on openbsd
>     * fPIE - redundant here (forced by default on openbsd llvm/gcc)
>     * -Wl,-z,relro/now: redundant on openbsd
>     * -ftrapv or -fno-strict-overflow: treat signed integer overflow 
> as UB
>
>     OpenBSD will already do this by default, so this option is likely 
> redundant,
>     but ensures that Mozilla's build system will not *clear* any such 
> flags.
>
>     --enable-stl-hardening turns on safe mode and assertions inside 
> the C++
>     standard template library (STL) and catched out of bound 
> array/vector indexing,
>     iterator invalidation, null-pointer deref in stl containsers, and 
> invalid
>     ranges at runtime, mitigating them before they can be exploited. 
> specifically
>     enables these flags:
>     * for clang using libc++:
>      * -D_LIBCPP_ENABLE_HARDENED_MODE=1
>      * runtime bounds checks on std::vector::operator[], std::string,
>        std::optional, std::variants and iterator bounds checking
>
>     Enabling --enable-stl-hardening forces LLVM's libc++ to abort 
> immediately
>     if an STL container boundary violation occurs, e.g. calling
>     std::vector::operator out of range. This mitigates errors 
> pertaining to
>     heap corruption, though OpenBSD will already do something for this at
>     kernel level, e.g. pledge is basically the best thing ever.
>
>     --enable-rust-simd is an interesting one:
>     It can improve performance in some workloads by processing text, data
>     and images using hardware acceleration (simd) depending on the 
> machine.
>     This can cause massive throughput gains in e.g. encoding_rs when 
> decoding
>     web pages (converting raw html/js byte streams into utf/8/16). 
> Normally,
>     html/js markup contain a lot of ascii, and so you have ascii/utf-8 
> validation;
>     with the simd extension enabled, your browser processes text e.g. 
> 16 or 32
>     bytes at a time instead of 1 byte at a time, via hardware features
>     like sse/avx or neon. It's unknown whether this might negatively 
> impact older
>     systems, but this would have to be tested over time.
>
>     image/media processing: lots of this in gecko now are written in 
> rust, e.g.
>     png/jpg decoding, colour profile transformation, audio 
> re-sampling. simd
>     lets rust run identical operations e.g. alpha blending, byte 
> swapping, colour
>     conversion across entire blocks of pixels in a single cpu cycle, 
> instead of
>     doing everything in software. this obviously depends on the user's 
> machine.
>
>     faster cryptography/hashing: rust crates used for crypto, https 
> handshakes,
>     and internal structures e.g. fash hash tables, can use simd for 
> parallel
>     bitwise operations and byte shifts, reducing cpu overhead when 
> negotiating
>     connections and such.
>
>     Risks associated with --enable-rust-simd:
>
>     This turns on RUSTC_BOOTSTRAP=1. Despite the name, this doesn't 
> cause anything
>     to be downloaded, but it does allow certain nightly features to be 
> used
>     in Rust, that have not yet been declared stable. Turning this 
> option on will
>     bypass compiler safety checks to use experimental features, that 
> may break
>     after updates (e.g. newer rustc/cargo on older mozilla codebase; 
> disabling
>     simd on firefox/thunderbird ESR releases might be prudent). 
> obviously this
>     means that code generation might be a bit buggier, potentially 
> leading to
>     some UB. without this option enabled, rustc will be much more 
> conservative,
>     only generating code that will run on virtually any CPU. one of 
> the downsides
>     doesn't apply to openbsd: this option makes cross compilation less 
> reliable,
>     but openbsd doesn't use cross compilation anyway.
>
>     enable hardening flags in mozilla projects
>
>     there is also a rust-sized easter egg.
>
>     --enable-hardening appends these flags to CFLAGS, CXXFLAGS and 
> LDFLAGS at
>     build time:
>     * -fstack-protector-strong or -fstack-protector-all depending on 
> target
>     * -D_FORTIFY_SOURCE=2 - useless on openbsd
>     * fPIE - redundant here (forced by default on openbsd llvm/gcc)
>     * -Wl,-z,relro/now: redundant on openbsd
>     * -ftrapv or -fno-strict-overflow: treat signed integer overflow 
> as UB
>
>     OpenBSD will already do this by default, so this option is likely 
> redundant,
>     but ensures that Mozilla's build system will not *clear* any such 
> flags.
>
>     --enable-stl-hardening turns on safe mode and assertions inside 
> the C++
>     standard template library (STL) and catched out of bound 
> array/vector indexing,
>     iterator invalidation, null-pointer deref in stl containsers, and 
> invalid
>     ranges at runtime, mitigating them before they can be exploited. 
> specifically
>     enables these flags:
>     * for clang using libc++:
>      * -D_LIBCPP_ENABLE_HARDENED_MODE=1
>      * runtime bounds checks on std::vector::operator[], std::string,
>        std::optional, std::variants and iterator bounds checking
>
>     Enabling --enable-stl-hardening forces LLVM's libc++ to abort 
> immediately
>     if an STL container boundary violation occurs, e.g. calling
>     std::vector::operator out of range. This mitigates errors 
> pertaining to
>     heap corruption, though OpenBSD will already do something for this at
>     kernel level, e.g. pledge is basically the best thing ever.
>
>     --enable-rust-simd is an interesting one:
>     It can improve performance in some workloads by processing text, data
>     and images using hardware acceleration (simd) depending on the 
> machine.
>     This can cause massive throughput gains in e.g. encoding_rs when 
> decoding
>     web pages (converting raw html/js byte streams into utf/8/16). 
> Normally,
>     html/js markup contain a lot of ascii, and so you have ascii/utf-8 
> validation;
>     with the simd extension enabled, your browser processes text e.g. 
> 16 or 32
>     bytes at a time instead of 1 byte at a time, via hardware features
>     like sse/avx or neon. It's unknown whether this might negatively 
> impact older
>     systems, but this would have to be tested over time.
>
>     image/media processing: lots of this in gecko now are written in 
> rust, e.g.
>     png/jpg decoding, colour profile transformation, audio 
> re-sampling. simd
>     lets rust run identical operations e.g. alpha blending, byte 
> swapping, colour
>     conversion across entire blocks of pixels in a single cpu cycle, 
> instead of
>     doing everything in software. this obviously depends on the user's 
> machine.
>
>     faster cryptography/hashing: rust crates used for crypto, https 
> handshakes,
>     and internal structures e.g. fash hash tables, can use simd for 
> parallel
>     bitwise operations and byte shifts, reducing cpu overhead when 
> negotiating
>     connections and such.
>
>     Risks associated with --enable-rust-simd:
>
>     This turns on RUSTC_BOOTSTRAP=1. Despite the name, this doesn't 
> cause anything
>     to be downloaded, but it does allow certain nightly features to be 
> used
>     in Rust, that have not yet been declared stable. Turning this 
> option on will
>     bypass compiler safety checks to use experimental features, that 
> may break
>     after updates (e.g. newer rustc/cargo on older mozilla codebase; 
> disabling
>     simd on firefox/thunderbird ESR releases might be prudent). 
> obviously this
>     means that code generation might be a bit buggier, potentially 
> leading to
>     some UB. without this option enabled, rustc will be much more 
> conservative,
>     only generating code that will run on virtually any CPU. one of 
> the downsides
>     doesn't apply to openbsd: this option makes cross compilation less 
> reliable,
>     but openbsd doesn't use cross compilation anyway.
>
-- 
Company director, Minifree Ltd
Registered in England, No. 9361826 | VAT No. GB202190462
Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK