Build pw_fuzzer FuzzTest targets for OSS-Fuzz (libFuzzer-compatibility mode) (#72573) * [pw_fuzzer] Build FuzzTest targets in libFuzzer-compatibility mode for OSS-Fuzz Wires pw_fuzzer / Google FuzzTest targets to build as libFuzzer-compatible binaries so they can run on OSS-Fuzz (b/295961502). - build/toolchain/pw_fuzzer: apply FUZZTEST_COMPATIBILITY_MODE=libfuzzer toolchain-wide and link the no-main libFuzzer runtime (fuzzer_no_main, resolved via clang -print-file-name, no hardcoded version); under oss_fuzz use the OSS-Fuzz-provided compiler + $CFLAGS instrumentation. - build/config/compiler: do not link $LIB_FUZZING_ENGINE (carries its own main) for the chip_pw_fuzztest toolchain -- FuzzTest provides main and calls LLVMFuzzerRunDriver. Legacy chip_fuzz_target libFuzzer targets still link it. - build/chip/fuzz_test.gni: drop the per-target compatibility-mode define; it must reach the FuzzTest library (compatibility_mode.cc), not only the harness TU. - scripts/build: add gen_pw_fuzztest_oss_fuzz_wrappers.sh, which emits one OSS-Fuzz fuzz target per FUZZ_TEST case (mirrors oss-fuzz compile_fuzztests.sh). * [pw_fuzzer] Gate libFuzzer-compatibility mode behind chip_pw_fuzz_libfuzzer_compat Local pw-fuzztest builds keep FuzzTest's native engine by default; libFuzzer-compat mode (FUZZTEST_COMPATIBILITY_MODE + no-main libFuzzer runtime) is now opt-in via chip_pw_fuzz_libfuzzer_compat=true, and remains forced on under oss_fuzz for OSS-Fuzz. * [pw_fuzzer] Disable UBSan vptr check for the FuzzTest toolchain Pigweed modules compile with -fno-rtti, which is incompatible with UBSan's -fsanitize=vptr (present in $CFLAGS under SANITIZER=undefined). Append -fno-sanitize=vptr for the chip_pw_fuzztest toolchain only (legacy libFuzzer targets keep full UBSan). No-op for non-undefined sanitizers. * [pw_fuzzer] FuzzChipCert: tolerate a missing seed directory The seed directory (credentials/test/operational-certificates-error-cases) ships in the source tree but is absent in the OSS-Fuzz runner, which runs fuzzers from a temp dir without the build tree (check_build does this deliberately). ReadFilesFromDirectory aborts on a missing dir, so guard it with std::filesystem::is_directory and run without file seeds when absent. On OSS-Fuzz the seeds are supplied via <target>_seed_corpus.zip instead. * [pw_fuzzer] build_examples: add 'compat' modifier for libFuzzer mode Adds a 'compat' build_examples modifier (valid only with -pw-fuzztest) that sets chip_pw_fuzz_libfuzzer_compat=true, so e.g. linux-x64-tests-clang-pw-fuzztest-compat builds the FuzzTest targets locally in libFuzzer-compatibility mode (default remains native FuzzTest). Verified: the target gens with pw_enable_fuzz_test_targets=true and chip_pw_fuzz_libfuzzer_compat=true. * [pw_fuzzer] Add local ASan options config for FuzzTest builds Layers extra ASan options on the chip_pw_fuzztest toolchain's base -fsanitize=address for local (non-oss_fuzz) builds: -fsanitize-address-use-after-return=always and -fsanitize-address-use-after-scope. Only build-activated options (no runtime ASAN_OPTIONS) are included; pointer-compare/pointer-subtract are intentionally omitted as they require ASAN_OPTIONS=detect_invalid_pointer_pairs=2. Under OSS-Fuzz the engine's $CFLAGS own the sanitizer flags, so this applies to local builds only. * [pw_fuzzer] Support ASan+UBSan for local FuzzTest builds (-pw-fuzztest-ubsan) The 'ubsan' build_examples modifier on a -pw-fuzztest target now adds UBSan alongside the default ASan: host.py sets chip_pw_fuzz_ubsan=true, and the chip_pw_fuzztest toolchain layers a fuzztest_ubsan config (-fsanitize=undefined -fno-sanitize=vptr -fno-sanitize-recover=undefined) on local builds. vptr is disabled because pigweed builds -fno-rtti; -fno-sanitize-recover makes UB fatal so libFuzzer records it. Composes with 'compat' (-pw-fuzztest-compat-ubsan). OSS-Fuzz is unaffected (it drives sanitizers via $CFLAGS). Verified: tlv target builds + links clean with address+undefined, no vptr conflict. * [pw_fuzzer] Quiet defined-behavior UBSan noise; drop redundant use-after-scope fuzztest_ubsan: disable -fsanitize=unsigned-integer-overflow and unsigned-shift-base -- these are DEFINED behavior (not UB) and fire constantly on intentional wraps (e.g. abseil's PRNG in low_level_alloc.cc), which is pure noise for fuzzing. Verified the abseil report is gone. fuzztest_asan_options: drop -fsanitize-address-use-after-scope, which is ASan-default-on in modern clang (redundant); keep -fsanitize-address-use-after-return=always (a real, no-env knob). * [build] Add UBSan ignorelist for vendored/stdlib false positives The sanitize_undefined_behavior config enables opt-in checks beyond -fsanitize=undefined (unsigned-integer-overflow, implicit-conversion, nullability) that are not themselves undefined behavior. Vendored libraries (abseil, fuzztest) and libc++ internals rely on defined unsigned modular arithmetic and narrowing, so they trip these checks as false positives; under -fno-sanitize-recover (the OSS-Fuzz UBSan engine) each report becomes a bogus crash. Add build/config/compiler/ubsan_ignorelist.txt to exclude the vendored and stdlib code we do not own (matched by src:* so header code inlined into first-party TUs is covered too), wired in via -fsanitize-ignorelist=. First-party src/ stays fully instrumented. * [pw_fuzzer] Resolve FuzzTest compiler via pw_toolchain_clang_tools Resolve the compiler used to locate the libFuzzer runtime archive (libclang_rt.fuzzer_no_main.a) via pw_toolchain_clang_tools.cxx -- the same clang++ the chip_pw_fuzztest toolchain actually compiles with -- instead of hardcoding //.environment/cipd/packages/pigweed/bin/clang++. The hardcoded path silently breaks if pigweed/CIPD relocate clang; the pigweed variable tracks the CIPD location and any pw_toolchain_CLANG_PREFIX override. Both spellings resolve the identical archive today, so the build is unchanged. * [pw_fuzzer] Drop redundant FuzzTest ASan/UBSan flags covered by global configs The chip_pw_fuzztest toolchain inherits chip's global sanitizer configs, so several local additions were redundant: - Remove fuzztest_asan_options entirely. Its only flag, -fsanitize-address-use-after-return=always, is redundant: modern clang detects stack-use-after-return by default (mode=runtime + detect_stack_use_after_return=1), no ASAN_OPTIONS needed. - Slim fuzztest_ubsan to the fuzzing-specific deltas. The global sanitize_undefined_behavior config reaches this toolchain via is_ubsan and already supplies -fsanitize=undefined, the ubsan ignorelist, and (for -fno-rtti) -fno-sanitize=vptr, so drop those duplicates. Keep -fno-sanitize-recover=undefined (make UB abort so FuzzTest records it as a crash rather than recovering) and the unsigned-overflow/shift noise suppressions (defined behavior, not UB; the ignorelist only covers vendored/stdlib, not first-party code). No effective change to a fuzztest TU's flags beyond dropping the redundant -fsanitize-address-use-after-return=always; stack-use-after-return is still detected via the compiler default. * [pw_fuzzer] Trim verbose/redundant toolchain comments Comment-only cleanup of the pw_fuzzer toolchain: tighten the libFuzzer-compat and sanitizer comments, drop the toolchain_args comment that just restated the section header, and remove external references (Buganizer ticket, pigweed discord link, FuzzTest CMake pointer). No build behavior change. * Remove unneeded comments * [pw_fuzzer] Fix CI: executable bit, build_examples golden, shellharden - Make build/toolchain/pw_fuzzer/print_file_name.py executable (flake8 EXE001: shebang present but file not executable). - Regenerate scripts/build/testdata/all_targets_linux_x64.txt for the new `compat` modifier (build_examples test_linux64_targets). - shellharden: drop unneeded braces in gen_pw_fuzztest_oss_fuzz_wrappers.sh. * [pw_fuzzer] Address review feedback: $OUT/bin wrapper layout, error_code, $CXX - gen_pw_fuzztest_oss_fuzz_wrappers.sh: place the shared FuzzTest binary in $OUT/bin/ (OSS-Fuzz scans only the root of $OUT for fuzz targets) and exec it directly, dropping the chmod -x/+x toggling that fails on read-only mounts. - FuzzChipCertPW.cpp: use the non-throwing std::filesystem::is_directory(path, ec) overload so a permission/I/O error cannot abort the harness (exceptions off). - print_file_name.py: shlex-split the compiler and catch exec failures, so a $CXX with a launcher or flags (e.g. ccache clang++) works and failures print a clean error instead of a Python traceback. * [pw_fuzzer] Document compat/ubsan modifiers and OSS-Fuzz integration in BUILDING.md * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * [pw_fuzzer] CI: build FuzzTests in compat mode in the Linux build workflow * [pw_fuzzer] Keep shared FuzzTest binary in $OUT root (revert $OUT/bin layout) OSS-Fuzz check_build copies the root-level fuzz targets into an isolated dir and runs each; a $OUT/bin/ subdirectory is not copied alongside the wrappers, so every wrapper's shared binary resolved to "No such file" and ~80% of targets were reported broken. Keep the shared binary in $OUT root, non-executable, with the wrappers doing chmod +x at runtime -- the exact layout OSS-Fuzz's own compile_fuzztests.sh uses (check_build copies root-level files, and the run dir is writable). The error_code and print_file_name $CXX-splitting review fixes are unaffected. * [pw_fuzzer] Rename pw-fuzztest libFuzzer-compat modifier: -compat -> -ossfuzz Reviewer feedback: `-compat` was too vague. Repurpose the vestigial `ossfuzz` build_examples modifier -- it set oss_fuzz=true but had no consumers (the OSS-Fuzz automation drives oss_fuzz=true from its own build.sh; nothing invoked the modifier) -- to denote pw-fuzztest's libFuzzer-compatibility build: - `ossfuzz` now sets chip_pw_fuzz_libfuzzer_compat=true, scoped to -pw-fuzztest; drop the now-redundant `compat` modifier. - Let pw-fuzztest + ossfuzz combine (drop ossfuzz from pw-fuzztest's exclusion). - Remove the now-unused HostFuzzingType.OSS_FUZZ and its oss_fuzz=true branch. - Update BUILDING.md, the golden target list, and the CI step. Local target is now linux-x64-tests-clang-pw-fuzztest-ossfuzz (composes with -ubsan/-coverage). Keeping the engine as a modifier leaves room for a future -centipede sibling without new base targets. * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Builds
Tests
Tools
Documentation
Matter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.
Matter is a unified, open-source application-layer connectivity standard built to enable developers and device manufacturers to connect and build reliable, and secure ecosystems and increase compatibility among connected home devices. It is built with market-proven technologies using Internet Protocol (IP) and is compatible with Thread and Wi-Fi network transports. Matter was developed by a Working Group within the Connectivity Standards Alliance (Alliance). This Working Group develops and promotes the adoption of the Matter standard, a royalty-free connectivity standard to increase compatibility among smart home products, with security as a fundamental design tenet. The vision that led major industry players to come together to build Matter is that smart connectivity should be simple, reliable, and interoperable.
Matter simplifies development for manufacturers and increases compatibility for consumers.
The standard was built around a shared belief that smart home devices should be secure, reliable, and seamless to use. By building upon Internet Protocol (IP), Matter enables communication across smart home devices, mobile apps, and cloud services and defines a specific set of IP-based networking technologies for device certification.
The Matter specification details everything necessary to implement a Matter application and transport layer stack. It is intended to be used by implementers as a complete specification.
The Alliance officially opened the Matter Working Group on January 17, 2020, and the specification is available for adoption now.
Visit buildwithmatter.com to learn more and read the latest news and updates about the project.
Matter is developed with the following goals and principles in mind:
Unifying: Matter is built with and on top of market-tested, existing technologies.
Interoperable: The specification permits communication between any Matter-certified device, subject to users’ permission.
Secure: The specification leverages modern security practices and protocols.
User Control: The end user controls authorization for interaction with devices.
Federated: No single entity serves as a throttle or a single point of failure for root of trust.
Robust: The set of protocols specifies a complete lifecycle of a device — starting with the seamless out-of-box experience, through operational protocols, to device and system management specifications required for proper function in the presence of change.
Low Overhead: The protocols are practically implementable on low compute-resource devices, such as MCUs.
Pervasive: The protocols are broadly deployable and accessible, by leveraging IP and being implementable on low-capability devices.
Ecosystem-Flexible: The protocol is flexible enough to accommodate deployment in ecosystems with differing policies.
Easy to Use: The protocol provides smooth, cohesive, integrated provisioning and out-of-box experience.
Open: The Project’s design and technical processes are open and transparent to the general public, including non-members wherever possible.
Matter aims to build a universal IPv6-based communication protocol for smart home devices. The protocol defines the application layer that will be deployed on devices and the different link layers to help maintain interoperability. The following diagram illustrates the normal operational mode of the stack:
The architecture is divided into layers to help separate the different responsibilities and introduce a good level of encapsulation among the various pieces of the protocol stack. The vast majority of interactions flow through the stack captured in the following Figure:
Security: An encoded action frame is then sent down to the Security Layer to encrypt and sign the payload to ensure that data is secured and authenticated by both sender and receiver of a packet.
Message Framing & Routing: With an interaction encrypted and signed, the Message Layer constructs the payload format with required and optional header fields; which specify the message's properties and some routing information.
Matter’s design and technical processes are intended to be open and transparent to the general public, including to Working Group non-members wherever possible. The availability of this GitHub repository and its source code under an Apache v2 license is an important and demonstrable step to achieving this commitment. Matter endeavors to bring together the best aspects of market-tested technologies and redeploy them as a unified and cohesive whole-system solution. The overall goal of this approach is to bring the benefits of Matter to consumers and manufacturers as quickly as possible. As a result, what you observe in this repository is an implementation-first approach to the technical specification, vetting integrations in practice. The Matter repository is growing and evolving to implement the overall architecture. The repository currently contains the security foundations, message framing and dispatch, and an implementation of the interaction model and data model. The code examples show simple interactions, and are supported on multiple transports -- Wi-Fi and Thread -- starting with resource-constrained (i.e., memory, processing) silicon platforms to help ensure Matter’s scalability.
We welcome your contributions to Matter. Read our contribution guidelines here.
Instructions about how to build Matter can be found here .
The Matter repository is structured as follows:
| File/Folder | Content |
|---|---|
| build | Build system support content and built output directories |
| build_overrides | Build system parameter customization for different platforms |
| config | Project configurations |
| credentials | Development and test credentials |
| docs | Documentation, including guides. Visit the Matter SDK documentation page to read it. |
| examples | Example firmware applications that demonstrate use of Matter |
| integrations | 3rd party integrations |
| scripts | Scripts needed to work with the Matter repository |
| src | Implementation of Matter |
| third_party | 3rd party code used by Matter |
| zzz_generated | ZAP generated template code - Revolving around cluster information |
| BUILD.gn | Build file for the GN build system |
| CODE_OF_CONDUCT.md | Code of conduct for Matter and contribution to it |
| CONTRIBUTING.md | Guidelines for contributing to Matter |
| LICENSE | Matter license file |
| REVIEWERS.md | PR reviewers |
| gn_build.sh | Build script for specific projects such as Android, EFR32, etc. |
| README.md | This file |
Matter is released under the Apache 2.0 license.