1.asanԴ?源码????
2.AFL--模糊测试使用浅析
3.CALL 、libc++、编译libc
4.微软推出了新的源码开源错误发现工具ProjectOneFuzz

asanԴ?????

       前言

       在使用C/C++构建程序时，内存问题常成为难题，编译难以复现和定位。源码这类问题主要源于内存越界和重复释放。编译用源码补码反码内存管理机制存在不足，源码DPDK内存检测仅在rte_free时进行，编译调试信息有限。源码市面上虽有多种内存管理工具，编译但缺乏DPDK适用且高效的源码解决方案。

       内存检测机制

       多数内存检测工具通过建立红区（redzones）来实现检测。编译红区环绕进程内存的源码绿色区域，通过影子内存记录访问状态。编译影子内存需一大块连续虚拟地址空间，源码供快速查找访问权限，并在每次内存访问前通过代码插桩检查影子区域状态。

       动态库实时检测影子内存状态，允许或阻止内存访问，生成诊断报告。ASan工具采用高效映射机制，使用紧凑影子编码，减少影子内存占用。

       相关视频推荐

       深入了解VPP源码流程、雨林漏斗源码动态库加载、插件、节点和特性。

       高性能网络开发框架VPP与DPDK解决了网卡问题。

       NFV基石DPDK，为网络定义新功能。

       免费学习资源：DPDK、网络协议栈、VPP、OvS、DDoS、NFV、虚拟化、高性能专家。

       DPDK学习路线：0voice.com/uiwebsite/ht...

       文章福利：提供学习书籍、视频资料，自行加入（需要自取）。

       AddressSanitizer原理及在DPDK中实现

       AddressSanitizer（ASan）是Google开发的内存检测工具，通过高效映射和紧凑编码方法优化效率。ASan使用1/8虚拟地址空间的影子内存描述所有地址，构建高效查找机制，通过原始指针除以8和偏移量计算影子内存位置。

       插桩技术在内存访问前进行检查，xphook框架源码替换glibc函数进行实时检测，设置红区标记内存不可访问。Free函数将内存染毒并隔离。日志记录调用栈，快速定位问题。ASan使用启发法关联错误地址，记录和报告错误信息。

       ASan在DPDK中的实现

       ASan基于glibc实现，但DPDK内存管理方式不同，导致动态运行库无法直接挂载。GCC和CLANG支持ASan编译选项，通过在malloc和free函数中实现设置红区。已将ASan代码合并至DPDK .，详情可下载代码查看。

       如何在DPDK中启用ASan工具检测内存

       Meson编译DPDK代码时，添加“-Db_sanitize=address”启用ASan。GCC编译时可不加“-Db_lundef=false”选项，使用“-Dbuildtype=debug”选项输出更多日志信息。推荐使用上述编译选项。

       ASan支持检测缓存溢出、释放后使用等内存问题。检测信息包含文件、行、springboot源码答案函数调用过程，便于高效定位问题。

       启用ASan工具后，会带来一定性能下降和内存开销，适用于代码调试和集成测试阶段。Intel DPDK测试部门已部署ASan工具，发现并修复多个静态工具无法检测的内存问题。CI系统也将ASan检测纳入DPDK代码测试。

AFL--模糊测试使用浅析

       AFL，全称American Fuzzy Lop，是由安全研究员Micha Zalewski开发的一款强大的模糊测试工具。它基于覆盖引导，通过记录输入样本的代码覆盖率，动态调整输入以提升覆盖率，从而提高发现漏洞的可能性。

       AFL的工作流程包括：首先，它会在编译程序时插入代码覆盖率跟踪代码；接着，初始化一个输入队列，包含一些测试文件；然后，对队列中的文件进行变异处理，如果变异后的文件覆盖了新的代码，就加入队列继续测试；过程中，若程序崩溃，kdj图纸源码会记录下来。目标是持续优化测试用例，直到发现潜在的漏洞。

       安装和使用AFL涉及下载源码、编译安装、利用afl-gcc或afl-clang编译测试文件，可能需要修改系统设置如core_pattern。并行测试时，可以根据可用内核数量同时运行多个实例。例如，四个内核可以并发运行四个fuzz实例。

       在模糊测试libjpeg-turbo时，首先编译并安装libjpeg-turbo，需注意动态链接库是否已插桩。通过测试示例验证安装，如果动态链接库未插桩，可以尝试静态链接。通过1亿次以上的模糊测试，验证了libjpeg-turbo的安全性提升。

       此外，AFL还支持内存错误检查工具，如ASAN，通过结合使用可以检测和分析内存安全问题。AFL字典库用于变异操作，自定义字典则需分析目标程序的特性。对于语料库，AFL提供了afl-cmin用于精简覆盖范围相同的测试用例，而afl-tmin则处理单个文件的优化。

       在持久模式下，AFL针对特定功能进行模糊测试，速度上优于全程序模糊。AFL-cov则用于处理代码覆盖率数据，结合lcov和gcov生成覆盖率报告。afl_postprocess则用于定制生成的种子文件格式。

       总的来说，AFL作为一款实用的模糊测试工具，通过一系列的优化和定制功能，为软件安全测试提供了强大的支持。

