CN118035045A

CN118035045A - 一种基于qnx系统的系统调用检测方法

Info

Publication number: CN118035045A
Application number: CN202410431522.0A
Authority: CN
Inventors: 解义全; 杨旭; 熊平海; 赵焕宇; 宋雪冬; 刘孙义
Original assignee: Guangdong Weichen Information Technology Co ltd
Current assignee: Guangdong Weichen Information Technology Co ltd
Priority date: 2024-04-11
Filing date: 2024-04-11
Publication date: 2024-05-14

Abstract

本发明涉及系统检测技术领域，具体地说，提供一种基于QNX系统的系统调用检测方法，其包括以下步骤：S1：使用tracelogger将跟踪内核事件信息记录到文件中；S2：使用traceprinter解析文件内容；S3：逐行分析跟踪内核事件；S4：得到结果。本发明能够较佳地检测系统调用，具有时效性。

Description

一种基于QNX系统的系统调用检测方法

技术领域

本发明涉及系统检测技术领域，具体地说，涉及一种基于QNX系统的系统调用检测方法。

背景技术

操作系统为用户态运行的进程与硬件设备（如CPU、磁盘等）进行交互提供了一组接口。在应用程序和硬件之间设置一个额外层具有很多优点。首先，这使得应用开发更加容易，把应用开发人员从学习硬件设备的底层编程特性中解放出来。其次，这极大地提高了系统的安全性，因为内核在试图满足某个请求之前在接口级就可以检查这种请求的正确性。最后，这些接口使得程序更具有可移植性，因为只要任何内核所提供的一组接口相同，那么在任一内核之上就可以正确地编译和执行程序。

Unix系统利用内核所提供的系统调用（system call）实现了用户态进程和硬件设备之间的大部分接口。QNX是一种商用的遵从POSIX规范的类Unix实时操作系统，目标市场主要是面向嵌入式系统。它可能是最成功的微内核操作系统之一。

可移植操作系统接口（Portable Operating System Interface of UNIX，缩写为POSIX），其发布者为电气与电子工程师协会（Institute of Electrical and ElectronicsEngineers，简称IEEE）。POSIX是IEEE为要在各种Unix操作系统上运行的软件而定义的一系列API标准的总称，其正式称呼为IEEE 1003，已经被国际标准化组织（InternationalStandards Organization，ISO）所接受，又被命名为 ISO/IEC 9945-1:1990 标准。POSIX标准针对API而不针对系统调用。判断一个系统是否与POSIX兼容要看它是否提供了一组合适的应用程序接口，而不管它是如何实现的。事实上，一些非Unix系统被认为是与POSIX兼容的，是因为他们在用户态的库函数中提供了传统的Unix能提供的所有服务。

应用编程接口（API）与系统调用其实是有所不同的，API只是一个函数的定义，说明了如何获得一个给定的服务；而系统调用则是通过软中断向内核态发出一个明确的请求。Unix系统给应用程序开发者提供了很多API的库函数，libc的标识C库所定义的一些API引用了封装例程（wrapper routine，其唯一目的就是发布系统调用）。通常情况下，每个系统调用对应一个封装例程，而封装例程定义了应用程序能引用的API。但反之则不然，一个API则不一定对应一个特定的系统调用。首先，一些API可能直接提供用户态的服务（如一些抽象的数学函数）。其次，一个单独的API可能调用几个系统调用。此外，几个API函数可能调用封装了不同功能的同一系统调用。例如C库中的函数malloc()、calloc()、和free()等POSIX API，这几个函数都利用brk()系统调用来扩大或缩小进程的堆区使用空间。

但是， API和系统调用之间测差别是没有关系的，唯一相关的事件就是函数名、参数类型及返回值的含义。然而，这种差别确实有关系，应为系统调用属于内核，而用户态的库函数不属于内核，所以，系统调用发生在内核，通过应用层无法直接获取到相关数据，需要对系统调用进行检测。

发明内容

本发明的内容是提供一种基于QNX系统的系统调用检测方法，其能够较佳地检测系统调用。

根据本发明的一种基于QNX系统的系统调用检测方法，其包括以下步骤：

S1：使用tracelogger将跟踪内核事件信息记录到文件中；

S2：使用traceprinter解析文件内容；

S3：逐行分析跟踪内核事件；

S4：得到结果。

作为优选，S1中，具体为：

