Re: mozilla port hardening, part II

[Leah Rowe]

bonus: python




Am 08.09.26 um 11:39 schrieb Leah Rowe:

i mean, i hate python too, but at least they don't seem to actually be using autoconf here. i call it autohell.

hi

because i'm bored, i actually checked inside firefox.git






    if using_msvc_stl_202503_or_newer:
        return ["-D_MSVC_STL_HARDENING=1"]
    if using_libstdcxx:
        return ["-D_GLIBCXX_ASSERTIONS=1"]
    if using_libcxx:
        if using_libcxx_19_or_newer:
            if debug:

            else:

        else:
            return ["-D_LIBCPP_ENABLE_ASSERTIONS=1"]





as for --enable-hardening, i see:

        if compiler_is_gccish and not asan:
            flags.append("-fstack-protector-strong")
            ldflags.append("-fstack-protector-strong")

            if (
                c_compiler.type == "clang"
                and target.os not in ("WINNT", "OSX", "OpenBSD", "iOS")

                    or

            ):
                flags.append("-fstack-clash-protection")
                ldflags.append("-fstack-clash-protection")

NOTE: in our context, llvm/clang/etc is indeed "gccish"

        linux32 = target.kernel == "Linux" and target.cpu == "x86"
        if (
            (c_compiler.type == "clang" or c_compiler.type == "clang-cl")
            and c_compiler.version >= "8"
            and not linux32
        ):
            if c_compiler.type == "clang-cl":
                trivial_auto_var_init.append("-Xclang")
trivial_auto_var_init.append("-ftrivial-auto-var-init=pattern")




            c_compiler.type == "gcc" and c_compiler.version >= "13"
        ):

            flags.append("-fstrict-flex-arrays=1")


        # Control Flow Guard (CFG) ----------------------------
        if (
            c_compiler.type == "clang-cl"
            and c_compiler.version >= "8"

        ):

                flags.append("-guard:cf,nochecks")
            else:
                flags.append("-guard:cf")

i see landry added --enable-rust-simd, without making it a toggle, just made it universally enabled on all mozilla ports. the patch omitted the other two options. i previously just read some mozilla documentation, but this time i specifically read build/moz.configure/toolchain.configure in firefox.git at git tag for 155.0.1 and found:                 return ["-D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_DEBUG"]                 return ["-D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_EXTENSIVE"] that's what i found for --enable-stl-hardening, above. looks like therefore we would typically get:  return ["-D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_EXTENSIVE"]                 and ((c_compiler.version >= "11.0.1" and target.cpu in ("x86", "x86_64", "ppc64", "s390x"))                      (c_compiler.version >= "18.1.0" and target.cpu == "aarch64")) ^ note that librewolf (port) already sets -ftrivial-auto-var-init=zero, so i guess that's harder than the above (pattern)         if (c_compiler.type == "clang" and c_compiler.version >= "16") or (             # Cannot use level 3 because we have many uses of the [0] GNU syntax.             # Cannot use level 2 because sqlite3 and icu use the [1] GNU syntax.             and (target.cpu != "aarch64" or c_compiler.version >= "8.0.1")             if target.cpu == "aarch64" and c_compiler.version >= "10.0.0":                 # The added checks in clang 10 make arm64 builds crash. (Bug 1639318)             # nolongjmp is needed because clang doesn't emit the CFG tables of             # setjmp return addresses https://bugs.llvm.org/show_bug.cgi?id=40057

            ldflags.append("-guard:cf,nolongjmp")

    # If ASAN _is_ on, disable FORTIFY_SOURCE just to be safe
    if asan:
        flags.append("-D_FORTIFY_SOURCE=0")

    # fno-common -----------------------------------------
    # Do not merge variables for ASAN; can detect some subtle bugs
    if asan:

        if c_compiler.type == "clang-cl":
            flags.append("-Xclang")
        flags.append("-fno-common")

    return namespace(
        flags=flags,
        ldflags=ldflags,
        trivial_auto_var_init=trivial_auto_var_init,
    )




(I will assume that asan is turned off):



















Am 05.09.26 um 19:29 schrieb Leah Rowe:

        # clang-cl does not recognize the flag, it must be passed down to clang I've no idea if asan is turned on, but from the above, I can see that in OpenBSD we would get with --enable-hardening, the following flags added: -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -- i'm told this is useless on openbsd. we also get: -fstack-protector-strong -fstack-clash-protection <-- removed if ASAN turned on. then (regardless): -ftrivial-auto-var-init=pattern -fstrict-flex-arrays=1 ldflags: -fstack-protector-strong -fstack-clash-protection <-- removed if ASAN turn on. then: -Wl,--dynamicbase -guard:cf,nolongjmp on arm64 we get the following CFLAG added: -guard:cf,nochecks - and on everything else, we get: -guard:cf for --enable-stl-hardening, used on C++ code, we would get these added: -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_EXTENSIVE (for libcpp older than 19 we get instead: -D_LIBCPP_ENABLE_ASSERTIONS=1) my judgement is as i was told earlier, that these two options are basically redundant on OpenBSD, but some of the above options might be worthwhile adding on their own. Look at build/moz.configure/toolchain.configure in firefox source tree to see exactly what these options add. that's actually really nice, the way mozilla configures that. pretty much all the flags are easy to figure out from that file.

Am 05.09.26 um 17:11 schrieb Leah Rowe:

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 :)