CALL 、libc++、libc

       CALL 是 **(Compiler/Assembler/Linker/Loader)**的简称。如果你和 C/C++ 打过交道，这几个词应该不会陌生。

       Levels of Representation/Interpretation

       抛开正确性，我们可以尝试填空（Python / C++、Go）并且知道：

       但是同时，Python 也能通过一些方式打包成 exe （虽然很巨大），同时 LLVM 这些层次的引入让我们的理解模糊了起来。所以我们要明确一下这个 Level。

       这个问题实际上是很含糊不清的，第三点里面 JIT 等的引入更让事情扑朔迷离了起来。具体其实可以参考这个链接里的说法： /question/。

       一般被称为“解释型语言”的是主流实现为解释器的语言，但并不是说它就无法编译。例如说经常被认为是“解释型语言”的 Scheme就有好几种编译器实现，其中率先支持 R6RS规范的大部分内容的是 Ikarus，支持在x上编译Scheme；它最终不是生成某种虚拟机的字节码，而是直接生成x机器码。

       实际上解释器的性能劣势也不一定是一种坏事，像我去年去 PyCon 听的“慢解释是一种优势”，虽然有点破罐子破摔的味道，但是如果你在 C/C++ 下开 asan/valgrind 或者带gcc -g, 和 Go 这种带 Runtime 的、V8这些可以提供的debug比较，难免会有羡慕的想法。

       Interpreter provides instruction set independence: run on any machine

       就是这样。

       CALL chain

       这是一张水图。可能还要处理一下预处理之类的过程，但是大概流程是这样没错。

       Compile

       Compile 的过程大概是

       不过看上面转的那篇文章，似乎形式有变，这方面我不是很了解。Lexer/Parser 的部分可以参考我之前的 Lex/Yacc 入门。总之，我们现在把源代码编译后可以转化为一种对应的 IR, 即nmsl.c -> nmsl.S.

       Assembler

       Assembler 接下来会nmsl.s -> nmsl.o.

       顺便给出这个 part 一个很有意思的 slide:

       ELF

       这个我觉得还是 csapp 写得好...总之生成的目标文件会满足这样的形式。

       Linker

       Combines several object (.o) files into a single executable (“linking”)

       这段我感觉 CSAPP 讲的稍微详细一些。

       在应用层面上，这里其实还涉及（不一定是这里引入的）name mangling，calling convention这种 C/C++ 相关的问题，所以可能extern "C" 在这种情况下就相对很好理解了。

       Loader

       When one is run, loader’s job is to load it into memory and start it running In reality, loader is the operating system (OS)

       这里可以参考 CSAPP 里面链接的时机相关的概念。

       libc/libc++

       qsort 是一个 下的函数，如果你去 libc++ 找的话，会发现事情好像不太对：

       github.com/llvm-mirror/...

       这里只有using 和函数声明，没有对应的实现。

       实际上 C++ 的标准库（以 libc++） 为例，可能会根据模版生成需要的函数/类。所以我们可以看到对应的一些源代码。

       C语言的库函数实际上通常以链接库的形式在 libc 中提供，链接的时候我们找到： stackoverflow.com/quest...

微软推出了新的开源错误发现工具ProjectOneFuzz

       今天早些时候，Microsoft 更新了Visual Studio Code的C ++扩展，将其扩展到了1.0版。源代码编辑器是在标准MIT许可下可在GitHub上获得的几种Microsoft产品之一。

       今天，该技术巨头已经在相同的许可下发布了一个新的开源工具-OneFuzz项目。该新平台将替代Microsoft已停产的安全风险检测服务，该平台被称为“ Azure的开源自托管开发人员测试平台”。

       模糊测试本质上是通过严格的测试过程来消除可利用的安全漏洞，该过程涉及用大量随机数据泛滥相关程序。尽管非常有用，但执行起来也常常很复杂。OneFuzz项目试图利用开源LLVM编译器基础结构项目的最新进展，使模糊测试变得更轻松，更连续。

       由于上述进步，以前必须连接到连续构建系统的相关机制现在可以直接烘焙到其中。例如，崩溃检测可以通过asan工具内置，而覆盖范围跟踪可以使用SanitizerCoverage(sancov)工具进行烘焙。展望未来，这些更改将使在单个可执行文件中内置多种模糊测试技术，从而可以开发单元测试二进制文件。

       然后，Project OneFuzz允许将这些测试二进制文件构建到CI / CD管道和云中的大规模Fuzz工作流程中。该工具的突出功能包括：

       可组合的模糊测试工作流程：开放源代码允许用户使用自己的模糊测试工具，交换仪器和管理种子输入。

       内置的集成模糊测试：默认情况下，模糊测试器作为一个团队来共享优势，在模糊测试技术之间交换感兴趣的输入。

       程序分类和结果重复数据删除：它提供了始终重复的独特缺陷案例。

       按需实时发现已崩溃的调试：它使您可以按需或从构建系统中调用实时调试会话。

       可观察和可调试：透明的设计允许自省每个阶段。

       Windows和Linux操作系统上的模糊性：设计成多平台。使用您自己的OS构建，内核或嵌套的管理程序进行模糊测试。

       崩溃报告通知回调：当前支持Azure DevOps工作项和Microsoft Teams消息

       该测试框架已在包括Microsoft Edge和Windows在内的其他Microsoft服务和平台中使用。现在，随着OneFuzz项目的可用性扩展到全世界的开发人员，可以在GitHub上访问它。微软欢迎开源社区的贡献，该公司承诺将来会对该工具进行将来的更新。