使用system()函数执行tracelogger -f sys_call.kev -n N命令，其中，sys_call.kev为跟踪内核事件，能指定具体路径，命令的默认模式为迭代模式，N表示在迭代模式中要填充的缓冲区数量；命令执行成功之后，会在指定的地方生成sys_call.kev文件，若没指定路径则在当前位置生成此文件，若再次执行此命令，则文件中的内容会被更新，而不是追加。

作为优选，S2中，traceprinter解析文件内容中记录的线性存储的时间事件，并将生成的格式化流发送到标准输出；traceprinter使用popen()函数将文件内容以文本流的方式解析并读取到内存中。

作为优选，S3中，具体为：

当本行数据中含有KER_CALL字段的数据时，记录内核事件，继续读取下一行并判断是否含有COMM字段或THREAD字段，若不存在则判断是否存在KER_CALL字段重新开始新的判断；若存在即记录PID号，然后再读取下一行判断是否存在THREAD或者COMM字段，若不存在则判断是否存在KER_CALL字段重新开始新的判断；如果存在则再读取下一行并判断是否存在KER_EXIT字段，若不存在则判断是否存在KER_CALL字段重新开始新的判断；若存在则认定为PID进行了一次系统调用。

作为优选，S4中，利用分析得出的结果，进一步分析进程是否调用了不应该在本进程中出现的系统调用，或者监控系统调用被哪些进程所调用，从而判断主机中的进程是否处于安全的运行状态。

本发明的有益效果如下：

本发明能够较佳地检测系统调用，具有时效性，能够实时的检测出QNX中的系统调用；能够结合系统调用上下文分析进程前后系统调用的关联性；检测系统调用时不影响其检测进程的正常运行。

附图说明

图1为实施例中一种基于QNX系统的系统调用检测方法的流程图。

具体实施方式

为进一步了解本发明的内容，结合附图和实施例对本发明作详细描述。应当理解的是，实施例仅仅是对本发明进行解释而并非限定。

实施例

如图1所示，本实施例提供了一种基于QNX系统的系统调用检测方法，其包括以下步骤：

S1：使用tracelogger将跟踪内核事件信息记录到文件中；

S1中，具体为：

使用system()函数执行“tracelogger -f sys_call.kev -n N”命令，其中，“sys_call.kev”为跟踪内核事件，能指定具体路径，命令的默认模式为迭代模式，N表示在迭代模式中要填充的缓冲区数量，默认为32，它决定了“sys_call.kev”文件的大小，也间接决定了每一次分析周期的大小；命令执行成功之后，会在指定的地方生成“sys_call.kev”文件，若没指定路径则在当前位置生成此文件，若再次执行此命令，则文件中的内容会被更新，而不是追加。

本实施例使用了QNX提供的跟踪记录器——tracelogger，该服务从插入指令的内核（procnto*-instr）接收事件，并将它们保存在文件或设备上，以供以后分析。默认情况下，tracelogger将事件保存在/dev/shmem/trtracebuffer.kev中。.kev扩展名是“内核事件”的缩写；集成开发环境在系统档案器中打开具有此扩展名的文件。该工具的使用前提是将tracelogger工具包安装到系统中，即在/usr/sbin/目录下会有tracelogger的可执行文件。使用方法则为在root用户模式下使用使用命令加选项的方式（即tracelogger[options]）执行即可。在跟踪系统调用的内核信息时，主要使用到以下选项：

-f file：存储记录事件的文件的名称。默认为/dev/shmem/tracebuffer.kev。

-n num_buffers：在迭代模式中要填充的缓冲区数量，默认为32，若指定0则为无限制迭代。

-w：记录广泛事件，默认情况下是记录快速事件。

S2：使用traceprinter解析文件内容；

traceprinter解析文件内容中记录的线性存储的时间事件，并将生成的格式化流发送到标准输出（或发送到由-o选项标识的文件）；由于tracelogger工具生成的文件无法直接读取，在分析“sys_call.kev”文件时需要借助于traceprinter工具，所以traceprinter使用popen()函数将文件内容以文本流的方式解析并读取到内存中，然后使用fgets()函数逐行读取进行分析。

本实施例使用了QNX提供的解析和显示跟踪记录器生成的跟踪文件的内容的工具——traceprinter。该工具的使用前提是将traceprinter工具包安装到系统中，即在/usr/sbin/目录下会有traceprinter的可执行文件。使用方法则为在root用户模式下使用使用命令加选项的方式（即traceprinter [options]）执行即可。在跟踪系统调用的内核信息时，主要使用到以下选项：

-f file：指定跟踪记录器生成的跟踪文件，默认为/dev/shmem/tracebuffer.kev。