Hi everyone!



--enable-hardening

--enable-stl-hardening

--enable-rust-simd





    enable hardening flags in mozilla projects

    there is also a rust-sized easter egg.


    build time:

    * -D_FORTIFY_SOURCE=2 - useless on openbsd
    * fPIE - redundant here (forced by default on openbsd llvm/gcc)
    * -Wl,-z,relro/now: redundant on openbsd





    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


    if an STL container boundary violation occurs, e.g. calling

    kernel level, e.g. pledge is basically the best thing ever.

    --enable-rust-simd is an interesting one:

    bytes at a time instead of 1 byte at a time, via hardware features

    systems, but this would have to be tested over time.




    connections and such.

    Risks associated with --enable-rust-simd:


    but openbsd doesn't use cross compilation anyway.

    enable hardening flags in mozilla projects

    there is also a rust-sized easter egg.


    build time:

    * -D_FORTIFY_SOURCE=2 - useless on openbsd
    * fPIE - redundant here (forced by default on openbsd llvm/gcc)
    * -Wl,-z,relro/now: redundant on openbsd





    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


    if an STL container boundary violation occurs, e.g. calling

    kernel level, e.g. pledge is basically the best thing ever.

    --enable-rust-simd is an interesting one:

    bytes at a time instead of 1 byte at a time, via hardware features

    systems, but this would have to be tested over time.




    connections and such.

    Risks associated with --enable-rust-simd:


    but openbsd doesn't use cross compilation anyway.

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: 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 appends these flags to CFLAGS, CXXFLAGS and LDFLAGS at     * -fstack-protector-strong or -fstack-protector-all depending on target     * -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     Enabling --enable-stl-hardening forces LLVM's libc++ to abort immediately     std::vector::operator out of range. This mitigates errors pertaining to     heap corruption, though OpenBSD will already do something for this at     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     like sse/avx or neon. It's unknown whether this might negatively impact older     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     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,     --enable-hardening appends these flags to CFLAGS, CXXFLAGS and LDFLAGS at     * -fstack-protector-strong or -fstack-protector-all depending on target     * -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     Enabling --enable-stl-hardening forces LLVM's libc++ to abort immediately     std::vector::operator out of range. This mitigates errors pertaining to     heap corruption, though OpenBSD will already do something for this at     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     like sse/avx or neon. It's unknown whether this might negatively impact older     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     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,

--
Company director, Minifree Ltd
Registered in England, No. 9361826 | VAT No. GB202190462
Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK

OpenPGP_0x5C654067D383B1FF.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature