Linux系统动态追踪技术演化

前言

开源世界本身就是一个开放的生态，新的思想和工具不断被引入，同时老的技术及工具也在不断被淘汰，正是这种新旧更替促成了当前Linux的缤纷世界。整个开源运动及Linux内核的发展史，就是一部引人入胜且让人心怀澎湃的励志故事。

本文将聚焦Linux系统动态追踪技术框架的演化及各种框架的更替，重点介绍众多追踪术框架底层所依赖的内核层上的探测技术及手段，并结合Elkeid HIDS项目，展示系统安全产品如何利用这些手段达成针对攻击行为的检测以及攻击路径的可视化。Elkeid 是火山引擎面向客户输出的终端安全能力模型和应对主机、容器与容器集群、Serverless 等多种工作负载安全需求的开源解决方案。Elkeid源于字节跳动内部最佳实践，其出发点就是字节自身随着业务快速发展所面临的多云、云原生、多种工作负载共存情况下的安全需求。

1 Linux追踪技术演化

Linux系统提供了多种动态追踪技术框架，如最常用的有perf、SystemTap，以及由大神Brendan Gregg主导开发的BCC（BPF Compiler Collection）工具集等。不仅仅是技术框架种类上的繁杂，框架名称就可能是有着多重意义的复合概念，如果再考虑到不同的发行版上的支持及预装，更让人无所适从，即使是运维人员、靠性工程师、或者开发者中的老手在面对实际问题时也要思虑一番才能决定到底用哪个工具链方能最高效地定位并解决问题。

1.1 Linux追踪技术时间线

我们先从时间线上来理解Linux追踪技术的演化： Linux Tracing Timeline

这个时间线是自2000年以来Linux内核追踪技术的演化过程，正是Linux开放的生态才促成了多种追踪框架不断涌现和更迭的局面，完美诠释了百花齐放、优胜劣汰的开源法则。

2000年初：在这个时期Linux内核还没有完整的追踪框架，但网络及安全上的需求一直在推动着Linux内核的追踪及探测能力的发展，如NSA SELinux安全模块引入了LSM Hooks回调机制并成为后续的安全模块如AppArmor所依赖的基础，网络层则是netfilter框架的引入以替代旧有的ipchains框架。
Linux Trace Toolkit（LTT）：LTT是最早的系统追踪和事件分析的框架之一，提供了Linux内核追踪的初始基础设施。LTT的开发早在1998年就已启动，但最终没能并入内核。之后又迎来了LTTng，即Linux Trace Toolkit Next Generation，LTTng提供了更好的扩展性、易用性以及更好的性能。LTTng其实并不是LTT的延续，而是对LTT整个框架的重写并一直维护至今。
DTrace for Sun Solaris: 于2003年正式发布，其强大的功能及可定制性触动了整个Linux开发者圈子，此时Linux的内核跟踪框架缺失的问题开始引起更广泛的关注。
IBM等公司开发了Dprobes for Linux，Linux发行版SLES最早引入此框架，直到2006年由SystemTap替代。Dprobes最终没能整合至Linux内核主线，但还是给Linux内核带来了Kprobes技术框架。
Redhat公司于2005年引入了SystemTap框架，SystemTap是Redhat的Dtrace for Linux解决方案，SystemTap提供给开发者更强大且灵活的接口，允许开发者编写自定义脚本来追踪特定事件和分析系统执行。
Ftrace：2008年左右Ftrace作为一个函数追踪器开始崭露头角，并最终成为Linux内核事实上的基准追踪框架。Ftrace允许记录函数调用及返回时的堆栈和时间戳等信息，为开发者提供了内核执行流的洞察能力。
Perf：全称为Performance Counters for Linux，又被称作是Perf events 或 Perf tools，2009年作为性能分析工具被引入，Perf使用了硬件性能计数器，可提供性能分析、指令级追踪和统计抽样等功能，最终成为Linux系统事实上的性能分析基准工具。
eBPF和BCC：近年来eBPF（扩展Berkeley包过滤器）的引入以及BPF编译器集合（BCC）的出现彻底改变了Linux内核追踪。eBPF允许在内核中进行动态追踪和执行自定义程序，而BCC提供了一系列用于编写和运行eBPF程序的工具和库。

Linux内核追踪从有限且分散的工具及方法最终发展出了全面且多功能的追踪基础设施，如Ftrace、Perf、SystemTap、LTTng、eBPF和BCC等，正是这些框架的引入为开发者带来追踪和分析Linux内核行为和性能的便利。

开源世界本身就是一个开放的生态，不断有新的思想和工具被引入，同时也不断有老的技术及老的工具被淘汰，正是这种更替促成了当前Linux的缤纷世界。整个开源运动及Linux内核的发展史就是一部引人入胜且让人心怀澎湃的故事，有兴趣的读者可延伸阅读参考资料[OS01: Rebel Code: Linux And The Open Source Revolution]。

1.2 追踪技术基础概念

在开始之前我们先澄清几个常用概念，这个概念很容易被混淆在一起：

Probing (探测)：

可以将探测理解为在指定点的进行监控或测量，其核心在于插桩机制(instrumentation)，可以提供在指令流特定位置添加和执行附加逻辑以采集相关数据的能力。Kprobes及uprobes，以及ftrace (Function hooks) 都有着各自的探测机制。

Tracing (跟踪)：

跟踪所强调的事件捕获及数据收集能力，其目的是为了更好地理解软件系统的内部动作。如果将探测假设成为各个分支路径上的路标的话，跟踪就是通过这些路标所串起来的运行轨迹。

Profiling (性能分析)：

性能分析也是基于数据采样的，但其的是为了评估和测量应用程序或系统性能指标，如执行时间、CPU/内存等相关资源的占用等。如通过分析性能分析器所输出的观测事件的统计图表，我们可以更方便地发现执行时间最长的函数等等。

Linux系统动态追踪框架其实都包含了以上三各能力，只不过倾向性有所不同，如perf强于性能分析及热点定位，而trace-cmd/ftrace则更多被用于事件跟踪及执行探查。

2 分层架构

Linux Tracing Hierachy

Linux系统上的所有追踪技术框架总的来说均可以拆分成三层：

1）最上层的交互工具层(Front-End)：本层就是我们通常所说的Linux系统追踪技术这一概念，所代表的是动态追踪技术的用户层工具包，即直接与用户交互的追踪工具及追踪技术的展现层，如Perf工具、BCC工具包、SystemTap或tracecmd等；不同的工具会有不同的命令行约定及输出格式(不同的数据整合及展示方式)、与用户的交互方式等

2）最下层的内核插桩(Kernel Instrument Hooking)：本层可以理解为Linux内核所提供的监控及跟踪能力，即动态追踪技术的基础架构(Infrastructure)，是所有动态追踪技术框架的公共基础。此部分所限定的是数据的采集力（度度/种类、粒度）

3）中间框架层(Frameworks)：本层可理解为接口层，即内核怎样使用和封装监控及跟踪能力并且以什么样的接口提供给应用层，主要作用就是承上启下，比如ftrace框架部分实现了ringbuffer来缓存事件日志并以tracefs形式将ftrace的监控能力直接暴露给用户程序。我们下面在详细各种跟踪框架时不就中间层做单独说明，而是放在交互工具及内核插桩部分中一起介绍。

3 前端交互工具

交互工具就是我们所平时直接使用的工具链，下面我们就分别介绍常用的追踪及性能工具，读者如果相了解各种工具的详细用法可参阅相关的参考资料。

3.1 perf

Perf工具正如其名称所示，其主要用于性能分析的场景，通过监控点数据采样的收集、处理及展示以定位热点(On-CPU)或冷点(Off-CPU)，所以又被称作是Performance Counters for Linux (PCL)。

Perf提供了全栈采样和分析能力，无论用户进程还是操作系统内核均可以采集分析，此外亦能采集分析如CPU硬件事件，此部分主要利用了CPU的performance monitoring unit (PMU) 部件来采集如cache缓存的命中率/有效性或CPU微架构层面上流水线的利用率等CPU硬件统计数据。Perf常被称作是Linux系统上的瑞士军刀，可被用来进行单一应用层程序或操作系统内核的瓶颈分析与定位。Perf分析基于高频采样数据，因面会所引入不小的外部干扰(系统延时、I/O及CPU占用)。

下面的的例子是32位及64位MurMur Hash算法的性能摘要的对比测试：

root@devz1:/bd# perf stat ./MurMur32 testfile

 Performance counter stats for &#039;./MurMur32 testfile&#039;:

          6,201.00 msec task-clock                       #    1.000 CPUs utilized             
                54      context-switches                 #    8.708 /sec                      
                 0      cpu-migrations                   #    0.000 /sec                      
           159,353      page-faults                      #   25.698 K/sec                     
    17,940,754,358      cycles                           #    2.893 GHz                       
    17,780,030,362      instructions                     #    0.99  insn per cycle            
     2,291,592,868      branches                         #  369.552 M/sec                     
        17,469,263      branch-misses                    #    0.76% of all branches           

       6.202178179 seconds time elapsed

       5.853408000 seconds user
       0.348083000 seconds sys

root@devz1:/bd# perf stat ./MurMur64 testfile

 Performance counter stats for &#039;./MurMur64 testfile&#039;:

          6,195.04 msec task-clock                       #    1.000 CPUs utilized             
                39      context-switches                 #    6.295 /sec                      
                 3      cpu-migrations                   #    0.484 /sec                      
           159,350      page-faults                      #   25.722 K/sec                     
    17,923,596,344      cycles                           #    2.893 GHz                       
    18,414,732,121      instructions                     #    1.03  insn per cycle            
     2,291,526,783      branches                         #  369.897 M/sec                     
        17,442,514      branch-misses                    #    0.76% of all branches           

       6.195976210 seconds time elapsed

       5.843555000 seconds user
       0.351973000 seconds sys

下面的例子是用Perf来统计指定监控点mprotect系统调用在10秒内的调用次数，共测量了5次：

root@devz1:/bd# perf stat -a -I 10000 -e &#039;syscalls:*_mprotect&#039;
#           time             counts unit events
    10.001203375            2945573      syscalls:sys_enter_mprotect                                   
    10.001203375            2945678      syscalls:sys_exit_mprotect                                   
    10.001203375                  0      syscalls:sys_enter_pkey_mprotect                                   
    10.001203375                  0      syscalls:sys_exit_pkey_mprotect                                   
    20.003415918            2885202      syscalls:sys_enter_mprotect                                   
    20.003415918            2885113      syscalls:sys_exit_mprotect                                   
    20.003415918                  0      syscalls:sys_enter_pkey_mprotect                                   
    20.003415918                  0      syscalls:sys_exit_pkey_mprotect                                   
    30.004569553            2900982      syscalls:sys_enter_mprotect                                   
    30.004569553            2900982      syscalls:sys_exit_mprotect                                   
    30.004569553                  0      syscalls:sys_enter_pkey_mprotect                                   
    30.004569553                  0      syscalls:sys_exit_pkey_mprotect                                   
    40.005761270            3057035      syscalls:sys_enter_mprotect                                   
    40.005761270            3057036      syscalls:sys_exit_mprotect                                   
    40.005761270                  0      syscalls:sys_enter_pkey_mprotect                                   
    40.005761270                  0      syscalls:sys_exit_pkey_mprotect                                   
    50.006815036            3051245      syscalls:sys_enter_mprotect                                   
    50.006815036            3051246      syscalls:sys_exit_mprotect                                   
    50.006815036                  0      syscalls:sys_enter_pkey_mprotect                                   
    50.006815036                  0      syscalls:sys_exit_pkey_mprotect

用perf生成系统的整体性能分析报告：

root@devz1:/bd# perf record -a -g --call-graph dwarf -s
root@devz1:/bd# perf report -s symbol

Linux Tracing perf

root@devz1:/bd# perf report -T

Linux Tracing perf report

Perf最强大的一项可视化能力是以火焰图形式更直观地展示结果，如图所示：

Perf工具支持所有2.6.31以来的内核版本，支持所有的常见发行版。在使用时需要注意与内核版本的匹配问题，最好使用内核自带的版本；另外Perf在处理及展示数据时(如函数名的提取等)需要相对应调试符号文件。

3.2 BCC & bpftrace

BCC ( Bpf Compiler Collectons) 既是eBPF程序的编写/编译框架，又是上百个测试、跟踪工具的合集，涵盖了Linux内核各个子系统。

bcc tracing

BCC是高度可定制的，支持以Python或LUA语言脚本并动态生成eBPF插桩程序，可充分利用eBPF的优势通过针对性的插桩以最小的CPU代价来获得更精准的监控数据。相较于Perf工具，主要差距在于通用性，对内核版本的要求较高，虽然eBPF所要求的最低内核版本是3.15，但大部BCC工具则需要4.1及之后的内核。

可参阅Brendan Gregg所著的《Systems Performance: Enterprise and the Cloud, 2e》或《BPF Performance Tools 》来了解性能分析的一般思路及BCC众多工具的用法。

与BCC工具相类似的是bpftrace工具，底层同样采用了eBPF，不同之处在于bpftrace实现了通过简单命令脚本实现了强大的eBPF的处理能力，在不少程度上可替代BCC工具链，可谓是调试及跟踪工具中的万能军刀。

3.3 Ftrace

Linux Tracing - ftrace

Ftrace是事实上的Linux默认内核跟踪框架，全称是function tracer，实际上包含了多个不同跟踪程序的框架，可以实现对内核函数整个调用栈的跟踪及执行流的时序分析。Ftrace跟踪框架既可以用前端工具如Trace-cmd或Trace Compass来收集处理跟踪事件，但也可以直接使用tracefs接口来进行交互 (注: 4.1之前的内核使用debugfs)，后者使得ftrace可以很方便地应用在类似嵌入式系统这种受限场景中。

root@devz1:/bd/elkeid/driver/LKM# trace-cmd record -p function_graph -o prctl.cond.dat /bd/prctl.cond 1000
  plugin 'function_graph'