S3：逐行分析跟踪内核事件；

具体为：

traceprinter解析出来的信息中每行的的格式为t:clk_time CPU:cpu class:event: P1: P2: P3: ... Pn。对本格式数据每列的解释如下：

clk_time：注册跟踪事件时CPU时钟周期中的时间偏移量。64位变量分为两个32位十六进制数字（msb和lsb）。除了在跟踪开始时和lsb滚动更新时，仅显示lsb编号。

cpu：一个2位十进制数字，表示注册事件的 CPU核。变量始终为00，除非系统中有多个 CPU核，如果系统中有四个CPU核，则CPU编号范围为00到03。在初始化期间，当启动程序探测系统时，CPU编号分配给特定的CPU核。

class、event、Parameters：这三个变量是可选的，具体取决于记录的跟踪信息和变量后跟的参数变量，参数的数量和类型取决于关联的跟踪记录器是使用快速还是宽发射模式。每条迹线包含一条或无、以及一个或多个参数变量，参数和返回值的数量取决于事件以及是否跟踪文件是使用快速或宽跟踪模式生成的。表1说明了每个组合和对应的参数。

表1 组合和对应的参数表

在检测系统调用的功能中，主要关注的是class和enent，它们分别表示事件的类型和事件名称。当一个进程进行系统调用时，内核中会追踪到连续四个事件类型，分别为：KER_CALL、COMM、THREAD、KER_EXIT。

内核事件信息所表示的内容为内核接收到一个系统调用的请求，对应的事件为MSG_REPLYV，其对应的内核函数原型为int MsgReplyv( int rcvid, int status, constiov_t* riov, int rparts )，传入的参数为rcvid=0x00000019，status=0x0000000e，此处忽略后两位参数，忽略原因是应为该函数肯能对应多个应用层的API实现不同的功能而传递不同的参数。与之通信的进程PID为1527830，系统调用结束后返回值ret_val=0。通过分析连续四行如此特征的数据，即可判断进程进行了一次系统调用。

对于事件类型为“KER_CALL”和“KER_EXIT”所对应的具体事件，在QNX官网中的“Utilities&Libraries”部分下的“C Library Reference”中，都有内核函数与之对应。比如“MSG_REPLYV”事件对应的内核函数为“MsgReplyv()”和“MsgReplyv_r()”；“MSG_SEND_PULSE”事件对应的内核函数为“MsgSendPulse()”或“MsgSendPulse_r()”等等。

需要注意的是，带有字段“COMM”的行和带有“THREAD”的行在顺序上可能不固定，但都应居于“KER_CALL”所在行和“KER_EXIT”所在行之间。

S4：得到结果。

利用分析得出的结果，进一步分析进程是否调用了不应该在本进程中出现的系统调用，或者监控系统调用被哪些进程所调用，从而判断主机中的进程是否处于安全的运行状态。

本实施例能够较佳地检测系统调用，具有时效性，能够实时的检测出QNX中的系统调用；能够结合系统调用上下文分析进程前后系统调用的关联性；检测系统调用时不影响其检测进程的正常运行。

以上示意性的对本发明及其实施方式进行了描述，该描述没有限制性，附图中所示的也只是本发明的实施方式之一，实际的结构并不局限于此。所以，如果本领域的普通技术人员受其启示，在不脱离本发明创造宗旨的情况下，不经创造性的设计出与该技术方案相似的结构方式及实施例，均应属于本发明的保护范围。

Claims

1.一种基于QNX系统的系统调用检测方法，其特征在于：包括以下步骤：

S1：使用tracelogger将跟踪内核事件信息记录到文件中；

S2：使用traceprinter解析文件内容；

S3：逐行分析跟踪内核事件；

S4：得到结果。

2.根据权利要求1所述的一种基于QNX系统的系统调用检测方法，其特征在于：S1中，具体为：

3.根据权利要求2所述的一种基于QNX系统的系统调用检测方法，其特征在于：S2中，traceprinter解析文件内容中记录的线性存储的时间事件，并将生成的格式化流发送到标准输出；traceprinter使用popen()函数将文件内容以文本流的方式解析并读取到内存中。

4.根据权利要求3所述的一种基于QNX系统的系统调用检测方法，其特征在于：S3中，具体为：

5.根据权利要求4所述的一种基于QNX系统的系统调用检测方法，其特征在于：S4中，利用分析得出的结果，进一步分析进程是否调用了不应该在本进程中出现的系统调用，或者监控系统调用被哪些进程所调用，从而判断主机中的进程是否处于安全的运行状态。