CRIU项目中Compel工具sys_open系统调用返回-1问题分析

问题背景

在CRIU项目的Compel工具使用过程中，开发者发现了一个关于sys_open系统调用的异常行为。当尝试在寄生进程中打开多个文件时，sys_open总是返回-1，尽管实际上文件描述符已经被成功创建并添加到受害进程中。

现象描述

开发者在测试Compel工具时，修改了compel/test/infect中的代码，在parasite_daemon_cmd函数中添加了sys_open调用，期望能够打开/etc/resolv.conf文件。然而观察到的现象是：

1. 所有sys_open调用都返回-1
2. 第一次打开操作确实在受害进程中创建了新的文件描述符，但仍然返回-1
3. 通过检查/proc/[pid]/fd目录确认文件描述符确实被创建

技术分析

这个问题的根本原因在于Compel工具中寄生进程命令处理函数的返回值机制。在Compel的设计中，parasite_daemon_cmd函数不应该返回非零值。当该函数返回非零值时，会导致RPC通信协议中断，使得调用方无法正确获取系统调用的实际返回值。

正确的做法应该是：

1. 通过参数指针返回需要传递的数据
2. 保持函数返回值为0表示成功
3. 让调用方通过参数获取实际的操作结果

解决方案

对于需要在寄生进程中获取文件描述符的场景，应该修改代码结构如下：

int parasite_daemon_cmd(int cmd, void *args)
{
    int v;
    int *ret_fd = (int *)args;  // 使用参数指针返回文件描述符
    
    switch (cmd) {
    case PARASITE_CMD_OPEN_FILE:
        *ret_fd = sys_open("/etc/resolv.conf", O_RDWR, 0);
        v = 0;  // 表示操作成功
        break;
    // 其他命令处理...
    default:
        v = -1;
        break;
    }
    
    sys_write(1, &v, sizeof(int));
    return 0;  // 始终保持返回0
}

深入理解

Compel工具中的寄生进程通信机制基于特定的RPC协议，这个协议设计上要求命令处理函数必须返回0表示成功。任何非零返回值都会被解释为错误，导致通信中断。这种设计是为了确保寄生进程状态的确定性，避免因意外错误导致寄生进程进入不可控状态。

在实际应用中，开发者需要注意：

1. 寄生进程中的系统调用返回值应通过参数传递
2. 命令处理函数必须返回0
3. 错误处理应通过设置特定的返回值或错误码来实现

总结

通过这个案例，我们可以更深入地理解Compel工具中寄生进程的通信机制和设计哲学。正确的返回值处理对于确保寄生进程稳定运行至关重要。开发者在使用Compel工具时，应当遵循其设计规范，通过参数而非返回值传递操作结果，这样才能确保寄生进程功能的正确执行。