CPU 0: 142884 events lost
CPU 1: 145553 events lost
CPU 2: 146946 events lost
CPU 3: 153171 events lost
CPU 4: 158666 events lost
CPU 5: 146837 events lost
CPU 6: 149830 events lost
CPU 7: 148248 events lost
CPU 8: 146777 events lost
CPU 9: 142771 events lost
CPU 10: 153487 events lost
CPU 11: 109054 events lost
CPU 12: 88133 events lost
CPU 13: 160568 events lost
CPU 14: 146435 events lost
CPU 15: 166039 events lost
CPU0 data recorded at offset=0x1ca000
    677910 bytes in size (2805760 uncompressed)
CPU1 data recorded at offset=0x270000
    662282 bytes in size (2760704 uncompressed)
CPU2 data recorded at offset=0x312000
    671880 bytes in size (2826240 uncompressed)
CPU3 data recorded at offset=0x3b7000
    666420 bytes in size (2760704 uncompressed)
CPU4 data recorded at offset=0x45a000
    660560 bytes in size (2760704 uncompressed)
CPU5 data recorded at offset=0x4fc000
    668253 bytes in size (2760704 uncompressed)
CPU6 data recorded at offset=0x5a0000
    597882 bytes in size (2473984 uncompressed)
CPU7 data recorded at offset=0x632000
    579340 bytes in size (2387968 uncompressed)
CPU8 data recorded at offset=0x6c0000
    669085 bytes in size (2760704 uncompressed)
CPU9 data recorded at offset=0x764000
    671154 bytes in size (2781184 uncompressed)
CPU10 data recorded at offset=0x808000
    461914 bytes in size (2236416 uncompressed)
CPU11 data recorded at offset=0x879000
    685712 bytes in size (2818048 uncompressed)
CPU12 data recorded at offset=0x921000
    678074 bytes in size (2756608 uncompressed)
CPU13 data recorded at offset=0x9c7000
    505564 bytes in size (2105344 uncompressed)
CPU14 data recorded at offset=0xa43000
    664372 bytes in size (2785280 uncompressed)
CPU15 data recorded at offset=0xae6000
    474461 bytes in size (1974272 uncompressed)

