将 Swift 项目接入 OSS-FuzzSwift fuzz target 编写与构建配置全指南【免费下载链接】oss-fuzzOSS-Fuzz - continuous fuzzing for open source software.项目地址: https://gitcode.com/gh_mirrors/os/oss-fuzz本篇指南基于 OSS-Fuzz 官方文档《Integrating a Swift project》展开系统讲解如何将一个 Swift 语言项目接入 OSS-Fuzz 持续模糊测试平台。读完本文你将掌握 Swift fuzz target 的编写规范、project.yaml与Dockerfile的 Swift 专属配置要点以及precompile_swift辅助脚本与SWIFTFLAGS的底层构建原理并可直接参照仓库中 swift-nio、swift-protobuf 两个真实项目落地实践。概述Swift 集成与通用流程的关系Swift 项目接入 OSS-Fuzz 的整体流程与新项目接入通用指南高度一致仍然需要在一个项目目录下放置project.yaml、Dockerfile、build.sh及 fuzz target 源文件仍由 OSS-Fuzz 基础设施负责拉取代码、构建镜像、编译 fuzz target 并投喂测试用例。二者的差异集中在与 Swift 语言工具链相关的几个具体环节上Swift 有独立的构建基础镜像base-builder-swiftfuzz target 需要用 Swift 编写并导出LLVMFuzzerTestOneInput符号构建脚本需要通过precompile_swift脚本生成一组专用的SWIFTFLAGS编译参数引擎与 sanitizer 的选择范围较窄。下文逐项展开这些 Swift 特有细节。编写 Swift fuzz target与 C/C/Go 项目相同Swift 项目接入 OSS-Fuzz 的第一步是编写一个接受「字节流输入」并调用被测程序 API 的 fuzz target。该 fuzz target 应存放在你的项目仓库中而不是 OSS-Fuzz 仓库在构建阶段通过 Dockerfile 拷贝或克隆进构建环境。Swift fuzz target 的核心要求是通过_cdecl导出LLVMFuzzerTestOneInput符号参数签名为(UnsafeRawPointer, Int) - CInt即接收 libFuzzer 传入的原始内存指针与长度。仓库中 swift-nio 项目的 HTTP 解析器 fuzz target fuzz_http1.swift 是一个完整可参考的范例import NIOHTTP1 import NIO _cdecl(LLVMFuzzerTestOneInput) public func test(_ start: UnsafeRawPointer, _ count: Int) - CInt { let bytes UnsafeRawBufferPointer(start: start, count: count) let channel EmbeddedChannel() var buffer channel.allocator.buffer(capacity: count) buffer.writeBytes(bytes) do { try channel.pipeline.addHandler(ByteToMessageHandler(HTTPRequestDecoder())).wait() try channel.writeInbound(buffer) channel.embeddedEventLoop.run() } catch { } do { try channel.finish(acceptAlreadyClosed: true) } catch { } return 0 }这个例子展示了 Swift fuzz target 的几个典型模式_cdecl导出_cdecl(LLVMFuzzerTestOneInput)将 Swift 函数导出为 C 符号libFuzzer 才能以 C ABI 调用它字节流接入将UnsafeRawPointer与长度包装为UnsafeRawBufferPointer再写入被测库如 NIO 的ByteBuffer异常兜底用do/catch吞掉业务异常如解析错误避免异常导致进程异常退出干扰模糊测试固定返回值函数统一返回0崩溃与否完全交由 sanitizer 判定。在搭建你自己的 fuzz target 时将import与处理逻辑替换为被测 Swift 库的 API 即可。项目目录结构与 project.yaml 配置Swift 项目在 OSS-Fuzz 仓库中的目录结构与其他语言项目并无差别即projects/project-name/下放置project.yaml、Dockerfile、build.sh等文件。差异主要体现在project.yaml的字段取值上。language 字段必须指定project.yaml中language属性必须显式声明为swiftlanguage: swift引擎与 sanitizer 的限定范围Swift 项目目前唯一支持的 fuzzing 引擎是libfuzzer支持的 sanitizer 为addressAddressSanitizer与threadThreadSanitizer。以仓库中 swift-nio/project.yaml 的真实配置为例homepage: https://github.com/apple/swift-nio language: swift primary_contact: lukasaapple.com auto_ccs : - johannesweissapple.com - pp_adamsapple.com - p.antoinecatenacyber.fr fuzzing_engines: - libfuzzer sanitizers: - address - thread main_repo: https://github.com/apple/swift-nio.git base_os_version: ubuntu-24-04需要注意Swift 项目不支持coverage之外的额外引擎如afl、honggfuzz也不支持undefined、memory等 sanitizer。这一限制来自底层 Swift 工具链与 libFuzzer 的集成方式配置超出范围会导致构建/运行阶段失败。此外仓库中的 swift-protobuf/project.yaml 还展示了 Swift 项目可用的coverage_extra_args配置——用于在覆盖率统计中排除自动生成的.pb.swift文件与构建产物目录coverage_extra_args: -ignore-filename-regex.*\.pb\.swift -ignore-filename-regex.*/\.build/.*Dockerfile基于 base-builder-swift 基础镜像Swift 项目的 Dockerfile 必须从gcr.io/oss-fuzz-base/base-builder-swift开始而不是通用基础镜像base-builder。该镜像已预装 Swift 工具链与precompile_swift脚本。以 swift-nio/Dockerfile 为参照FROM gcr.io/oss-fuzz-base/base-builder-swift:ubuntu-24-04 # specific swift-nio RUN git clone --depth 1 https://github.com/google/fuzzing RUN git clone --depth 1 https://github.com/apple/swift-nio.git COPY build.sh $SRC COPY *.swift $SRC/ WORKDIR $SRC/swift-nio值得注意的细节显式指定 tag仓库中 Swift 项目的 Dockerfile 均使用带版本 tag 的镜像如:ubuntu-24-04并在project.yaml中同步声明base_os_version: ubuntu-24-04fuzz target 的拷贝方式通过COPY *.swift $SRC/将项目仓库中的 Swift fuzz target 拷贝到构建环境对应前文「fuzz target 存放在项目仓库」的要求$SRC环境变量与其他语言项目一致$SRC是 OSS-Fuzz 约定的源码工作目录。该基础镜像的构成可以在仓库中追溯base-builder-swift/Dockerfile 在base-builder之上执行install_swift.sh并将precompile_swift脚本安装到/usr/local/bin/FROM gcr.io/oss-fuzz-base/base-builder RUN install_swift.sh COPY precompile_swift /usr/local/bin/而 install_swift.sh 则完成了 Swift 工具链的安装安装libc6-dev、libstdc-9-dev、pkg-config、uuid-dev、zlib1g-dev等依赖包下载并解压 Swift 6.1.3 release 工具链到/usr/并从 LLVM 源码编译出专供 Swift 使用的llvm-symbolizer-swift用于崩溃栈符号化对应precompile_swift中将其复制到$OUT的动作。build.sh 与 precompile_swiftSWIFTFLAGS 的生成与使用核心用法build.sh的第一步应当 source执行precompile_swift脚本该脚本会生成环境变量SWIFTFLAGS随后即可将$SWIFTFLAGS直接拼接到 Swift 构建命令中例如swift build -c release $SWIFTFLAGSswift-protobuf 的完整范例仓库中 swift-protobuf 项目的构建脚本文档原文引用展示了完整的用法其中还包含 fuzz target 产物的收集与重命名逻辑. precompile_swift # build project cd FuzzTesting swift build -c debug $SWIFTFLAGS ( cd .build/debug/ find . -maxdepth 1 -type f -name *Fuzzer -executable | while read i; do cp $i $OUT/$i-debug; done )逐步解读这段脚本. precompile_swift以 source 方式执行脚本使SWIFTFLAGS等环境变量在当前 shell 生效swift build -c debug $SWIFTFLAGS进入 fuzz 测试工程目录本例为FuzzTesting携带$SWIFTFLAGS执行构建。使用-c debug而非 release可以保留更多调试信息、提升 sanitizer 报错的可读性收集产物find在.build/debug/下查找名称以Fuzzer结尾、且带可执行权限的文件逐个拷贝到$OUT并追加-debug后缀。由于 swiftpm 会生成多个可执行目标这种批量收集方式可以避免遗漏$OUT是 OSS-Fuzz 约定的 fuzz target 输出目录构建产物最终会被打包并运行于集群。precompile_swift 的底层实现原理SWIFTFLAGS的内容由 precompile_swift 脚本根据当前构建上下文动态生成其核心逻辑如下摘录关键行cp /usr/local/bin/llvm-symbolizer-swift $OUT/llvm-symbolizer export SWIFTFLAGS-Xswiftc -parse-as-library -Xswiftc -static-stdlib --static-swift-stdlib if [ $SANITIZER coverage ] then export SWIFTFLAGS$SWIFTFLAGS -Xswiftc -profile-generate -Xswiftc -profile-coverage-mapping -Xswiftc -sanitizefuzzer else export SWIFTFLAGS$SWIFTFLAGS -Xswiftc -sanitizefuzzer,$SANITIZER --sanitize$SANITIZER for f in $CFLAGS; do export SWIFTFLAGS$SWIFTFLAGS -Xcc$f done for f in $CXXFLAGS; do export SWIFTFLAGS$SWIFTFLAGS -Xcxx$f done fi逐项拆解这些标志的含义标志作用-Xswiftc -parse-as-library将顶层代码按库library而非可执行文件解析这是 fuzz target 以函数入口而非main组织的必要条件-Xswiftc -static-stdlib/--static-swift-stdlib静态链接 Swift 标准库避免运行时依赖动态库导致 fuzz target 在 OSS-Fuzz 运行环境中无法加载-Xswiftc -sanitizefuzzer,$SANITIZER/--sanitize$SANITIZER同时启用 libFuzzer 与当前 sanitizeraddress/thread其中$SANITIZER由 OSS-Fuzz 构建系统按project.yaml中sanitizers字段注入-Xswiftc -profile-generate/-profile-coverage-mapping仅 coverage 构建时启用生成覆盖率映射信息配合-sanitizefuzzer实现带覆盖引导的模糊测试-Xcc$f/-Xcxx$f将 OSS-Fuzz 为 C/C 设置的$CFLAGS/$CXXFLAGS如-fsanitize、-O1等逐条透传给底层 Clang 编译器保证 Swift 与 C/C 混合代码的插桩与 sanitizer 行为一致此外脚本第一步将llvm-symbolizer-swift复制为$OUT/llvm-symbolizer使崩溃报告能够正确符号化 Swift 栈帧。这与project.yaml中仅声明libfuzzer引擎、address/threadsanitizer 的限制遥相呼应precompile_swift是在 Swift 工具链之上补齐 libFuzzer 集成的关键胶水层。端到端集成清单将以上内容整合一个 Swift 项目接入 OSS-Fuzz 的完整落地步骤为编写 fuzz target置于你的项目仓库用_cdecl(LLVMFuzzerTestOneInput)导出入口签名(UnsafeRawPointer, Int) - CInt创建项目目录在 OSS-Fuzz 仓库的projects/name/下准备三个文件配置 project.yaml声明language: swiftfuzzing_engines仅填libfuzzersanitizers填address/thread建议同步声明base_os_version: ubuntu-24-04编写 DockerfileFROM gcr.io/oss-fuzz-base/base-builder-swift:ubuntu-24-04克隆源码并COPYfuzz target 与build.sh编写 build.sh以. precompile_swift开头用swift build -c debug $SWIFTFLAGS构建再按需将产物复制到$OUT可参考 swift-protobuf 的批量收集写法。完成上述步骤后即可按照新项目接入通用指南的后续流程提交项目、通过本地构建验证并接入 OSS-Fuzz 的持续模糊测试。仓库中的 swift-nio 与 swift-protobuf 两个目录是完整的 Swift 项目参考实现涵盖project.yaml、Dockerfile、build.sh与 Swift fuzz target 源文件可作为新项目模板对照学习。【免费下载链接】oss-fuzzOSS-Fuzz - continuous fuzzing for open source software.项目地址: https://gitcode.com/gh_mirrors/os/oss-fuzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 将 Swift 项目接入 OSS-Fuzz：Swift fuzz target 编写与构建配置全指南
将 Swift 项目接入 OSS-FuzzSwift fuzz target 编写与构建配置全指南【免费下载链接】oss-fuzzOSS-Fuzz - continuous fuzzing for open source software.项目地址: https://gitcode.com/gh_mirrors/os/oss-fuzz本篇指南基于 OSS-Fuzz 官方文档《Integrating a Swift project》展开系统讲解如何将一个 Swift 语言项目接入 OSS-Fuzz 持续模糊测试平台。读完本文你将掌握 Swift fuzz target 的编写规范、project.yaml与Dockerfile的 Swift 专属配置要点以及precompile_swift辅助脚本与SWIFTFLAGS的底层构建原理并可直接参照仓库中 swift-nio、swift-protobuf 两个真实项目落地实践。概述Swift 集成与通用流程的关系Swift 项目接入 OSS-Fuzz 的整体流程与新项目接入通用指南高度一致仍然需要在一个项目目录下放置project.yaml、Dockerfile、build.sh及 fuzz target 源文件仍由 OSS-Fuzz 基础设施负责拉取代码、构建镜像、编译 fuzz target 并投喂测试用例。二者的差异集中在与 Swift 语言工具链相关的几个具体环节上Swift 有独立的构建基础镜像base-builder-swiftfuzz target 需要用 Swift 编写并导出LLVMFuzzerTestOneInput符号构建脚本需要通过precompile_swift脚本生成一组专用的SWIFTFLAGS编译参数引擎与 sanitizer 的选择范围较窄。下文逐项展开这些 Swift 特有细节。编写 Swift fuzz target与 C/C/Go 项目相同Swift 项目接入 OSS-Fuzz 的第一步是编写一个接受「字节流输入」并调用被测程序 API 的 fuzz target。该 fuzz target 应存放在你的项目仓库中而不是 OSS-Fuzz 仓库在构建阶段通过 Dockerfile 拷贝或克隆进构建环境。Swift fuzz target 的核心要求是通过_cdecl导出LLVMFuzzerTestOneInput符号参数签名为(UnsafeRawPointer, Int) - CInt即接收 libFuzzer 传入的原始内存指针与长度。仓库中 swift-nio 项目的 HTTP 解析器 fuzz target fuzz_http1.swift 是一个完整可参考的范例import NIOHTTP1 import NIO _cdecl(LLVMFuzzerTestOneInput) public func test(_ start: UnsafeRawPointer, _ count: Int) - CInt { let bytes UnsafeRawBufferPointer(start: start, count: count) let channel EmbeddedChannel() var buffer channel.allocator.buffer(capacity: count) buffer.writeBytes(bytes) do { try channel.pipeline.addHandler(ByteToMessageHandler(HTTPRequestDecoder())).wait() try channel.writeInbound(buffer) channel.embeddedEventLoop.run() } catch { } do { try channel.finish(acceptAlreadyClosed: true) } catch { } return 0 }这个例子展示了 Swift fuzz target 的几个典型模式_cdecl导出_cdecl(LLVMFuzzerTestOneInput)将 Swift 函数导出为 C 符号libFuzzer 才能以 C ABI 调用它字节流接入将UnsafeRawPointer与长度包装为UnsafeRawBufferPointer再写入被测库如 NIO 的ByteBuffer异常兜底用do/catch吞掉业务异常如解析错误避免异常导致进程异常退出干扰模糊测试固定返回值函数统一返回0崩溃与否完全交由 sanitizer 判定。在搭建你自己的 fuzz target 时将import与处理逻辑替换为被测 Swift 库的 API 即可。项目目录结构与 project.yaml 配置Swift 项目在 OSS-Fuzz 仓库中的目录结构与其他语言项目并无差别即projects/project-name/下放置project.yaml、Dockerfile、build.sh等文件。差异主要体现在project.yaml的字段取值上。language 字段必须指定project.yaml中language属性必须显式声明为swiftlanguage: swift引擎与 sanitizer 的限定范围Swift 项目目前唯一支持的 fuzzing 引擎是libfuzzer支持的 sanitizer 为addressAddressSanitizer与threadThreadSanitizer。以仓库中 swift-nio/project.yaml 的真实配置为例homepage: https://github.com/apple/swift-nio language: swift primary_contact: lukasaapple.com auto_ccs : - johannesweissapple.com - pp_adamsapple.com - p.antoinecatenacyber.fr fuzzing_engines: - libfuzzer sanitizers: - address - thread main_repo: https://github.com/apple/swift-nio.git base_os_version: ubuntu-24-04需要注意Swift 项目不支持coverage之外的额外引擎如afl、honggfuzz也不支持undefined、memory等 sanitizer。这一限制来自底层 Swift 工具链与 libFuzzer 的集成方式配置超出范围会导致构建/运行阶段失败。此外仓库中的 swift-protobuf/project.yaml 还展示了 Swift 项目可用的coverage_extra_args配置——用于在覆盖率统计中排除自动生成的.pb.swift文件与构建产物目录coverage_extra_args: -ignore-filename-regex.*\.pb\.swift -ignore-filename-regex.*/\.build/.*Dockerfile基于 base-builder-swift 基础镜像Swift 项目的 Dockerfile 必须从gcr.io/oss-fuzz-base/base-builder-swift开始而不是通用基础镜像base-builder。该镜像已预装 Swift 工具链与precompile_swift脚本。以 swift-nio/Dockerfile 为参照FROM gcr.io/oss-fuzz-base/base-builder-swift:ubuntu-24-04 # specific swift-nio RUN git clone --depth 1 https://github.com/google/fuzzing RUN git clone --depth 1 https://github.com/apple/swift-nio.git COPY build.sh $SRC COPY *.swift $SRC/ WORKDIR $SRC/swift-nio值得注意的细节显式指定 tag仓库中 Swift 项目的 Dockerfile 均使用带版本 tag 的镜像如:ubuntu-24-04并在project.yaml中同步声明base_os_version: ubuntu-24-04fuzz target 的拷贝方式通过COPY *.swift $SRC/将项目仓库中的 Swift fuzz target 拷贝到构建环境对应前文「fuzz target 存放在项目仓库」的要求$SRC环境变量与其他语言项目一致$SRC是 OSS-Fuzz 约定的源码工作目录。该基础镜像的构成可以在仓库中追溯base-builder-swift/Dockerfile 在base-builder之上执行install_swift.sh并将precompile_swift脚本安装到/usr/local/bin/FROM gcr.io/oss-fuzz-base/base-builder RUN install_swift.sh COPY precompile_swift /usr/local/bin/而 install_swift.sh 则完成了 Swift 工具链的安装安装libc6-dev、libstdc-9-dev、pkg-config、uuid-dev、zlib1g-dev等依赖包下载并解压 Swift 6.1.3 release 工具链到/usr/并从 LLVM 源码编译出专供 Swift 使用的llvm-symbolizer-swift用于崩溃栈符号化对应precompile_swift中将其复制到$OUT的动作。build.sh 与 precompile_swiftSWIFTFLAGS 的生成与使用核心用法build.sh的第一步应当 source执行precompile_swift脚本该脚本会生成环境变量SWIFTFLAGS随后即可将$SWIFTFLAGS直接拼接到 Swift 构建命令中例如swift build -c release $SWIFTFLAGSswift-protobuf 的完整范例仓库中 swift-protobuf 项目的构建脚本文档原文引用展示了完整的用法其中还包含 fuzz target 产物的收集与重命名逻辑. precompile_swift # build project cd FuzzTesting swift build -c debug $SWIFTFLAGS ( cd .build/debug/ find . -maxdepth 1 -type f -name *Fuzzer -executable | while read i; do cp $i $OUT/$i-debug; done )逐步解读这段脚本. precompile_swift以 source 方式执行脚本使SWIFTFLAGS等环境变量在当前 shell 生效swift build -c debug $SWIFTFLAGS进入 fuzz 测试工程目录本例为FuzzTesting携带$SWIFTFLAGS执行构建。使用-c debug而非 release可以保留更多调试信息、提升 sanitizer 报错的可读性收集产物find在.build/debug/下查找名称以Fuzzer结尾、且带可执行权限的文件逐个拷贝到$OUT并追加-debug后缀。由于 swiftpm 会生成多个可执行目标这种批量收集方式可以避免遗漏$OUT是 OSS-Fuzz 约定的 fuzz target 输出目录构建产物最终会被打包并运行于集群。precompile_swift 的底层实现原理SWIFTFLAGS的内容由 precompile_swift 脚本根据当前构建上下文动态生成其核心逻辑如下摘录关键行cp /usr/local/bin/llvm-symbolizer-swift $OUT/llvm-symbolizer export SWIFTFLAGS-Xswiftc -parse-as-library -Xswiftc -static-stdlib --static-swift-stdlib if [ $SANITIZER coverage ] then export SWIFTFLAGS$SWIFTFLAGS -Xswiftc -profile-generate -Xswiftc -profile-coverage-mapping -Xswiftc -sanitizefuzzer else export SWIFTFLAGS$SWIFTFLAGS -Xswiftc -sanitizefuzzer,$SANITIZER --sanitize$SANITIZER for f in $CFLAGS; do export SWIFTFLAGS$SWIFTFLAGS -Xcc$f done for f in $CXXFLAGS; do export SWIFTFLAGS$SWIFTFLAGS -Xcxx$f done fi逐项拆解这些标志的含义标志作用-Xswiftc -parse-as-library将顶层代码按库library而非可执行文件解析这是 fuzz target 以函数入口而非main组织的必要条件-Xswiftc -static-stdlib/--static-swift-stdlib静态链接 Swift 标准库避免运行时依赖动态库导致 fuzz target 在 OSS-Fuzz 运行环境中无法加载-Xswiftc -sanitizefuzzer,$SANITIZER/--sanitize$SANITIZER同时启用 libFuzzer 与当前 sanitizeraddress/thread其中$SANITIZER由 OSS-Fuzz 构建系统按project.yaml中sanitizers字段注入-Xswiftc -profile-generate/-profile-coverage-mapping仅 coverage 构建时启用生成覆盖率映射信息配合-sanitizefuzzer实现带覆盖引导的模糊测试-Xcc$f/-Xcxx$f将 OSS-Fuzz 为 C/C 设置的$CFLAGS/$CXXFLAGS如-fsanitize、-O1等逐条透传给底层 Clang 编译器保证 Swift 与 C/C 混合代码的插桩与 sanitizer 行为一致此外脚本第一步将llvm-symbolizer-swift复制为$OUT/llvm-symbolizer使崩溃报告能够正确符号化 Swift 栈帧。这与project.yaml中仅声明libfuzzer引擎、address/threadsanitizer 的限制遥相呼应precompile_swift是在 Swift 工具链之上补齐 libFuzzer 集成的关键胶水层。端到端集成清单将以上内容整合一个 Swift 项目接入 OSS-Fuzz 的完整落地步骤为编写 fuzz target置于你的项目仓库用_cdecl(LLVMFuzzerTestOneInput)导出入口签名(UnsafeRawPointer, Int) - CInt创建项目目录在 OSS-Fuzz 仓库的projects/name/下准备三个文件配置 project.yaml声明language: swiftfuzzing_engines仅填libfuzzersanitizers填address/thread建议同步声明base_os_version: ubuntu-24-04编写 DockerfileFROM gcr.io/oss-fuzz-base/base-builder-swift:ubuntu-24-04克隆源码并COPYfuzz target 与build.sh编写 build.sh以. precompile_swift开头用swift build -c debug $SWIFTFLAGS构建再按需将产物复制到$OUT可参考 swift-protobuf 的批量收集写法。完成上述步骤后即可按照新项目接入通用指南的后续流程提交项目、通过本地构建验证并接入 OSS-Fuzz 的持续模糊测试。仓库中的 swift-nio 与 swift-protobuf 两个目录是完整的 Swift 项目参考实现涵盖project.yaml、Dockerfile、build.sh与 Swift fuzz target 源文件可作为新项目模板对照学习。【免费下载链接】oss-fuzzOSS-Fuzz - continuous fuzzing for open source software.项目地址: https://gitcode.com/gh_mirrors/os/oss-fuzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考