root@devz1:/bd/elkeid/driver/LKM# trace-cmd report -i prctl.cond.dat | head -n60
cpus=16
       prctl-999-17870 [010] 106972.553766: funcgraph_entry:        0.663 us   |  mutex_unlock();
       prctl-999-17870 [010] 106972.553767: funcgraph_entry:        0.171 us   |  preempt_count_add();
       prctl-999-17870 [010] 106972.553767: funcgraph_entry:        0.128 us   |  preempt_count_sub();
       prctl-999-17870 [010] 106972.553768: funcgraph_entry:                   |  __f_unlock_pos() {
       prctl-999-17870 [010] 106972.553768: funcgraph_entry:        0.133 us   |    mutex_unlock();
       prctl-999-17870 [010] 106972.553768: funcgraph_exit:         0.375 us   |  }
       prctl-999-17870 [010] 106972.553768: funcgraph_entry:        0.132 us   |  syscall_exit_to_user_mode_prepare();
       prctl-999-17870 [010] 106972.553768: funcgraph_entry:                   |  exit_to_user_mode_prepare() {
       prctl-999-17870 [010] 106972.553769: funcgraph_entry:        0.145 us   |    fpregs_assert_state_consistent();
       prctl-999-17870 [010] 106972.553769: funcgraph_exit:         0.429 us   |  }
       prctl-999-17870 [010] 106972.553770: funcgraph_entry:                   |  __x64_sys_execve() {
       prctl-999-17870 [010] 106972.553770: funcgraph_entry:                   |    kprobe_ftrace_handler() {
       prctl-999-17870 [010] 106972.553771: funcgraph_entry:        0.347 us   |      get_kprobe();
       prctl-999-17870 [010] 106972.553771: funcgraph_entry:                   |      pre_handler_kretprobe() {
       prctl-999-17870 [010] 106972.553772: funcgraph_entry:                   |        execve_entry_handler() {
       prctl-999-17870 [010] 106972.553772: funcgraph_entry:                   |          get_execve_data() {
       prctl-999-17870 [010] 106972.553772: funcgraph_entry:                   |            count() {
       prctl-999-17870 [010] 106972.553772: funcgraph_entry:        0.172 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553773: funcgraph_entry:        0.157 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553773: funcgraph_entry:        0.161 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553773: funcgraph_entry:        0.155 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553774: funcgraph_entry:        0.155 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553774: funcgraph_entry:        0.154 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553774: funcgraph_entry:        0.152 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553774: funcgraph_entry:        0.156 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553775: funcgraph_entry:        0.154 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553775: funcgraph_entry:        0.154 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553775: funcgraph_entry:        0.156 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553775: funcgraph_entry:        0.151 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553776: funcgraph_entry:        0.155 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553776: funcgraph_entry:        0.154 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553776: funcgraph_entry:        0.152 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553777: funcgraph_entry:        0.155 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553777: funcgraph_entry:        0.153 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553777: funcgraph_entry:        0.151 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553777: funcgraph_entry:        0.168 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553778: funcgraph_entry:        0.154 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553778: funcgraph_entry:        0.153 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553778: funcgraph_entry:        0.153 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553778: funcgraph_entry:        0.152 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553779: funcgraph_entry:        0.149 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553779: funcgraph_entry:        0.155 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553779: funcgraph_entry:        0.149 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553779: funcgraph_entry:        0.158 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553780: funcgraph_exit:         7.694 us   |            }
       prctl-999-17870 [010] 106972.553780: funcgraph_entry:                   |            count() {
       prctl-999-17870 [010] 106972.553780: funcgraph_entry:        0.154 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553780: funcgraph_entry:        0.154 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553781: funcgraph_entry:        0.152 us   |              get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553781: funcgraph_exit:         0.960 us   |            }
       prctl-999-17870 [010] 106972.553781: funcgraph_entry:                   |            __kmalloc() {
       prctl-999-17870 [010] 106972.553781: funcgraph_entry:        0.150 us   |              kmalloc_slab();
       prctl-999-17870 [010] 106972.553781: funcgraph_entry:                   |              __kmem_cache_alloc_node() {
       prctl-999-17870 [010] 106972.553781: funcgraph_entry:        0.131 us   |                should_failslab();
       prctl-999-17870 [010] 106972.553782: funcgraph_exit:         0.588 us   |              }
       prctl-999-17870 [010] 106972.553782: funcgraph_exit:         1.140 us   |            }
       prctl-999-17870 [010] 106972.553782: funcgraph_entry:        0.154 us   |            get_user_arg_ptr();
       prctl-999-17870 [010] 106972.553783: funcgraph_entry:                   |            __check_object_size() {
       prctl-999-17870 [010] 106972.553783: funcgraph_entry:        0.127 us   |              check_stack_object();

另外值得一提的是，KernelShark是Perf的数据展示的GUI版本，能以图形的方式多样展示数据： Linux Tracing Kernelshark

3.4 SystemTap

SystemTap是Redhat的DTrace方案，是RHEL、Fedora等红帽系发行般的默认追踪技术框架。2003年Solaris DTrace横空出世，席卷整个Linux开发世界，引起了广泛且持久的关注，彼时Linux的内核跟踪能力还没有建立起完整的生态，而RedHat的答案就是SystemTap，并维护至今，虽然没有集成至内核，但对主流发行版的支持一直都有很好的贯彻，如Debian、SLES等。

SystemTap实现了自己的脚本语言，以对应DTrace的D语言，SystemTap对LKM的编程框架进行了二次封装，实现了脚本至C代码的即时转换，最终通过动态编译并加载内核模块(LKM实现了针对相应关注点的监控能力。所以SystemTap需要额外的依赖：如内核头文件、编译链支持以及调试符号信息等。

下面的例子是使用SystemTap监控libc malloc函数的调用：

[root@CentOS8 ~]# cat malloc.stp 
probe process(&quot;/lib64/libc.so.6&quot;).function(&quot;malloc&quot;) {
    printf(&quot;malloc called: process: %s\n&quot;, execname());
    print_ubacktrace();
}
[root@C82 ~]# stap malloc.stp 
malloc called: process: in:imjournal
 0x7fd360fc0a90 : __libc_malloc+0x0/0x300 [/usr/lib64/libc-2.28.so]
malloc called: process: tuned
 0x7efd845f1a90 : __libc_malloc+0x0/0x300 [/usr/lib64/libc-2.28.so]
malloc called: process: tuned
  ...

SystemTap会自动加载一个临时模块，可通过lsmod来查询：

[root@C82 matt]# lsmod | grep stap
stap_038834a35c414369cc17bce6916b3411_1641   757760  0

[root@C82 ~]# ls -l /tmp
total 8
drwx------. 2 root root 4096 Jul 20 17:45 stap7X8kn4
...
[root@C82 ~]# ls /tmp/stap7X8kn4/
stap_038834a35c414369cc17bce6916b3411_1641.ko  stap_038834a35c414369cc17bce6916b3411_1641_src.c

3.5 LTTng

Linux Trace Toolkit Next Generation (LTTng)于2005年发布，只看名称的话很容易被人理解为LTT (Linux Trace Toolkit) 的升级版本，但实际上是Mathieu Desnoyers对LTT的完全重写。LTTng虽然没能整合进Linux内核主干版本，但Linux tracepoints的开发及性能优化均有Mathieu及LTTng项目的功劳，而tracepoints则是perf及ftrace框架的重要支撑，是Linux跟踪框架的起步。

LTTng项目一直在维护状态，并且增加了对USDT的支持以收集用户态进程自定义监控点数据。在结果分析及展示上可用TraceCompass工具进行辅助。

3.6 Sysdig

Sysdig是一种Linux环境的可视化工具，功能上可以理解为strace + tcpdump + htop + iftop + lsof等工具的集合。Sysdig发布之初主要是用于提升Linux系统可观察性，后续又加入了针对容器本地监控以侧重云环境下的行为监控，Sysdig支持lua脚本。

3.7 Oracle DTrace

Oracle Linux Dtrace是 Solaris DTrace的移植版本，由Oracle发起并维护，主要用在Oracle Linux发行版上。与SystemTap一样，DTrace也是以内核模块为载体来提供内核运行时态的探测能力。与Oracle DTrace类似的项目dtrace4linux，则是由 Paul D. Fox个人所开发和维护的移植版本，可参见[DT04: dtrace4linux @ github]，两个项目其实是各自独立的。DTrace源生于Solairs (由Sun Microsystems inc开发，后Sun公司被Oracle收购)，Sun公司曾以CDDL协议开源整个Solaris操作系统，但Linux内核是基于GPLv2的，也正因为两种协议的差异使得源生于Solaris OS的很多诱人的功能如DTrace、ZFS等不能直接并入Linux内核，这也是DTrace for Linux仅支持Oracle Linux系统的主要原因，相对于日新月异的Linux内核来说DTrace移植开发的节奏要慢很多。

DTrace的强大之处是D语言的脚本支持能力，用户可以自定义D语言程序来达成对系统软硬件运行时态的探测。以【LT04: Linux Performance Analysis Tools】其中的一个例子来介绍Dtrace的使用，此例子统计了sshd进程的所有tcp_sendmsg()调用的size参数并以分布直方图形式展示给用户：

# dtrace -n 'fbt::tcp_sendmsg:entry /execname == "sshd"/ {
    @["bytes"] = quantize(arg3); }'
dtrace: description 'fbt::tcp_sendmsg:entry ' matched 1 probe
^C
 bytes
            value ------------- Distribution ------------- count
               16 |                                        0
               32 |@@@@@@@@@@@@@@@@                        1869
               64 |@@@@@@@@@@@@@                           1490
              128 |@@@                                     355
              256 |@@@@                                    461
              512 |@@@                                     373
             1024 |@                                       95
             2048 |                                        4
             4096 |                                        1
             8192 |                                        0

3.8 Linux Audit

Audit system architecture

Linux Audit是一个用于监控和记录Linux系统相关活动的安全框架，可以追踪系统中的安全相关事件，如用户登录、文件访问、系统调用等等。Audit提供了强大且灵活的安全审计机制，几乎无所不能，无论是监控系统活动，还是合规确保，或者威胁发现等场景均适用，并且能根据系统的安全需求和政策要求进行灵活配置。

Audit是一个完整的审计系统解决方案，自身形成了一个完整的闭环生态，故可定制性上缺乏灵活性，另外所被诟病比较多的则是性能问题，就因为其监控控制的粒度问题。

Linux内核监控点由Audit子系统来实现，均为显式的静态调用，自2.6内核以来就已经存在，所以每个监控点的功能亦是静态的，并且为了性能及稳定性等因素，每条日志的输出基本限定于相关操作函数的调用参数，没有可扩展或自定义的空间。应用层服务进程Auditd与内核kaudit通过netlink机制通信，所有的内核日志只能由Auditd来消费。目前也有新的开源应用层框架替代如go-audit。

4 插桩机制

程序或操作系统本身对用户来说就是一个二进制的黑箱，当评估其内部运作逻辑是否与设计相符、以及调研错误来源或性能热点时，我们就不得不利用插桩技术来进行探测其内部的执行流程及状态数据。这里所说的插桩其实就是常说的instrumenting 及 hooking两个概念，二者的含义基本一致，只不过前者更侧重于数据收集而不改变其行为序列，而后者更侧重于改变或替代原执行流程。

最常用的插桩机制是Inline hooking，目前依然被广泛使用，此技术通过动态修改代码指令以执行监控代码然后再返回原执行流程。Linux内核本身提供了kprobe、uprobe及ftarce等插桩技术框架，其实也是对inline hooking的封装并提供了一致性的内核支持函数，用以掩盖对不同指令架构及不同内核版本的处理。

4.1 插桩机制汇总

Linux Tracing - 插桩机制

插桩机制可分类的维度有很多，从使用范围上可分内核态及用户态，从实现机制上可分顾静态及动态插桩机制，总的来说可归纳为以下几类：

4.1.1通用插桩机制

inline hook机制：即直接修改指令的方式

4.1.2 内核插桩机制

静态插桩机制：

Tracepoints：内核自定义了近2000多个静态监控点，可监控内核及intree模块的内部运作
LSM HOOK：主要适用于安全模块，如SELinux/AppArmor等，能够中断及阻止当前操作
Audit：用于Linux Audit系统，已内置于内核，可根据需要输出相应监控点功子系统的日志
NetFilter：监控网络数据包，防火墙、隧道、VPN等均可基于Netfilter框架来实现

动态插桩机制：

ftrace：kernel function hook的插桩机制
kprobes/uprobes：内核的动态插桩框架，基于int 3 trap及ftace实现
Linux内核通知链（CPU、Mount, USB等）：Linux内核向模块提供的事件通知机制，模块可以注册回调

自定义内核插桩机制：

Syscall table hook：直接修改syscall table以指向自己的程序代码
DKOM (operations table hook)：内核是以文件来管理所有资源的，每种资源如文件均有相应的回调接口，实际上可以理解为一组函数指针，通过修改这些指针的指向从而可以劫持对此类型所有或单个对象的操作
中断向量hook：中断向量表的入口，CPU通过寄存器保存了不同中断的入口地址以实现中断处理的硬件加速
硬件调试断点：调试断点支持指令断点及内存访问断点，但是不同的架构、CPU类型所提供的调试寄存器数量不同，一般都比较少
高精度软/硬中断：中断机制主要用于采样，同样也能用于hook的场景，但对性能影响较大，并且不能确保中断点的指令位置

4.1.3 用户态插桩机制

USDT：User Statically Defined Trace，即用户层的Tracepoint，需要程序在编写时显示定义的监控点，如libc、mysql等应用均有支持
uprobes: 用户态的动态跟踪机制，其实现及回调处理均是在内核中处理的。原理上其实是用breakpoint改写用户态指令的方式触发异常并跳转至内核态的处理程序。自3.5并入的内核，但3.14之后才提供了较好的可用性，tracefs及perf等框架均可以直接使用uprobes
LD_PRELOAD: 利用Linux .so共享库的搜索路径使得加载器优先绑定指定共享库的导出函数，从而跳过默认共享库的绑定，可实现函数级的hook
GOT/PLT表hook：利用ELF/COFF文件的导入及导出表来进行函数级的hook

4.2 通用inline hooking

Inline-hooking是最常用的一种插桩技术，无论是安全软件还是恶意软件都有广泛使用，特别是Windows平台，inline hooking的使用非常频繁，几乎所有的安全软件均依赖于此技术来监控应用层的恶意行为。

Inline-hooking技术简单来就是直接修改代码指令改变原指令的执行流程转而执行我们的监控代码，等监控代码执行完成后再返回至原路径继续执行，最常用的方法就是将函数入口处的指令修改成跳转 (JMP )指令。

Linux Tracing - inline hook

很多rootkit程序如reptile为了达成更好的藏匿效果就使用了inline hooking，syscall table hook方式使用频率很高，很多安全软件均有针对syscall table的审计和校验。下面以reptile为例来说明，

vfs_read内核函数被劫持前的代码：

pwndbg> x/100i 0xffffffff9980b900
   0xffffffff9980b900:  nop    DWORD PTR [rax+rax*1+0x0
   0xffffffff9980b905:  push   r14
   0xffffffff9980b907:  push   r13
   0xffffffff9980b909:  push   r12
   0xffffffff9980b90b:  push   rbp
   0xffffffff9980b90c:  push   rbx
   0xffffffff9980b90d:  mov    eax,DWORD PTR [rdi+0x44]
   0xffffffff9980b910:  test   al,0x1
   0xffffffff9980b912:  je     0xffffffff9980ba1b
   ...

加载reptile之后，vfs_read被篡改了，直接跳转至地0xffffffffc03013f0：

pwndbg> x/100i 0xffffffff9980b900
   0xffffffff9980b900:  jmp    0xffffffffc03013f0
   0xffffffff9980b905:  push   r14
   0xffffffff9980b907:  push   r13
   0xffffffff9980b909:  push   r12
   0xffffffff9980b90b:  push   rbp
   0xffffffff9980b90c:  push   rbx
   0xffffffff9980b90d:  mov    eax,DWORD PTR [rdi+0x44]
   0xffffffff9980b910:  test   al,0x1
   0xffffffff9980b912:  je     0xffffffff9980ba1b
   ...

沿此被修改后的代码流程，可最终找到存放原vfs_read函数指令的跳板，即0xffffffffc03013d0：

pwndbg> x/100i  0xffffffffc03013f0
   0xffffffffc03013f0:  lock inc DWORD PTR [rip+0xffffffffffffffc9]        # 0xffffffffc03013c0
   0xffffffffc03013f7:  sub    rsp,0x40
   0xffffffffc03013fb:  mov    rax,QWORD PTR [rsp+0x48]
   0xffffffffc0301400:  mov    QWORD PTR [rsp],rax
   0xffffffffc0301404:  mov    rax,QWORD PTR [rsp+0x50]
   0xffffffffc0301409:  mov    QWORD PTR [rsp+0x8],rax
   0xffffffffc030140e:  mov    rax,QWORD PTR [rsp+0x58]
   0xffffffffc0301413:  mov    QWORD PTR [rsp+0x10],rax
   0xffffffffc0301418:  mov    rax,QWORD PTR [rsp+0x60]
   0xffffffffc030141d:  mov    QWORD PTR [rsp+0x18],rax
   0xffffffffc0301422:  mov    rax,QWORD PTR [rsp+0x68]
   0xffffffffc0301427:  mov    QWORD PTR [rsp+0x20],rax
   0xffffffffc030142c:  mov    rax,QWORD PTR [rsp+0x70]
   0xffffffffc0301431:  mov    QWORD PTR [rsp+0x28],rax
   0xffffffffc0301436:  mov    rax,QWORD PTR [rsp+0x78]
   0xffffffffc030143b:  mov    QWORD PTR [rsp+0x30],rax
   0xffffffffc0301440:  mov    rax,QWORD PTR [rsp+0x80]
   0xffffffffc0301448:  mov    QWORD PTR [rsp+0x38],rax
   0xffffffffc030144d:  movabs rax,0xffffffffc0694830
   0xffffffffc0301457:  call   rax
   0xffffffffc0301459:  add    rsp,0x40
   0xffffffffc030145d:  lock dec DWORD PTR [rip+0xffffffffffffff5c]        # 0xffffffffc03013c0
   0xffffffffc0301464:  ret

pwndbg> x/100i 0xffffffffc0694830
   0xffffffffc0694830:  push   rbp
   0xffffffffc0694831:  mov    DWORD PTR [rip+0x2f4d],0x1        # 0xffffffffc0697788
   0xffffffffc069483b:  mov    rbp,rsi
   0xffffffffc069483e:  push   rbx
   0xffffffffc069483f:  mov    rax,QWORD PTR [rip+0x28ca]        # 0xffffffffc0697110
   0xffffffffc0694846:  call   0xffffffff99c20750
   0xffffffffc069484b:  mov    rbx,rax
   0xffffffffc069484e:  mov    eax,DWORD PTR [rip+0x2f30]        # 0xffffffffc0697784
   0xffffffffc0694854:  test   eax,eax
   0xffffffffc0694856:  jne    0xffffffffc0694868
   0xffffffffc0694858:  mov    rax,rbx
   0xffffffffc069485b:  mov    DWORD PTR [rip+0x2f23],0x0        # 0xffffffffc0697788
   0xffffffffc0694865:  pop    rbx
   0xffffffffc0694866:  pop    rbp
   0xffffffffc0694867:  ret
   ...

pwndbg> x /10i  0xffffffff99c20750  
   0xffffffff99c20750:  jmp    rax

pwndbg> x/60i  0xffffffffc03013d0
   0xffffffffc03013d0:  nop    DWORD PTR [rax+rax*1+0x0]
   0xffffffffc03013d5:  jmp    0xffffffff9980b905

通常的热补丁技术也使用inline hook，不过热补丁的使用相对更简单一些，因为要修改的指令位置是精心选择的，并且只有完整性核验通过的情况下才会进行热补操作，而一个通用的inline hooking引擎则需要处理更多的问题。

内存不可写的问题：此部分需要修改页面属性或通过页面重新映射来达成，X86体系CPU提供了WP位可以强制改写内存，但此方式下的修改不会触发COW (copy-on-write)，针对用户层的共享代码（如libc共享库）的改写要特别注意
跳板指令生成的问题：以X86指令体系为例，JMP跳转指令的总长度为5个字节，即1个字节的操作数 (0xE9) 及 4个字节的相对地址的偏移。对原始函数的入口写入一个跳转指令会覆盖至少5个字节，而这5个字节可能是多打指令，其中也可能有短跳转指令，所以一般hook框架都需要集成一个反汇编引擎，并且不同的CPU框架需要使用不同指令集的汇编引擎，像ARM及RISC-V一类RISC体系相对更简单一些。跳板指令生成的另一个问题是位置选择，如X86指令JMP的操作数即4个字节的相对地址偏移是个有符号数，即只能跳转相对当前位置上下各2G的空间，如果超出这个范围的话就需要增加中间跳板或改成绝对地址跳转， X86_64绝对跳转指令总长度为12-14字节。
指令撕裂问题：当改写多条指令时就会遇到正好有CPU执行中间指令的情况，特别是多CPU环境中正好线程执行在这几条指令中间的可能性大大增加，一旦遇到此情况将最终导致程序或系统崩溃。针对运行时态的操作系统内核或应用程序可通过暂停其它CPU或当前进程的其它线程以降低指令撕裂发生的概率，但并不能从根本上杜绝。当然如果是在应用程序在加载执行的初始化阶段的话，可有效避免。针对此情况下的应对就是只改写一条指令，因为指令的执行对CPU来说是原子性的，不管CPU的微架构或流水线有多复杂，指令执行的原子性是CPU必须保证的。针对X86指令来说将入口代码的第一个字节修改为0xCC，即 int 3 trap指令，然后通过捕获及并修复继续执行位置的方式来达成改变原执行流程的目的，这也是Linux uprobe所使用的技术方案，此方案的不便之处就是需要内核的协助，即int3 trap异常处理函数要正确识别此uprobe监控点。kprobe的最早实现也是基于int3 trap的，后来的版本则基于ftrace，ftrace则是需要编译器的支持才行，后面再介绍ftace机制时再做详述。

Inline hooking这种技术的明显限制是针对同一个函数的多次hook问题，主要的困扰在于卸载时的跳板无法安全清理的问题，最终结果将导致跳板数量的累加。此外inline hooking的插桩行为改变了指令序列，相关的安全审计软件或者可信计算系统在进行完整性校验时将会发现这种不一致性。另外在使能Intel CPU shadow stack安全技术的系统上也会有兼容性问题。

Linux系统下很少有较成熟的inline hook框架，但Windows系统上有着众多成熟框架，如detours，EasyHook、mhook等。

4.3 Tracepoints

Linux内核预置了近2000个tracepoints，使用tracepoints来监控非常容易，并且支持监控点的批量处理，并且每一个tracepoint都有自己独立的开关，以最小化在监控点未使用的情况下的性能消耗，其中内核使用了jump label、static call等技术，有兴趣的不妨进一步延伸阅读相关资料。

Tracepoints监控点不仅覆盖了用户进程所有的系统调用，也囊括了内核各个关键子系统内部的整个执行过程。总体上Linux内核的tracepoints可以分为以下几类：

进程和线程跟踪点：这些tracepoints与进程和线程的创建、调度、结束等操作有关。通过跟踪这些tracepoints，可以了解进程和线程的执行情况，帮助我们分析和优化多任务系统的性能和行为。
内核事件和操作跟踪点：这些tracepoints与内核内部的事件和操作有关，如内存分配、锁操作、调度器操作等。通过跟踪这些tracepoints，可以深入了解内核的内部工作机制和性能特征。
安全和错误跟踪点：这些tracepoints用于跟踪安全相关的事件和错误条件。例如，可以跟踪系统调用的安全性检查、文件访问权限错误等。安全和错误跟踪点可以帮助我们监视和调试系统的安全性和错误处理。
内核子系统跟踪点：这些tracepoints与内核的不同子系统相关，例如文件系统、网络、内存管理等。它们提供了一种跟踪和调试内核子系统行为的方式，可以用于监视和分析特定子系统的性能和行为。
硬件事件跟踪点：这些tracepoints与硬件相关的事件和操作有关。例如，可以跟踪CPU的中断、缓存事件、DMA操作等。硬件事件跟踪点可以帮助我们深入了解硬件的行为和性能瓶颈。

Tracepoints覆盖了所有syscall的调用、任务调度与切换、硬件等，几乎涵盖了所有的系统事件，当然不同的内核版本会有差异，针对内核v6.1的统计信息如下，基于perf list的输出（等同于 /sys/kernel/debug/tracing/events）：

项目	数量
syscall raw (sys_enter/sys_exit)	2
syscalls（sys_enter_xxx/sys_exit_xxx）	690
sched及task相关事件: 调度层监控点	29
cgroup事件	13
module事件：涉及模块的加载、卸载、引用等	5
net事件：协议及封包相关事件	16
kvm事件	91
所有tracepoints	1944

Tracepoint的支持默认是打开的，相关内核选项为CONFIG_TRACEPOINTS及CONFIG_HAVE_SYSCALL_TRACEPOINTS，当然不排除第三方自定义内核关闭tracepoints的情况。

另外还需要注意的是tracepoints在不同的内核版本上有较大差异，使用时需要做进一步甄别，特别是老版本内核的系统，如CentOS 6系统等。另外还有些个别性的缺陷问题，如sched:process_exec这个监控点的支持是人Linux 3.4才开始有的；ARM64架构上syscall execve及execveat的处理上也有问题，在新进程加载成功的情况下没有syscall exit回调，此问题在5.20及之后的内核版本才得到修复。

用户在自己的模块中也可以显示地定义自己的Tracepoint，这样就可以直接利用Trace-cmd或perf工具来直接跟踪与分析自己的模块。

4.4 Ftrace

在Section 3.3中我们介绍了Ftrace是Linux内核动态跟踪技术的基准框架，在这里我们重点介绍Ftrace的动态插桩机制。Ftrace实现了内核”任意函数点“插桩的能力，并且可以输出调用参数、内部变量，甚至改变函数执行流程、返回值等。

Ftrace的”任意函数点“插桩能力实际上是由在内核编译阶段由gcc编译器完成的，在开启CONFIG_FTRACE的情况下，会打开内核编译开关 -pg，此参数会在函数头添加一个跳板函数的调用：call _mcount或fentry调用指令。即使mcount函数定义为空，此举会带来可达13%的性能损失。

为了解决性能损失的问题，内核引入了CONFIG_DYNAMIC_FTRACE选项，此选项会在内核启动时将所有的跳板函数的调用指令改写成no指令 (nop DWORD PTR [rax+rax*1+0x0])。当注册新的ftrace监控点时，ftrace框架会动态修改相应函数的跳板调用指令，以下面的例子来说明：

do_init_module函数在vmlinux内核镜像文件中的代码如下：

pwndbg> disass do_init_module
Dump of assembler code for function do_init_module:
Address range 0xffffffff81151a50 to 0xffffffff81151c5d:
   0xffffffff81151a50 <+0>: call   0xffffffff81079320 <__fentry__>
   0xffffffff81151a55 <+5>: push   rbp
   0xffffffff81151a56 <+6>: mov    edx,0x10
   0xffffffff81151a5b <+11>:    mov    esi,0xcc0
   0xffffffff81151a60 <+16>:    mov    rbp,rsp
   0xffffffff81151a63 <+19>:    push   r14
   0xffffffff81151a65 <+21>:    push   r13
   0xffffffff81151a67 <+23>:    push   r12
   0xffffffff81151a69 <+25>:    mov    r12,rdi
   0xffffffff81151a6c <+28>:    mov    rdi,QWORD PTR [rip+0x156480d] # <kmalloc_caches+32>
   0xffffffff81151a73 <+35>:    call   0xffffffff812cbc10 <kmalloc_trace>
   0xffffffff81151a78 <+40>:    test   rax,rax
   0xffffffff81151a7b <+43>:    je     0xffffffff81151c55 <do_init_module+517>
   0xffffffff81151a81 <+49>:    mov    r13,rax
   ...

我们可以看到call 0xffffffff81079320 <__fentry__>这条指令实际上非由源代码生成，而是gcc在编译时自动添加的。在系统启动之后，我们用调试器来观察运行时态的内核代码，可以看出第一条指令已被修改：

pwndbg> disass do_init_module
   0xffffffff81151a50 <+0>: nop    DWORD PTR [rax+rax*1+0x0]
   0xffffffff81151a55 <+5>: push   rbp
   0xffffffff81151a56 <+6>: mov    edx,0x10
   0xffffffff81151a5b <+11>:    mov    esi,0xcc0
   0xffffffff81151a60 <+16>:    mov    rbp,rsp
   0xffffffff81151a63 <+19>:    push   r14
   0xffffffff81151a65 <+21>:    push   r13
   0xffffffff81151a67 <+23>:    push   r12
   0xffffffff81151a69 <+25>:    mov    r12,rdi
   0xffffffff81151a6c <+28>:    mov    rdi,QWORD PTR [rip+0x156480d] # <kmalloc_caches+32>
   0xffffffff81151a73 <+35>:    call   0xffffffff812cbc10 <kmalloc_trace>
   0xffffffff81151a78 <+40>:    test   rax,rax
   0xffffffff81151a7b <+43>:    je     0xffffffff81151c55 <do_init_module+517>
   0xffffffff81151a81 <+49>:    mov    r13,rax
   ...

然后我们注册一个do_init_mdoule的kprobe hook，再来观察存在ftrace hook的情况下do_init_module的入口指令：

pwndbg> disass do_init_module
   0xffffffff81151a50 <+0>: call   0xffffffffc0206000
   0xffffffff81151a55 <+5>: push   rbp
   0xffffffff81151a56 <+6>: mov    edx,0x10
   0xffffffff81151a5b <+11>:    mov    esi,0xcc0
   0xffffffff81151a60 <+16>:    mov    rbp,rsp
   0xffffffff81151a63 <+19>:    push   r14
   0xffffffff81151a65 <+21>:    push   r13
   0xffffffff81151a67 <+23>:    push   r12
   0xffffffff81151a69 <+25>:    mov    r12,rdi
   0xffffffff81151a6c <+28>:    mov    rdi,QWORD PTR [rip+0x156480d] # <kmalloc_caches+32>
   0xffffffff81151a73 <+35>:    call   0xffffffff812cbc10 <kmalloc_trace>
   0xffffffff81151a78 <+40>:    test   rax,rax
   0xffffffff81151a7b <+43>:    je     0xffffffff81151c55 <do_init_module+517>
   0xffffffff81151a81 <+49>:    mov    r13,rax
   ...

0xffffffffc0206000就是kprobe的跳板代码，其主要作用就是调用kprobe_ftrace_handler以处理kprobe回调或进行kretprobe回调的堆栈hook，当然还需要进行现场 (寄存器等context相关变量) 的保存与恢复：

pwndbg> x/100i 0xffffffffc0206000
   0xffffffffc0206000:  pushf
   0xffffffffc0206001:  push   rbp
   0xffffffffc0206002:  push   QWORD PTR [rsp+0x18]
   0xffffffffc0206006:  push   rbp
   0xffffffffc0206007:  mov    rbp,rsp
   0xffffffffc020600a:  push   QWORD PTR [rsp+0x20]
   0xffffffffc020600e:  push   rbp
   0xffffffffc020600f:  mov    rbp,rsp
   0xffffffffc0206012:  sub    rsp,0xa8
   0xffffffffc0206019:  mov    QWORD PTR [rsp+0x50],rax
   0xffffffffc020601e:  mov    QWORD PTR [rsp+0x58],rcx
   ......
   0xffffffffc02060cd:  mov    QWORD PTR [rsp+0x98],rcx
   0xffffffffc02060d5:  lea    rbp,[rsp+0x1]
   0xffffffffc02060da:  lea    rcx,[rsp]
   0xffffffffc02060de:  call   0xffffffff8107e500 <kprobe_ftrace_handler>
   0xffffffffc02060e3:  mov    rax,QWORD PTR [rsp+0x90]
   ......
   0xffffffffc020615a:  add    rsp,0xd0
   0xffffffffc0206161:  popf
   0xffffffffc0206162:  ret

Ftrace支持同一个监控点的多次hook，如不同的模块同时监控了同一个内核函数，ftrace hook框架已经封装了相关的处理。另外Dynamic Ftrace在修改跳板调用指令时也考虑到了指令撕裂问题，可参见文档【FT01 】以了解详情。

4.5 Kprobes

Krobes（Kernel Probes）允许在内核运行时（即不需要重新编译内核或模块）动态地插入断点和探测点。最新的Kprobes是基于ftrace的，之前的版本是利用了int 3 trap指令来达成的对目标函数的监控。Kprobes共有3种类型，包括Kprobe、Jprobe和Kretprobe:

Kprobe：Kprobe是一种基本的探测点，用于在内核函数的任意指令位置插入断点。当断点被触发时，Kprobe会执行一个预先注册的处理程序（handler）。处理程序可以访问和修改寄存器、内存和堆栈等数据，以实现对内核操作的监控和修改。
Kretprobe：Kretprobe本身就是架构在Kprobe之上的，Kretprobe需要在Kprobe触发时通过额外的堆栈hook以使能完成回调在在函数返回时被触发。Kretprobe可以在函数返回时获取返回值和堆栈信息，以实现对内核函数执行结果的监控和分析。AMD64架构上针对尾调用做了性能上的优化，即通过JMP跳转的方式以减少函数调用的层数，同时遐免了函数调用的额外压栈及返回时的取栈动作，此举会影响kretprobe hook的使用。
Jprobe，可以当作是特殊的Kprobe。Kprobe通过修改函数入口指令监控函数调用的入口，而Jprobe允许在函数中间直接中断并查看参数及局部变量，这使得Jprobe更适合用于分析和调试内核函数的行为，但同时也会带来不可控问题，直接导致Jprobe被从主线内核中移除，具体可参见：https://lwn.net/Articles/735667/ & https://lkml.org/lkml/2017/10/2/386。

Kprobes可以理解成对Ftrace的封装，增加了函数参数的处理，同时增加了函数返回回调的功能，即Kretprobe，但Kretprobe在可扩展性上有较大性能问题，所以在性能敏感或高频次调用的热点函数上尽量避免或者进行动态的开启及关闭，当然开启及关闭的的动作同样也会引入新的问题，如为了处理指令撕裂问题需要暂停其它CPU的执行等。

4.6 LSM hook

Linux Security Module（LSM）Hooking机制是Linux内核中的一个安全框架，允许多个安全模块（如SELinux、AppArmor、Landlock等）在内核中插入钩子（Hooks），以实施特定的安全策略和访问控制。LSM Hooking机制的设计目的是提供一种模块化、可扩展的安全解决方案，使得内核可以灵活地支持不同的安全模型和需求。

每个LSM组件可根据自己的需求填充security_operations的回调结构，这些函数指针代表了各种内核操作（如文件访问、进程创建等）的安全钩子。通过在这些钩子函数中插入特定的安全模块，LSM可以对内核操作实施访问控制和审计等功能

LSM hook最早由SELinux使用并引入内核，本就是为安全而生的，安全软件所主要关注的进程、程序/动态库/模块加载、内存及文件等高危操作与Linux LSM的监控点亦基本符合，LSM hook本身也提供了操作阻止功能，是安全组件及HIPS (Host-based Intrusion Prevention System) 产品的最佳选择。

最新的6.4内核共提供了多达247个监控回调，之前的内核版本会少一些，如5.4.2内核所支持的回调数量为216，二者数量上相差31，所以在使用中要注意不同内核版本上所支持的回调种类上的差异：

类别	钩子函数个数	功能
ptrace	2	ptrace操作的权限检查
能力机制	3	Capabilities相关操作的权限检查
磁盘配额	2	配盘配额管理操作的权限检查
超级块	15	mount/umount/文件系统/超级块相关操作的权限检查
dentry	2	dentry相关操作的权限检查
文件路径	12	文件名/路径相关操作的权限检查
inode	37	inode相关操作的权限检查
file	12	file相关操作的权限检查
程序加载	5	运行程序时的权限检查
进程	20	线程/进程相关操作的权限检查
IPC	15	IPC消息/共享内存/信号量等操作的权限检查
网络	38	网络相关操作的权限检查: socket/tun/sctp等操作
XFRM	11	IPSec/XFRM相关操作的权限检查
密钥	4	密钥管理相关操作的权限检查
审计	4	内核审计相关操作的权限检查
Binder	4	Android IPC子系统相关操作的权限检查
Perf	5	perf工具相关操作
iouring	3	i/o uring相关
eBPF	7	eBPF系统调用及相关操作
...
总计	247

LSM虽然全称是Linux Secuirty Module，但其并不是真正的Linux内核模块(LKM)，而是必须编译在内核镜像中，即in-tree模式。与其它的功能类似，不同的内核版本间差异也比较大，其中3个影响较大的版本改变： 1） < 4.2.0 只允许一个模块注册，security_ops 指针指向此模块的 security_operations 2）>= 4.2.0 允许多个模块注册，通过双向链表（security_hook_heads）管理（struct list_head） 3) >= 4.17.0 允许多个模块注册，通过单链表（security_hook_heads）管理（struct hlist_head）

LSM hooks虽然是HIPS产品在监控机制上的最佳选择，但对于Linux模块来说却非常不好即，比如自4.12.0开始，security_hook_heads列表在内核初始化之后将不可写，当然有其它方式可达成改写目的，不过更大的障碍还在于security_hook_heads不再导出，这样的话只能通过分析函数指令来定位此链表头，以security_inode_create为例：

pwndbg> disass security_inode_create
Dump of assembler code for function security_inode_create:
   0xffffffff8152d3b0 <+0>: nop    DWORD PTR [rax+rax*1+0x0]
   0xffffffff8152d3b5 <+5>: test   BYTE PTR [rdi+0xd],0x2
   0xffffffff8152d3b9 <+9>: jne    0xffffffff8152d407 <security_inode_create+87>
   0xffffffff8152d3bb <+11>:    push   rbp
   0xffffffff8152d3bc <+12>:    mov    rbp,rsp
   0xffffffff8152d3bf <+15>:    push   r14
   0xffffffff8152d3c1 <+17>:    mov    r14,QWORD PTR [rip+0x1189610]        # 0xffffffff826b69d8 <security_hook_heads+440>
   0xffffffff8152d3c8 <+24>:    push   r13
   0xffffffff8152d3ca <+26>:    push   r12
   0xffffffff8152d3cc <+28>:    push   rbx
   0xffffffff8152d3cd <+29>:    test   r14,r14
   0xffffffff8152d3d0 <+32>:    je     0xffffffff8152d3f8 <security_inode_create+72>
   0xffffffff8152d3d2 <+34>:    mov    r12,rdi
   0xffffffff8152d3d5 <+37>:    mov    r13,rsi
   0xffffffff8152d3d8 <+40>:    movzx  ebx,dx
   0xffffffff8152d3db <+43>:    mov    rax,QWORD PTR [r14+0x18]
   0xffffffff8152d3df <+47>:    mov    edx,ebx
   0xffffffff8152d3e1 <+49>:    mov    rsi,r13
   0xffffffff8152d3e4 <+52>:    mov    rdi,r12
   0xffffffff8152d3e7 <+55>:    call   rax
   0xffffffff8152d3e9 <+57>:    nop    DWORD PTR [rax]
   0xffffffff8152d3ec <+60>:    test   eax,eax
   0xffffffff8152d3ee <+62>:    jne    0xffffffff8152d3fa <security_inode_create+74>
   0xffffffff8152d3f0 <+64>:    mov    r14,QWORD PTR [r14]
   0xffffffff8152d3f3 <+67>:    test   r14,r14
   0xffffffff8152d3f6 <+70>:    jne    0xffffffff8152d3db <security_inode_create+43>
   0xffffffff8152d3f8 <+72>:    xor    eax,eax
   0xffffffff8152d3fa <+74>:    pop    rbx
   0xffffffff8152d3fb <+75>:    pop    r12
   0xffffffff8152d3fd <+77>:    pop    r13
   0xffffffff8152d3ff <+79>:    pop    r14
   0xffffffff8152d401 <+81>:    pop    rbp
   0xffffffff8152d402 <+82>:    ret
   0xffffffff8152d403 <+83>:    int3
   0xffffffff8152d404 <+84>:    int3
   0xffffffff8152d405 <+85>:    int3
   0xffffffff8152d406 <+86>:    int3
   0xffffffff8152d407 <+87>:    xor    eax,eax
   0xffffffff8152d409 <+89>:    ret
   0xffffffff8152d40a <+90>:    int3
   0xffffffff8152d40b <+91>:    int3
   0xffffffff8152d40c <+92>:    int3
   0xffffffff8152d40d <+93>:    int3
End of assembler dump.
pwndbg>

从0xffffffff8152d3c1处的指令即可算出inode_create的链表头为0xffffffff826b69d8。遗憾的是不同的内核版本、及不同的体系架构均会生成不同的指令组合，所要面临的情况比此示例要复杂的多。

值得庆幸的是5.7之后的内核 eBPF框架已支持LSM Hooks，我们可以编写eBPF程序来直接挂接LSM Hooks，以file_mprotect为例：

SEC("lsm/file_mprotect")
int BPF_PROG(mprotect_audit, struct vm_area_struct *vma,
             unsigned long reqprot, unsigned long prot, int ret)
{
        /* ret is the return value from the previous BPF program
         * or 0 if it's the first hook.
         */
        if (ret != 0)
                return ret;

        int is_heap;

        is_heap = (vma->vm_start >= vma->vm_mm->start_brk &&
                   vma->vm_end <= vma->vm_mm->brk);

        /* Return an -EPERM or write information to the perf events buffer
         * for auditing
         */
        if (is_heap)
                return -EPERM;
}

要注意的一点是虽然5.7及之内的内核已经支持LSM Hooks，但不一定会打开相应的配置选项：CONFIG_BPF_LSM，使用前必须确认。

4.7 eBPF

Linux Tracing ebpf

eBPF（Extended Berkeley Packet Filter，扩展的伯克利数据包过滤器）是Linux内核中的一种高效、灵活的程序执行框架。它允许在内核空间运行一些小型、受限制的程序，从而在不修改内核代码的情况下实现对内核行为的观察、修改和扩展。eBPF最初是为了实现高效的网络数据包过滤而设计的，后来扩展为一种通用的内核执行引擎，广泛应用于性能分析、安全监控、网络处理等领域。

eBPF可以认为是内核模块即LKM的替代，可以实现几乎全部的LKM模块的功能。eBPF有以下主要特性：

安全性：eBPF程序在加载到内核之前需要经过验证器（Verifier）的检查，确保程序状态的有限性，即没有不可控循环且不会访问非法的内存区域，所以eBPF在内核空间中执行时超级安全，永不崩溃
高性能：eBPF程序由一组简单的RISC指令组成，可以在内核中以JIT (即时编译) 的方式执行，接近于原生代码的性能，但因为多了更多边界检查与指令校验所以总体上要比LKM的性能差一些
可编程性：eBPF程序可以使用C语言编写，并通过LLVM编译器生成eBPF字节码，并且现在有了支持Go、Python等能用语言的框架
可扩展性：eBPF程序可以访问内核中的辅助函数 (helpers)来与内核交互，通过内存映射 (maps)可以实现应用层与内核层之间的通信交互和高效的数据共享

eBPF最大的好处就是安全性，即使出错也不会导致系统崩溃。另外，它解决了LKM多内核版本适配的问题，eBPF程序在BTF的加持下可以同一个二进制文件运行在多个内核之上。不过实际使用中，eBPF还是无法全量替代LKM，其限制相当多，主要是对内核版本的依赖，毕竟eBPF子系统还在开发中。eBPF框架主要有以下限制：

功能限制：为了确保内核的安全和稳定性，eBPF程序的状态必须是有限的，早期版本不支持循环，在编译时必须将循环做展开处理，而5.3之后才能支持Bounded loop，即常量次数的循环。eBPF程序不能直接访问内核内存或执行任意内核函数，只能调用eBPF的内核辅助函数(helpers)，故其在功能上大大受限；另外为了安全考虑不能进行指针运算
指令限制：eBPF程序由一组限定的64位RISC指令组成，这些指令不支持浮点数、向量操作或高级控制结构 (如异常处理)；eBPF指令是无架构的，故不能访问硬件寄存器或端口。从指令体系上来说其处理能力远不如x86或ARM等系统；5.2之前的内核所支持的最大指令数为4K，之后的内核最大支持1M指令数
内存限制：eBPF程序可以使用有限的堆栈空间和预分配的内存映射(maps)，但不能使用其他内存资源 (如内核堆或全局变量); 函数堆栈只有512字节，函数调用层级亦不能多于9层，参数不能多于5个
系统限制：尽管eBPF框架在较新的Linux发行版中得到了支持，但在较旧的内核版本或特定的系统配置下依然无法使用或功能受限；其对内核版本依赖性较高，eBPF的功能及特性可能因Linux内核版本的不同而有较大的差异
性能开销：eBPF虽然是为高效场景服务场景设计的，但为了保证安全性引入了较多限制及检查，这些额外的动作均会引入性能开销，所以就性能指标而言比LKM要差
eBPF程序必须遵循GPL协议

目前已有众多的安全安全产品及数据可视化平台正在使用eBPF框架以采集内核及网络事件，如Cilium、Sysdig、Tracee、KubuArmor等。

4.8 Netfilter & XDR

Netfilter框架自Linux 2.4.x时便并入了内核，是Linux网络功能及防火墙的实现基础，提供了网络数据包过滤的强大能力。应用层的交互由iptables或nftables完成。netfilter项目提供数据包过滤、网络地址（和端口）转换（NAT/NAPT）、数据包日志记录、用户空间数据包排队和其他数据包操作功能。

Netfilter实现了包过滤及防火墙功能，可通过iptables或nftables定义及下发规则。另外Netfilter允许内核模块在Linux网络堆栈的不同位置注册回调函数，当数据包到达Linux网络栈中预定位置时便会触发这些回调以通知内核模块进行下一步的处理。

XDP全称是eXpress Data Path (快速数据路径)，基于eBPF指令的流程处理程序，其快速的原因在于能够在网络数据包到达网卡驱动时对其进行处理，具有传统框架所不具备的处理时机上的优势及更强的上下文识别能力，故最终可以达成较高的数据面处理性能。传统的Linux内核网络协议栈更强调和注重通用性，所以框架本身就固有性能瓶颈问题，特别随着如100G高速网络的出现，这种性能瓶颈就变得更加突出了，而基于eBPF的XDP程序则没有这些限制，所以XDP能够提高网络数据包的处理速度，同时减少内核协议栈的开销，并最终能够提升系统整体性能。

XDP 技术可以用于各种网络应用的实现，如入侵检测、流量监控、网络加速等各个方面。

5 安全领域实践 - Elkeid

5.1 Elkeid项目简介

Elkeid 是一款可以满足主机、容器与容器集群，Serverless 等多种工作负载安全需求的开源解决方案，源于字节跳动内部最佳实践。随着企业的业务发展，多云、云原生、多种工作负载共存的情况愈发凸显，故Elkeid项目就是我们推出的用以满足不同工作负载下安全需求的完整解决方案。

Elkeid@Bytedance

Elkeid 具备以下主要能力：

Elkeid 不仅具备传统的 HIDS(Host Intrusion Detection System) 的对于主机层入侵检测和恶意文件识别的能力，且对容器内的恶意行为也可以很好的识别，部署在宿主机即可以满足宿主机与其上容器内的反入侵安全需求，并且 Elkeid 底层强大的内核态数据采集能力可以满足大部分安全运营人员对于主机层数据的渴望。
对于运行的业务 Elkeid 具备 RASP 能力可以注入到业务进程内进行反入侵保护，不仅运维人员不需要再安装一个 Agent，业务也无需重启。
对于 K8s 本身 Elkeid 支持接入K8s Audit Log 对 K8s 系统进行入侵检测和风险识别。
Elkeid 的规则引擎 Elkeid HUB 也可以很好的和外部多系统进行联动对接。

Ekeid 将这些能力都很好的融合在一个平台内，满足不同工作负载的复杂安全需求的同时，还能实现多组件能力关联，更难得的是每个组件均经过字节跳动海量数据和多年的实战检验。本文里我们仅关注内部模块的实现，对Elkeid有兴趣的读者可访问Elkeid的网站或联系我们以便更详细地了解Elkeid项目。

5.2 监控点选择

Elkeid是主机安全产品线的监控能力，不需要阻断，即HIDS产品，非HIPS。目前Elkeid主要监控了33个高风险操作，其中18个默认开启，其它的只在沙箱模式下才会启用。监控点列表如下：

	监控点或	编号	备注	启用
1	write	1
2	open	2		沙箱
3	mprotect	10	only PROT_EXEC	沙箱
4	nanosleep	35		沙箱
5	connect	42		开启
6	accept	43		沙箱
7	bind	49		开启
8	execve	59		开启
9	process exit	60		沙箱
10	kill	62		沙箱
11	rename	82		开启
12	link	86		开启
13	chmod	90	>= v1.8	开启
14	ptrace	101	only PTRACE_POKETEXT or PTRACE_POKEDATA	开启
15	setsid	112		开启
16	prctl	157	only PR_SET_NAME	开启
17	mount	165		开启
18	tkill	200		沙箱
19	tgkill	201	>= v1.8	沙箱
20	exit_group	231		沙箱
21	memfd_create	356		开启
22	dns query	601		开启
23	create_file	602		开启
24	load_module	603		开启
25	update_cred	604	only old uid ≠0 && new uid == 0	开启
26	unlink	605		沙箱
27	rmdir	606		沙箱
28	call_usermodehelper_exec	607		开启
29	file_write	608		沙箱
30	file_read	609		沙箱
31	usb_device_event	610		开启
32	privilege_escalation	611		开启
33	port-scan detection	612	tunable via module param: psad_switch	沙箱

选择监控点的考量因素：

监控点并非越多越好，诚然数据种类越多越容易关联起来以提升发现攻击行为的检测水平，但同时也要考虑增加监控点的负担，综合起来的因素有以下3个：

高危操作：尽量覆盖，同时要避免相互间的重叠，即遵循MECE法则 (Mutually Exclusive, Collectively Exhaustive)
性能影响：不同的监控点及不同的回调处理对性能的影响均是不同的，需要实地测试评估
数据量：数据量的问题需要考虑部署规模，如果部署量为百万级，则每增加一个监控点最终所汇聚的数据可能将是巨量的，假设新增的一个监控1分钟产生一条1K的数据，则整个系统每分钟会增加1000000 * 1K = 1G的数据量，每天则会增加1.4T。

5.3 监控机制选择

在监控机制的选择上有两个核心考量维度：

通用性：跨度多个发行版（CentOS/RHEL/Debian/Ubuntu/SLES等）、多个内核版本（从2.6.32 - 6.4），多种CPU架构（AMD64、AArch64、RISC-V64）
性能因素：尽量降低对性能的影响，一般以5%为性能损失上限

从以上两点出发，同时又能保证监控点定制上的弹性，故做出以下选择：

主选：Tracepoints优先，并尽可能用 raw_tracepoint/sys_exit

可以处理64位系统下32位程序的syscall调用，通过检查TS_COMPAT标志判断
可以获取syscall及tracepoint调用点的所有信息，pt_regs或相应参数
尽量少的设置监控点，毕竟sys_enter或sys_exit均会接管所有的syscall，会有全局性的影响，在裸系统上设置sys_enter或sys_exit hook约带来3 - 5%的性能损失。ebpf的tracepint hook最终会向系统注册 perf_syscall_enter或perf_syscall_exit来接管所有的sys_enter及sys_exit事件，并在回调内部增加了分拣机制及相应的封装

备选：使用Kprobe或Ftrace，尽量避免Kretprobe

kprobe的提供的API更友好；ftrace机制的普适性更好，但差别并不大，kprobe底层是优先选择ftrace来实现的
kretprobe存在性能问题，高频或热点函数一定要避免kretprobe；较新内核kprobe机制已优化，但相比tracepoint还是较重
要注意的是kretprobe的ebpf回调中pt_regs全是乱值，与LKM的kretprobe的语义不一致，故kretprobe回调中如果想访问被hook函数的原始参数的话，只能通过kprobe先保存至map，然后kretprobe再从map中查询并获取相应的原始参数

最新的Elkeid的驱动模块及eBPF版本均以Tracepoints为首选监控机制，部分利用Tracepoints无法满足的监控点则使用了kprobe及kretprobe。

6 参考链接

6.1 Open Source & Linux

OS01 Rebel Code: Linux And The Open Source Revolution 2002, Glyn Moody OS02 What Unix Gets Right

6.2 Linux Tracing

LT01: Linux Tracing Technologies, 6.5.0-rc2 LT02 Linux Tracing Concepts, 2021, Elena Zannoni LT03 BPF, Tracing and more, 2017, Brendan Gregg LT04 LWN: Unifying kernel tracing, 2019, Steven Rostedt LT05 Linux Performance Analysis and Tools, 2013, Brendan Gregg LT06 Linux Tracing Systems, 2017, Julia Evans LT07 Choosing a Linux Tracer, 2015, Brendan Gregg LT08 动态追踪技术漫谈，2016，章亦春 LT09 万字长文解读 Linux 内核追踪机制, 2023, 张帆 LT10 Linux Kernel Tracing, 2016, Viller Hsiao

6.3 Ftrace

FT01 Ftrace Kern elHooks: More than just tracing FT02 Kernel Document: Function Tracer Design, 6.5.0-rc2 FT03 通过Ftrace实现高效、精确的内核调试与分析, 2023

6.4 Kprobes

KP01 Kernel Probes (Kprobes)

6.5 Linux Perf

LP01 Linux profiling with performance counters, 2023 LP02: perf Examples LP03: Linux Perf Tools Tips, 2023, Oliver Yang

6.6 eBPF

eBPF @ Wikipedia eBPF BPF Features by Linux Kernel Versions LH01: LSM BPF Progams, 6.5.0-rc2

6.7 BCC

BC01: Systems Performance: Enterprise and the Cloud, 2e, Brendan Gregg [BC02 BPF Performance Tools, 2019](https://www.brendangregg.com/bpf-performance-tools-book.html BC03: eBPF Tracing Tools

6.8 bpftrace

BT01 A thorough introduction to bpftrace, 2019 BT02 bpftrace @ github

6.9 SystemTap

ST01 Getting started with SystemTap, 9.0 ST02: Using SystemTap for Dynamic Tracing and Performance Analysis, 2007, Mike Mason ST03: SystemTap For Runtime Analysis of Kernel Modules such as AFS, 2015, IBM

6.10 LTTng

LT01 LTTng Project LT02 LTTng Documents LT03 How LTTng enables complex multicore system development, 2012, Manfred Kreutzer

6.11 DTrace for Linux

DT01 Orace DTrace DT02 dtrace-linux@github DT03 dtrace@fosdem DT04 dtrace4linux@github: 由个人开发者PaulD.Fox维护的版本

6.12 Audit

AU01 Linux Audit Project, 2023 AU02 System Auditing, 6, RHEL [AU03 Audit Your Linux Box, 2017](https://www.linux-magazine.com/Issues/2017/195/Core-Technologies AU04 Syscall Auditing at Scale, 2017 AU05 go-audit @ github AU06 What You Need to Know About Linux Auditing , 2022, Jakub Nyckowski AU07 Linux audit详解, 2019 AU08 Syscall Auditing in Production with Go-Audit, 2018

6.13 uprobes

UP01 Uprobe-tracer: Uprobe-based Event Tracing， Srikar Dronamraju UP02 Inode based uprobes, 2011, Srikar Dronamraju UP03 Dynamic Instrumentation of User Applications with uprobes, 2019

6.14 Netfilter

NF01 netfilter.org project NF02 In-depth understanding of netfilter and iptables, 2022

6.15 XDP

XD01 XDP @ github XD02 Firewalling with BPF/XDP: Examples and Deep Dive, 2021 XD03 Get started with XDP, 2021 XD04 The BSD Packet Filter A New Architecture for User-level Packet Capture, 2017 XD05 L4Drop: XDP DDoS Mitigations XD06 (译) 深入理解 Cilium 的 eBPF 收发包路径, 2019

6.16 Elkeid项目

BD01 Elkeid @ github

Windows进程CPU、内存等资源限制

Windows自身没有提供类似Linux cgroup的能力来限制进程或进程组的资源占用，进程CPU/IO/内存/网络等资源的控制只能由自己实现。目前已有第三方的实现，主要是限制进程CPU的占用，如文档 < 21 Best Ways to Limit the CPU Usage of a Process > 所描述的BES，Process Tamer等软件。自Windows 8及Server 2012开始Windows系统有提供以job为单位的CPU占用及内存上限设置，之前的版本则只能以进程或线程为单位进行限制。

进程CPU占用限制方案

即时轮询系统所有进程(线程)的CPU占用，当发现所设定进程有超标时强制暂停进程所有线程的执行，然后在适当的时机再恢复执行。其中所涉及技术点：

进程CPU占用查询 GetProcessTimes

BOOL GetProcessTimes(
  [in]  HANDLE     hProcess,
  [out] LPFILETIME lpCreationTime,
  [out] LPFILETIME lpExitTime,
  [out] LPFILETIME lpKernelTime,
  [out] LPFILETIME lpUserTime
);

此函数可以获取进程从创建至当前的总运行时间及总的CPU时间，(KernelTime + UserTime) < 系统CPU数 * (当前时间 - CreationTime)

线程CPU占用查询 GetThreadTimes

BOOL GetThreadTimes(
  [in]  HANDLE     hThread,
  [out] LPFILETIME lpCreationTime,
  [out] LPFILETIME lpExitTime,
  [out] LPFILETIME lpKernelTime,
  [out] LPFILETIME lpUserTime
);

QueryThreadCycleTime可以提供更精准的CPU时间数据，单位为CPU时钟周期

BOOL QueryThreadCycleTime(
  [in]  HANDLE   ThreadHandle,
  [out] PULONG64 CycleTime
);

线程暂停及恢复

Windows平台没有提供暂停整个进程的支持函数，只能以线程为单位来操作，即SuspendThread及ResumeThread:

DWORD SuspendThread(
  [in] HANDLE hThread
);
DWORD ResumeThread(
  [in] HANDLE hThread
);

CPU亲和性设置: SetProcessAffinityMask

BOOL SetProcessAffinityMask(
  [in] HANDLE    hProcess,
  [in] DWORD_PTR dwProcessAffinityMask
);

此函数可以限定进程及其所有线程所能使用的CPU，故一定程序上亦限定了进程最大的系统CPU占用率。

DWORD_PTR SetThreadAffinityMask(
  [in] HANDLE    hThread,
  [in] DWORD_PTR dwThreadAffinityMask
);

此函数可单独限制特定线程的CPU亲和性。

进程优先级设置: SetPriorityClass

优先级解决的是优先运行及退让CPU的问题，本质上并不能限定CPU占用，只是优先级高于当前任务的忙碌的时候，当前进程会主动退让CPU 线程优先级设置：SetThreadPriority

BOOL SetThreadPriority(
  [in] HANDLE hThread,
  [in] int    nPriority
);

Job Objects

Windows系统提供了Job的概念用以管理多个进程，可以限制Job对象内所有进程及期线程的CPU核心占用、CPU占用及内存分配上限等，均通过SetInformationJobObject来实现，具体的CPU限制由JOBOBJECT_CPU_RATE_CONTROL_INFORMATION管理，内存限制则由JOBOBJECT_EXTENDED_LIMIT_INFORMATION来管理。

BOOL SetInformationJobObject(
  [in] HANDLE             hJob,
  [in] JOBOBJECTINFOCLASS JobObjectInformationClass,
  [in] LPVOID             lpJobObjectInformation,
  [in] DWORD              cbJobObjectInformationLength
);

需要注意的是CPU占用设置只有Windows 8及Server 2012之后的版本有效。

CPU Sets

此部分只限定了CPU Affinity属性

实验验证

可以直接利用开源项目go-winjob验证，验证系统Windows 8 x64，go-winjob git repo: https://github.com/kolesnikovae/go-winjob

验证程序

#include &lt;stdio.h&gt;
#include &lt;stdlib.h&gt;

void main(int argc, char *argv[])
{
        unsigned long total = 0, count = 0, i = 0;

        while (1) {
                if (malloc(1024)) {
                        total += 1024;
                        count++;
                }
                if (!(++i &amp; 4095))
                        printf(&quot;alloc: %u size: %u bytes\n&quot;, count, total);
    }
}

无限制

在无限制的情况下，此进程会占满一个CPU核心，commit内存总占用达2G CPUStress unlimited

单一进程

在设定CPU上限16%及内存16M上限之后，结果如下： CPUStress single process examples/job_object.go按如下修改：

var limits = []winjob.Limit{
        winjob.WithBreakawayOK(),
        winjob.WithKillOnJobClose(),
        winjob.WithActiveProcessLimit(3),
        winjob.WithProcessTimeLimit(10 * time.Second),
        winjob.WithCPUHardCapLimit(1600),        // 16%
        winjob.WithProcessMemoryLimit(16 &lt;&lt; 20), // 16MB
        winjob.WithWriteClipboardLimit(),
}

const defaultCommand = &quot;.\\CPUStress.exe&quot;

多进程(双进程)

将winjob.WithProcessMemoryLimit 改为 winjob.WithJobMemoryLimit，后者表示此job内所有进程要占用的总内存限制：

var limits = []winjob.Limit{
        winjob.WithBreakawayOK(),
        winjob.WithKillOnJobClose(),
        winjob.WithActiveProcessLimit(3),
        winjob.WithProcessTimeLimit(10 * time.Second),
        winjob.WithCPUHardCapLimit(1600),    // 16%
        winjob.WithJobMemoryLimit(16 &lt;&lt; 20), // 16MB
        winjob.WithWriteClipboardLimit(),
}

验证结果如下： CPUStress 2-processes

winjob example代码：

// +build windows

package main

import (
        &quot;encoding/json&quot;
        &quot;log&quot;
        &quot;os&quot;
        &quot;os/exec&quot;
        &quot;os/signal&quot;
        &quot;time&quot;

        &quot;golang.org/x/sys/windows&quot;

        &quot;github.com/kolesnikovae/go-winjob&quot;
)

var limits = []winjob.Limit{
        winjob.WithBreakawayOK(),
        winjob.WithKillOnJobClose(),
        winjob.WithActiveProcessLimit(3),
        winjob.WithProcessTimeLimit(10 * time.Second),
        winjob.WithCPUHardCapLimit(1600),    // 16%
        winjob.WithJobMemoryLimit(16 &lt;&lt; 20), // 16MB
        winjob.WithWriteClipboardLimit(),
}

const defaultCommand = &quot;.\\CPUStress.exe&quot;
const stressCommand  = &quot;.\\CPUStressX64.exe&quot;

func main() {
        job, err := winjob.Create(&quot;&quot;, limits...)
        if err != nil {
                log.Fatalf(&quot;Create: %v&quot;, err)
        }

        cmd := exec.Command(defaultCommand)
        cmd.Stderr = os.Stderr
        cmd.SysProcAttr = &amp;windows.SysProcAttr{
                CreationFlags: windows.CREATE_SUSPENDED,
        }
        if err := cmd.Start(); err != nil {
                log.Fatalf(&quot;Start: %v&quot;, err)
        }

        stress := exec.Command(stressCommand)
        stress.Stderr = os.Stderr
        stress.SysProcAttr = &amp;windows.SysProcAttr{
                CreationFlags: windows.CREATE_SUSPENDED,
        }
        if err := stress.Start(); err != nil {
                log.Fatalf(&quot;Start: %v&quot;, err)
        }

        s := make(chan os.Signal, 1)
        signal.Notify(s, os.Interrupt)

        c := make(chan winjob.Notification)
        subscription, err := winjob.Notify(c, job)
        if err != nil {
                log.Fatalf(&quot;Notify: %v&quot;, err)
        }

        done := make(chan struct{})
        go func() {
                defer close(done)
                ticker := time.NewTicker(time.Second * 5)
                defer ticker.Stop()
                var counters winjob.Counters
                for {
                        select {
                        case &lt;-s:
                                log.Println(&quot;Closing job object&quot;)
                                if err := job.Close(); err != nil {
                                        log.Fatal(err)
                                }
                                log.Println(&quot;Closing subscription&quot;)
                                if err := subscription.Close(); err != nil {
                                        log.Fatal(err)
                                }
                                return

                        case n, ok := &lt;-c:
                                if ok {
                                        log.Printf(&quot;Notification: %#v\n&quot;, n)
                                } else if err := subscription.Err(); err != nil {
                                        log.Fatalf(&quot;Subscription: %v&quot;, err)
                                }

                        case &lt;-ticker.C:
                                if err := job.QueryCounters(&amp;counters); err != nil {
                                        log.Fatalf(&quot;QueryCounters: %v&quot;, err)
                                }
                                b, err := json.MarshalIndent(counters, &quot;&quot;, &quot;\t&quot;)
                                if err != nil {
                                        log.Fatal(err)
                                }
                                log.Printf(&quot;Counters: \n%s\n&quot;, b)
                        }
                }
        }()

        if err := job.Assign(cmd.Process); err != nil {
                log.Fatalf(&quot;Assign: %v&quot;, err)
        }
        if err := winjob.Resume(cmd); err != nil {
                log.Fatalf(&quot;Resume: %v&quot;, err)
        }

        if err := job.Assign(stress.Process); err != nil {
                log.Fatalf(&quot;Assign: %v&quot;, err)
        }
        if err := winjob.Resume(stress); err != nil {
                log.Fatalf(&quot;Resume: %v&quot;, err)
        }

        if err := cmd.Wait(); err != nil {
                log.Fatalf(&quot;Wait: %v&quot;, err)
        }
        if err := stress.Wait(); err != nil {
                log.Fatalf(&quot;Wait: %v&quot;, err)
        }

        // Wait for a signal.
        &lt;-done
}

参考链接

通过QEMU/KVM GDB Stub进行内核调试

内核准备

内核配置

建议从源代码重新编译内核，这样可以更方便地进行源代码级调试；当然自己从发行版官网下载相应内核的调试符号亦可以，通常情况下只用于应急分析，比如crash dump分析等。

自己编译Linux内核的话，最好打开两个选项：

CONFIG_DEBUG_INFO=y
CONFIG_GDB_SCRIPTS=y

可通过make menuconfig来设置内核配置项，分别以5.12及6.1.0为例： 5.12: Linux kernel 5.12 menuconfig 6.1.0: Linux kernel 6.1.0 menuconfig

禁止编译优化

无法针对Linux内核禁止全局优化，但可以针对特定的源代码文件做禁止编译优化的处理，可通过以下方式达成：

在需要被调试的源代码文件头部增加下面一行代码：

#pragma GCC optimize ("O0")

或者修改其对应的Makefile，以文件名core.c为例:

CFLAGS_REMOVE_core.o := -O2
CFLAGS_core.o := -O0

镜像准备

建议通过libvirt来管理本地KVM虚拟机，这样使用起来非常方便，如果条件不允许的话亦可用qemu命令行方式来运行。

添加 gdb stub

下面的示例是以命令行方式来运行调试目标：

qemu-system-x86_64 -m 4096 -nographic -net user,hostfwd=tcp::44334-:22 -net nic -hda \
    debian-10.7.qcow2 -machine type=pc,accel=kvm -cpu host -smp 4 -gdb tcp:127.0.0.1:44333

“-gdb tcp:127.0.0.1:44333” 就是gdb stub的命令行参数，即gdb可连接localhost:44333来调试目标系统。

如果使用libvirt的话则需要修改QEMU配置，可通过命令virsh edit来进行修改，需要在末尾加上中间4行：

   </devices>

   <qemu:commandline>
    <qemu:arg value='-gdb'/>
    <qemu:arg value='tcp:localhost:44333'/>
  </qemu:commandline>

</domain>

另外还需要更改虚拟机配置文件的domain type，即将第一行从

<domain type='kvm'>

改为：

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>

修改内核启动项

本步骤主要为了禁止内核地址随机化，不然内核符号无法定位并正确绑定。可通过修改grub项完成，在安装新内核过程中会自加增加nokaslr及nopti，当然在编译内核时亦可直接禁止相应功能亦可。

root@T490:~# cat /etc/default/grub | grep nokaslr
GRUB_CMDLINE_LINUX_DEFAULT=&quot;noquiet nopti nokaslr console=ttyS0&quot;

最直接的方式就是直接修改/boot/grub/grub.cfg文件，或者在系统启动时手工编译grub启动项亦可：

root@T490:~# cat /boot/grub/grub.cfg | grep nokaslr
    linux   /boot/vmlinuz-5.10.14 root=UUID=c4072cd3-9ed9-4376-b85c-95d1306e817b ro  noquiet nopti nokaslr console=ttyS0,115200

host端准备

前面我们就完成了guest端即调试目标机的配置，然后就是准备host端，可以用gdb，亦可以用vscode等gui工具，甚至可以用Windows Visual Studio配合VisualKernel工具来调试Linux系统。

源代码及调试符号vmlinux

将相应源代码及调试符号vmlinux复制到host端即可，复制时注意软链接问题，比如：

vmlinux-gdb.py -> /BUILD/linux-5.12/scripts/gdb/vmlinux-gdb.py

设置gdb的auto-load路径

建议直接修改 ~/.gdbinit文件，当然手动执行亦可，当处理多个调试机时最好通过.gdbinit来保存配置：

matt@T490 /W/K/debian-10.7> cat ~/.gdbinit 
add-auto-load-safe-path /usr/share/gdb/python/gdb/
add-auto-load-safe-path /usr/share/gdb/python/
add-auto-load-safe-path /usr/share/gdb/
add-auto-load-safe-path /BUILD/linux-5.12
set auto-load python-scripts on
source /BUILD/pwndbg/gdbinit.py

我本地的调试环境里安装的是pwndbg，已配置好了python组件

启动gdb

cd /BUILD/linux-5.12; gdb ./vmlinux

在gdb中执行以下执行开启内核调试：

    target remote :44333

然后gdb会自动加载pwndbg并中断目标机： Linux kernel 5.12 gdb

在内核gdb scripts加载成功的情况下可以执行lx系列扩展命令以获取内核信息： Linux kernel 5.12 gdb scripts

可通过apropos lx查询相应的gdb scripts扩展命令，如lx-lsmod, 变量：$lx_current()：

gdb> apropos lx
function lx_clk_core_lookup -- Find struct clk_core by name
function lx_current -- Return current task.
function lx_device_find_by_bus_name -- Find struct device by bus and name (both strings)
function lx_device_find_by_class_name -- Find struct device by class and name (both strings)
function lx_module -- Find module by name and return the module variable.
function lx_per_cpu -- Return per-cpu variable.
function lx_rb_first -- Lookup and return a node from an RBTree
function lx_rb_last -- Lookup and return a node from an RBTree.
function lx_rb_next -- Lookup and return a node from an RBTree.
function lx_rb_prev -- Lookup and return a node from an RBTree.
function lx_task_by_pid -- Find Linux task by PID and return the task_struct variable.
function lx_thread_info -- Calculate Linux thread_info from task variable.
function lx_thread_info_by_pid -- Calculate Linux thread_info from task variable found by pid
lx-clk-summary -- Print clk tree summary
lx-cmdline --  Report the Linux Commandline used in the current kernel.
lx-configdump -- Output kernel config to the filename specified as the command
lx-cpus -- List CPU status arrays
lx-device-list-bus -- Print devices on a bus (or all buses if not specified)
lx-device-list-class -- Print devices in a class (or all classes if not specified)
lx-device-list-tree -- Print a device and its children recursively
lx-dmesg -- Print Linux kernel log buffer.
lx-fdtdump -- Output Flattened Device Tree header and dump FDT blob to the filename
lx-genpd-summary -- Print genpd summary
lx-iomem -- Identify the IO memory resource locations defined by the kernel
lx-ioports -- Identify the IO port resource locations defined by the kernel
lx-list-check -- Verify a list consistency
lx-lsmod -- List currently loaded modules.
lx-mounts -- Report the VFS mounts of the current process namespace.
lx-ps -- Dump Linux tasks.
lx-symbols -- (Re-)load symbols of Linux kernel and currently loaded modules.
lx-timerlist -- Print /proc/timer_list
lx-version --  Report the Linux Version of the current kernel.

Linux kernel 6.0 gdb

gdb常用命令及调试技巧

常用命令

常用gdb指令：bt, disass, step, next, break/delete, print, x/[i/g/d]等，具体可查询gdb命令手册

断点设置

使用break命令可设置断点，支持以下几种命令格式：

break 函数名: break dump_stack
break source_file:line_number: break smith_hook.c:70
break 逻辑地址：break 0xffffffff81003010，可以强制break跳过符号/函数名识别

针对模块的调试，可以考虑在模块中增加不常用内核函数的调用，如dump_stack；模块加载前是无法设置断点的，但内核函数的调用是可以的，这样就可以在模块调用指定内核函数时触发断点，然后再通过add-symbol-file /path_to/ko_file base_address，base_address或通过lx-lsmod查询得到，即模块在内核中的内存位置，之后就可以访问模块内的符号了，如全局变量或内部函数

X86_64位环境调试32位虚拟机

需要在attach前设置目标及当前系统架构，如 set architecture i386:x86-64。建议安装gdb-multiarch，以免系统自带gdb不支持多种架构：

pwndbg> target remote :44323
Remote debugging using :44323
warning: Selected architecture i386 is not compatible with reported target architecture i386:x86-64
warning: Architecture rejected target-supplied description
Remote 'g' packet reply is too long (expected 312 bytes, got 608 bytes): 102b91c10......0000

pwndbg> set architecture i386:x86-64
The target architecture is set to "i386:x86-64".
pwndbg> target remote :44323
Remote debugging using :44323
0x00000000c1912b23 in default_idle () at arch/x86/kernel

Linux系统安全检测项

Security Checkpoints

Linux系统安全-入侵检测与防护思路

1 系统安全简介及现状分析

主机安全涉及防御的整个纵深，内容繁多，如防火墙、WAF、RASP、IDS、IPS、安全审计、病毒杀毒、补丁管理、安运与安服等等。本文的目标主要是解决单点的系统威胁的发现与防御问题，属于系统安全的范畴，主要包含攻击发现、本地提权、rootkit防护三方面的内容。

本文目标在操作系统层面仅限于Linux系统，体系架构上以X86为主，兼顾ARM64。公司目前的主机系统主要是Intel XEON架构。既然以服务器系统为主，所以必须应对生产服务器对稳定性及性能的苛刻要求，并在此前提下达成安全上的需求。

2 核心需求

实现入侵行为的检测与防护，保障服务安全
稳定性与性能兼顾，保证服务可用性

总之，从检测能力及防护能力上着手，进一步接近并达成反入侵的需求，确实做好安全与保障。

3 攻击路径

大部分的入侵行为均可分成以下几个阶段：

扫描探测：通过扫描、社工或钓鱼等方式以了解主机信息，如网络结构、操作系统及服务类型等
漏洞触发：针对系统漏洞或配置错误发起攻击，前期攻击办能搭载较轻量的payload
主体下载：成功触发漏洞并达成了RCE (shellcode执行)或取得了shell权限，然后下载工作负载，如挖矿、勒索程序
主体执行：运行新下载的工作负载以启动真正的攻击，如挖矿、勒索、横向攻击、提权或持久化
本地提权：利用系统漏洞组合攻击，这一步有难度较高，且并非必需，主要由攻击意图决定
后门固化：即持久化，并隐藏自身或伪装、混淆

在主机这个单点上由于缺少关联数据，针对“扫描探测”只能做有限应对，如弱密码爆破场景，其它复杂场景需要汇集终端及其它主机的数据综合分析以作判定。第二步的漏洞触发也是很难检测到的，如未知0DAY漏洞本身就没有任何的先验知识，毕竟漏洞的存在是不可回避的事实。好在从第三步开始，主机端均有机会发现并做出合理判定，因为攻击意图必须以特定的攻击行为方能达成。

攻击行为相对于系统正常行为来说还是少之又少，并且多数攻击行为和正常操作并没有太大差异，这也是攻击检测的难点。攻击行为可分为两部分分别应对：可疑攻击和未知攻击，可疑攻击部分毕竟有先验知识，可以划定出较清楚的边界，此部分可以马上着手实现，这也是本文的重点。

4 可疑攻击

这部分主要依据经验总结，是针对当前HIDS的补充和增强，检测部分主要有4类检测项目，实现思路部分先做个简单阐述，等商定后再做详细详解。

4.1 攻击检测

4.1.1 CPU关键控制位

此部分主要针对CPU硬件的安全特性的检测，攻击者为了展开攻击或扩大成果不得不关闭这些安全特性：

MSR寄件器EFER.NXE位：即DEP/NX位，数据区防执行，本安全特性默认开启，Linux系统允许通过grub的kernel参数开启或关闭。另外亦可通过修改MSI寄存Extended Feature Enable Register (EFER)的Bit 11调节。EFER寄存器是位于MSR的C0000080H处。
CR4.SMEP位：Supervisor Mode Execution Prevention，此功能可阻止内核特权模式下运行用户层代码，可阻止ret2usr类的攻击。
CR4.SMAP位：Supervisor Mode Access Prevention，配合EFLAGS的AC位可开启或关闭，可以阻止内核特权模式下直接访问用户层内存。在必须访问用户内存时，系统支持函数copy_to/from_user会临时设置EFLAGS的AC位。此特性从Linux 3.7开始支持。
CR4.TSD位：Time Stamp Disable, 高精度计数器，可用于时序攻击，如Meltdown及Spectre/MDS等针对CPU漏洞的攻击所采用的就是rdtsc或rdtscp指令以精准确定CPU cache是否命中。
CR4.PCE位： Performance-monitor Counter Enable，类似TSD，但精度上不如TSC。

4.1.2 内核检查项

这部分主要是针对内核对象及内核空间的检测，需要内核权限:

内核镜像： KIMAGE_VADDR， kpti/kaslr等属性
核心表项：idt/syscall table/shadow kernel
内核模块：映射区域：MODULES_VADDR - MODULES_END，3条链：module/sysfs/kobject
关键内核对象：file/dentry/inode_operations等，涉及文件系统(包含/proc、设备等重要数据结构，常被rootkit篡改以隐藏进程、网络连接、病毒文件等
内核通知链notifier_chain: 内核支持几十个，较重要的有module、keyboard等，后者可用于实现keylogger
网络驱动netfilter内部结构及操作表项
binfmt: 二进制可执行行程序加载：elf程序运行、内核模块加载等

4.1.3 进程检查项

此部分检测针对用户进程，主要是进程相关的核心数据结构、以及对进程自身的R3用户空间的内存的检测:

可执行内存区域检测： a) W + X 内存映射区，针对jit程序存在误报可能 b) 不属于任何模块的映射区：如通过【REF1: ELF反射加载器】自展开加载的模块或程序
VDSO及vsyscall映射区域防篡改校验：常用于ret2dir及DirtyCow攻击，可通过PFN与内容HASH进行校验
运行时安全属性检测： a) LD_PRELOAD: 动态库搜索路径，最好程序运行时进行检查 b) 第三方模块注入，如Apache插件，第三方注入在Linux系统上并不常见
task_struct结构：如属主权限信息：uid/suid/euid/gid/egid/fsuid/fsgid, cap_effective/inheritable/permitted等，定时检测可以发现“任意内存写”攻击 a) 非法pid值检查：利用非法pid值可以达成进程隐藏 b) 线程Stack Pointer检查 (Stack Pivot攻击)，难点是：go/rust/jit的

4.1.4 高危调用

这里我们主要关注进程、程序/动态库/模块加载、内存及文件相关的调用，与Linux LSM的监控点基本符合。以4.4.131的内核为例，系统共提供了多达198个监控点回调，较新的5.4.2内核已经支持多达216监控回调：

类别	钩子函数个数	功能
ptrace	2	ptrace操作的权限检查
能力机制	3	Capabilities相关操作的权限检查
磁盘配额	2	配盘配额管理操作的权限检查
超级块	13	mount/umount/文件系统/超级块相关操作的权限检查
dentry	2	dentry相关操作的权限检查
文件路径	11	文件名/路径相关操作的权限检查
inode	27	inode相关操作的权限检查
file	13	file相关操作的权限检查
程序加载	5	运行程序时的权限检查
进程	27	进程/进程相关操作的权限检查
IPC	21	IPC消息/共享内存/信号量等操作的权限检查
proc文件系统	2	proc文件系统相关操作的权限检查
系统设置	2	日志，时间等相关操作的权限检查
内存管理	1	内存管理相关操作的权限检查
安全属性	7	对安全相关数据结构的操作的权限检查
网络	37	网络相关操作的权限检查
XFRM	11	XFRM架构想要关操作的权限检查
密钥	4	密钥管理相关操作的权限检查
审计	4	内核审计相关操作的权限检查
Android Binder	4	Android Binder架构有关操作的权限检查
总计	198

重点关注项：

prctl：进程项调节
ptrace：调试
mmap/mprotect (W+X)：内存映射、可执行权限设置
dlopen/dlmopen：动态库加载
LKM/module加载时针对modprobe_path的检查
execve/execveat等：针对主、客体的关联判断，另外可增加主被动交互的侦测，如通过bash.readline可以判断是否是用户手动输入
commit_creds/setuid/seteuid/setegid...
chown/chmod +s/rename/unlink/link等：文件属主、属性相关操作

4.2 实现思路简述

需要两种检测机制：

4.2.1 定时检测：CPU及纯内核数据

此部分需要周期性的定时检测，实现方式有多种，如hrtimer/timer回调，延时工作队列(delayed workqueue)、硬件PMU或Intel PT等机制，目前来看延时工作队列的方式足以满足需求，如果后期对实时性要求更高可改用高精度时钟（hrtimer），这两种方式是都是Linux内核本身所支持的，有良好的普适性和稳定性。

在涉及内核对抗的情况下，可采用PMU或PT等硬件机制，硬件机制还能应对基于虚拟化的攻击，参考实现有【REF3: HARDWARE-ASSISTED ROOTKITS】及【REF4: GhostHook – Bypassing PatchGuard with Processor Trace Based Hooking】。

4.2.2 事件触发检测：进程相关数据

模块加载、进程创建等操作可通过通知链或kprobe监控点触发，如LD_PRELOAD及modprobe_path等项目
进程相关数据检测：要通过进程调度事件触发（trace_sched_switch）,当进程时间片用完被调试出去时检测task_struct结构及相关内存映射属性等项目
高危调用

这部分数据的检测要注意事件回调的上下文环境，部分数据检测会涉及进程用户层内存的访问，属于softirq的hrtimer回调中是不能进行此操作的，需要转至workqueue或私有内核线程。

另外，纯用户层内存的检测亦可以通过R3 HOOK【REF2: TrustSec: LINUX: HOW’S MY MEMORY】或uprobe机制实现（自Linux 3.8开始支持），但必要性并不大，完全内核态的实现没有引入过多复杂性。

5 未知攻击

针对未知攻击一直没有较好的应对方式，一些比较苛刻的环境采用了可信计算的机制，即非白即黑的策略。可信计算主要解决了程序来源的问题，并不能有效应对程序的漏洞问题。业界公司应对内存安全的方案，所解决的也是类似的未知攻击及内存安全问题。

本章节所描述的应对思路便遵循了非白即黑的策略，当然此部分并不是完全的可信计算，而是一种轻量级的程序来源可信及可信执行的工程化实现。

5.1 程序可信

程序可信所解决的是来源问题，有两种可实现方式：

白名单机制：利用现有的IMA/Integrity进行来源控制
针对ELF文件增加新section，所有的程序均要做此处理，技术上需要修改elf加载器

此部分对用户行为有较大影响，程序发布及扩散环节都要做处理，特别是第二种方式。

5.2 执行可信

执行可信考虑的不是程序的来源，而是程序自身的代码逻辑，可分为两种粒度的控制：

指令控制流防护（CFI）：需要编译器在编译阶段生成指令时加入分支指令操作的判断，这部分相对已经成熟，gcc及llvm均有支持，会增加程序的体量和性能损耗，但总体上可控。grSecurity的RAP方式就是类似的方式，可参见：【REF5: grSecurity RAP】
关键API调用序列防护：在API或系统调用层次上实现的执行防护，需要预先针对可执行程序进行静态或动态分析以生成规则，并在运行时进行插桩检测，同RASP异曲同工，只是所解决的问题不在一个层面上。相关的参考有【REF6: BlackBox: Lightweight Security C Monitoring for COTS Binaries】及【REF7: Virsec Trusted Execution】

5.3 脚本防护

Linux下可执行脚本种类繁多，且功能较大，没有统一的方式来应对，可常用的应对方案有以下几中：

用行为沙箱或类RASP的方式来做启发式分析
通过文件集进行执行管控: 如/tmp目录、web服务upload目录（新上传）脚本防执行，当然也有些例外情况，如安装包会自动生成脚本并执行
全量收集以进行后续人工分析及机器学习分类

6 其它功能

6.1 自保功能：防杀防卸载 6.2 ARM64等新体系结构的支持 6.3 代码优化及性能提升

7 样本数据库建设

安全不只是技术，还是人的行为管理和数据的运营，所以有必要从以下两个方面来强化数据的收集与关联：

7.1 行为数据及画像库

常登录的服务器、登录时间、经常的操作、来源ip等习惯行为数据

7.2 程序样本数据库

所有的程序（可执行程序、动态库、脚本）及安装包、来源信息的整理，现在360、腾讯等公司均已建立了较为完备的样本库，同样亦适用于URL/IP、威胁及漏洞等数据

8 参考资料

Windows HIPS防护面

1. 防护范围

Windows HIPS (Host Intrusion Prevent System) 主机入侵防御系统核心部分可以归纳为3D，即AD（Application Defend，应用程序防御体系）、RD(Registry Defend，注册表防御体系）和FD(File Defend，文件防御体系)。另外还有ND（Network Defend，网络防火墙）及DD（Device Defend，设备/外设防护）,后两者也算是管控的范畴

2. AD

Windows的用户权限管理比较宽松，AD防护不仅复杂还面临较大的攻击面：

针对AD防护，仅利用系统内核层回调很难达成全面防护，只有当攻击已发生且已经成功的情况下才能发现攻击，此时恶意攻击已然达成。AD防护的短板极有必要采用R0或R3 HOOK的方式予以弥补和加固。

操作	方式	说明
创建	-	通用回调可以在进程启动时得到通知，但在“进程为什么会启动”的原因上缺少必要信息，R0/R3 HOOK可以作为必要的补充手段来实现全方面的进程监控
	普通进程	在进程加载阶段可侦测，可采用手段：FD及通用回调
	脚本程序	可侦测，如cmd batch、powershell、python及WScript或CScript等，可侦测到解释程序的启动及相关命令行参数
	计划任务	可侦测，可通过父进程判断是不是计划任务，但计划任务的创建无从感知。当然计划任务的创建亦可从文件系统层感知并发现，但此方式只是个间接方案
	服务创建及修改	加载时通过进程回调可侦测，服务创建及修改可通过RD侦测
	驱动创建及修改	同服务
	WMI串链	可侦测新进程启动，但不能定位由谁创建
	DCOM串链	可侦测，但不能定位原始启动进程
	DDE加载	可侦测
	MSI安装拦截	可侦测
	PICO/WSL进程	可发现、可拦截（Win10系统）
	...
结束	-	通用回调可以在得到进程退出通知，但时机上已经太晚了；只能通过R3或R0 HOOK实现更早和更好时机上的拦截
	窗口消息	通过SendMessage/PostMessage/PostThreadMessage方式直接发送退出消息
	动作模拟	通过模拟按键及鼠标输入，直接发送ALT+F4或者鼠标点击事件
	结束进程	TerminateProcess/NtTerminateProcess
	停止或结束线程	SuspendThread/TerminateThread/ NtSuspendTHread/NtTerminateThread
	调试模式	NtDebugActiveProcess DebugSetProcessKillOnExit ...
	job调度	通过AssignProcessToJobObject及TerminateJobObject强制关闭进程，或通过job作业限制进程的执行调度
	WMI利用
	WinStation
	执行劫持	通过远程线程、APC或SetThreadContext将流程导向ExitProcess
	资源耗尽	耗尽进程的Handle/VM资源等以造成程序运行错误
	镜像破坏	通过VirtualProtectEx改变关键页面属性至PAGE_NOACCESS等，或通过WriteProcessMemory进行破坏
	内核攻击	方式非常多，不在我们考虑之列
	...
注入	-	在R3 HOOK统一框架设计中有详细描述，在此只简单列举常用方式。通过模块加载系统回调可以感知注入事件的发生，但不能直接拦截
	APC注入	R0及R3均可攻击，除R0/R3 HOOK外没有好的方案
	远程线程注入	R0及R3均可攻击，可通过线程创建回调侦测到
	消息钩子	可通过模块加载侦测，但无法溯源至“消息钩子”
	线程Context劫持	R0及R3均可攻击，不可侦测，只能采用HOOK方案
	内存写入	R0及R3均可攻击，不可侦测，只能采用HOOK方案
	UserModeCallback	不可侦测，只能采用HOOK方案
	Section Un-mapping	不可侦测：UnMapViewOfSection/NtUnmapViewOfSectionEx
	SetWindowLong[Ptr]注入	不可侦测，只能采用HOOK方案
	打印、输入法注入	可通过模块回调侦测到，但无法溯源
	DLL劫持	DLL搜索路径篡改、DLL文件替换等
	...
其它	-	隐私窃取、信息泄漏
	消息拦截	不可侦测
	KeyLogger	一般均是通过DLL注入实现
	白利用、提权、沙箱逃逸	发现与拦截均有难度

3. RD

RD防护通过注册表操作回调基本可以达成我们针对注册表操作的监控、审计及拦截的需求。注册表回调操作自Windows XP系统之后均有支持，但XP系统的支持并不完善，有可能需要采用OB HOOK等方式以弥补回调功能的缺失。

Vista之后系统针对注册表操作增加了事务处理，WDK已有演示程序。

操作	前置回调	后置回调
键删除	RegNtPreDeleteKey	RegNtPostDeleteKey: SRV2003
值创建、改变	RegNtPreSetValueKey	RegNtPostSetValueKey: SRV2003
值删除	RegNtPreDeleteValueKey	RegNtPostDeleteValueKey: SRV2003
键属性修改	RegNtPreSetInformationKey	RegNtPostSetInformationKey: SRV2003
键改名	RegNtPreRenameKey	RegNtPostRenameKey: SRV2003
子键枚举	RegNtPreEnumerateKey	RegNtPostEnumerateKey: SRV2003
值枚举	RegNtPreEnumerateValueKey	RegNtPostEnumerateValueKey: SRV2003
获取键信息	RegNtPreQueryKey	RegNtPostQueryKey: SRV2003
值内容提取	RegNtPreQueryValueKey	RegNtPostQueryValueKey: SRV2003
	RegNtPreQueryMultipleValueKey	RegNtPostQueryMultipleValueKey: SRV2003
子键创建	RegNtPreCreateKey	RegNtPostCreateKey
子键创建	RegNtPreCreateKeyEx: SRV2003	RegNtPostCreateKeyEx: SRV2003
子键打开	RegNtPreOpenKey	RegNtPostOpenKey
子键打开	RegNtPreOpenKeyEx: SRV2003	RegNtPostOpenKeyEx: SRV2003
子键关闭	RegNtPreKeyHandleClose	RegNtPostKeyHandleClose: SRV2003
	RegNtPreFlushKey: VISTA	RegNtPostFlushKey: VISTA
	RegNtPreLoadKey: VISTA	RegNtPostLoadKey: VISTA
	RegNtPreUnLoadKey: VISTA	RegNtPostUnLoadKey: VISTA
安全描述符提取	RegNtPreQueryKeySecurity: VISTA	RegNtPostQueryKeySecurity: VISTA
安全描述符设置	RegNtPreSetKeySecurity: VISTA	RegNtPostSetKeySecurity: VISTA
	RegNtPreRestoreKey: VISTA SP2	RegNtPostRestoreKey: VISTA SP2
	RegNtPreSaveKey: VISTA SP2	RegNtPostSaveKey: VISTA SP2
	RegNtPreReplaceKey: VISTA SP2	RegNtPostReplaceKey: VISTA SP2
	RegNtPreQueryKeyName: WIN10	RegNtPostQueryKeyName: WIN10
	RegNtCallbackObjectContextCleanup: VISTA

4. FD

针对FD的防护将基于Windows FS Mini Filter架构实现，Windows FS Mini Filter可支持Win2k SP4、XP SP2及最新的Windows操作系统。XP及Win2k系统上的支持最新版本Windows的支持有些差别，在实现时要多加注意。另外Vista之后文件操作事务的支持增加了攻击面，使得针对文件的攻击手段更加隐蔽，因此文件事务操作的支持是必须的。

Mini Filter框架不仅可对本地及网络文件进行监控，亦支持邮槽及命名管道的操作监控，后期可根据实际需求进行灵活扩展。

操作	描述	备注
IRP_MJ_CREATE	文件打开、删除、覆写(清空)操作
IRP_MJ_CLEANUP	文件句柄关闭
IRP_MJ_CLOSE
IRP_MJ_CREATE_MAILSLOT	只针对邮槽驱动
IRP_MJ_CREATE_NAMED_PIPE	只针对管道驱动
IRP_MJ_DEVICE_CONTROL	与应用层通信、存储设备通信
IRP_MJ_DIRECTORY_CONTROL	目录项管理
IRP_MJ_FILE_SYSTEM_CONTROL
IRP_MJ_FLUSH_BUFFERS
IRP_MJ_INTERNAL_DEVICE_CONTROL
IRP_MJ_LOCK_CONTROL	byte range lock（flock）支持
IRP_MJ_PNP	设备热插拔处理
IRP_MJ_QUERY_EA	EA数据流处理
IRP_MJ_QUERY_INFORMATION	文件信息处理
IRP_MJ_QUERY_QUOTA	用户Quota支持
IRP_MJ_QUERY_SECURITY	安全属性及安全描述
IRP_MJ_QUERY_VOLUME_INFORMATION	卷属性操作
IRP_MJ_READ	读操作
IRP_MJ_SET_EA	EA创建或写入
IRP_MJ_SET_INFORMATION	设置文件信息、改名、删除文件等
IRP_MJ_SET_QUOTA	设置用户Quota
IRP_MJ_SET_SECURITY	设置安全描述符
IRP_MJ_SET_VOLUME_INFORMATION	设置卷属性、卷标信息
IRP_MJ_SHUTDOWN	关机事件
IRP_MJ_SYSTEM_CONTROL	WMI
IRP_MJ_WRITE	写操作
IRP_MJ_ACQUIRE_FOR_CC_FLUSH	锁操作回调
IRP_MJ_ACQUIRE_FOR_MOD_WRITE	锁操作回调: mmap
IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION	锁操作回调: Section首次创建
IRP_MJ_FAST_IO_CHECK_IF_POSSIBLE	Fast i/o调用检测
IRP_MJ_MDL_READ	MDL i/o，一般用于SRV
IRP_MJ_MDL_READ_COMPLETE
IRP_MJ_MDL_WRITE_COMPLETE
IRP_MJ_NETWORK_QUERY_OPEN
IRP_MJ_PREPARE_MDL_WRITE
IRP_MJ_RELEASE_FOR_CC_FLUSH	锁操作回调
IRP_MJ_RELEASE_FOR_MOD_WRITE	锁操作回调
IRP_MJ_RELEASE_FOR_SECTION_SYNCHRONIZATION	锁操作回调
IRP_MJ_VOLUME_DISMOUNT	卷卸载操作
IRP_MJ_VOLUME_MOUNT	新卷加载操作