📚 课程目录第3章 Binder驱动层职责

3. Binder驱动层职责：设备节点、ioctl指令集、binder_transaction_data结构

3.1 驱动层全景与分层边界

Binder驱动（drivers/android/binder.c）是Android IPC的内核态核心引擎，运行在内核空间，为所有用户态进程提供跨进程通信基座。它在系统分层中处于承上启下的关键位置：上方对接Framework层的libbinder（Native）和BinderProxy（Java），下方直接操作物理内存与进程调度。驱动层是唯一运行在内核态的Binder组件，负责执行权限校验、内存映射（binder_mmap）、事务路由、Binder节点与引用的生命周期管理。

模块边界划分：用户态通过唯一的设备节点 /dev/binder 发起系统调用，驱动层接收并解析 ioctl 指令，将事务数据整理为 binder_transaction_data 结构体，最终投递到目标进程的事务队列中。驱动层不关心上层业务语义，只负责数据的安全搬运和跨进程路由。

3.2 核心组件职责与模块边界

组件	文件/接口	核心职责	边界与约束
设备节点	`/dev/binder`	提供进程与驱动的文件交互入口；通过 `open()` 获取文件描述符，通过 `mmap()` 分配内核缓冲区	每个进程仅允许 `mmap` 一次；缓冲区大小上限为 4MB（默认 1MB - 8KB）
ioctl 指令集	`binder_ioctl()`	控制命令通道；解析并分发 `BINDER_WRITE_READ`、`BINDER_SET_CONTEXT_MGR` 等指令	所有操作必须经过 `ioctl` 系统调用；权限校验在驱动入口完成
binder_transaction_data	内核结构体	承载跨进程事务数据（包括目标句柄、操作码、序列化缓冲区、对象偏移表）	数据在驱动层完成从发送方到接收方的内存拷贝或共享

3.3 数据流与控制流解析

Binder 驱动层采用控制流与数据流分离的设计：控制流通过 ioctl 指令触发，指定操作类型；数据流通过 binder_transaction_data 结构体传递序列化后的 Parcel 数据。一次典型的跨进程调用流程如下：

客户端进程将方法参数序列化为 Parcel，封装到 binder_transaction_data 中。
客户端调用 ioctl(fd, BINDER_WRITE_READ, &bwr) 陷入内核。
驱动层校验 PID/UID，查找目标 Binder 实体，将事务排队到目标进程的事务队列。
目标进程工作线程被唤醒，读取事务数据，反序列化 Parcel 并执行目标方法。
返回结果沿相同路径回到客户端。

信任链路锚点：用户态进程通过 /dev/binder 发起调用时，驱动层会提取调用者的 PID 和 EUID，写入 binder_transaction_data.sender_pid 和 sender_euid。这两个字段由内核填充，用户态不可伪造，是整个 Binder 信任模型的基础。

3.4 选型权衡与风险点

维度	Binder 驱动的选择	备选方案（未采用的原因）
系统调用接口	ioctl（同步、多命令复用、灵活）	sysfs（不适合大数据量交互）；Netlink（异步，不适合同步 IPC 语义）
数据传递方式	内核缓冲区 + 一次拷贝（通过 `mmap` 避免两次拷贝）	管道/套接字（两次数据拷贝，性能差 30%~50%）
线程管理	驱动层维护 Binder 线程池（`BINDER_SET_MAX_THREADS`）	完全由用户态管理（无法确保公平调度）

关键风险点：

内核内存压力：每个事务最多分配近 1MB 内核缓冲区，高并发场景或发送方阻塞可导致内核内存耗尽（OOM）。落地时必须监控 /proc/meminfo 的 Slab 使用量。
Use-After-Free (UAF)：若驱动层在释放 Binder 节点时未正确清理引用，悬空指针可被利用提权。必须保证内核版本包含 CVE 补丁。
事务大小硬限制：单次 binder_transaction_data 数据大小不得超过 (1MB - 8KB)，超出会触发 BR_FAILED_REPLY，业务层必须做数据分片。

3.5 核心数据结构：binder_transaction_data

该结构体是驱动层数据流的核心载体，所有跨进程数据都通过它传递。下面是关键字段解析：

字段	类型	说明	数据流向
`target.handle`	`__u32`	目标 Binder 引用句柄（相对于当前进程）	客户端 → 驱动
`code`	`__u32`	事务操作码（如 `TRANSACTION_TYPE`）	客户端 → 驱动 → 服务端
`sender_pid`	`__u32`	发送方进程 ID（由驱动填充）	驱动 → 服务端
`sender_euid`	`__u32`	发送方有效用户 ID（由驱动填充）	驱动 → 服务端
`data.ptr.buffer`	`binder_uintptr_t`	指向内核区序列化 Parcel 数据的指针	客户端 → 驱动 → 服务端
`data.ptr.offsets`	`binder_uintptr_t`	指向 Binder 对象偏移表的指针	客户端 → 驱动 → 服务端

struct binder_transaction_data {
    union {
        __u32   handle;
        binder_uintptr_t ptr;
    } target;
    binder_uintptr_t cookie;
    __u32           code;
    __u32           flags;
    __u32           sender_pid;
    __u32           sender_euid;
    binder_size_t   data_size;
    binder_size_t   offsets_size;
    union {
        struct {
            binder_uintptr_t buffer;
            binder_uintptr_t offsets;
        } ptr;
        __u8 buf[8];
    } data;
};

3.6 落地步骤与验收标准

步骤	操作	预期结果
1. 内核配置	`CONFIG_ANDROID_BINDER_IPC=y`	内核编译包含 Binder 驱动
2. 设备节点注册	`device_create(binder_class)`	`/dev/binder` 节点出现，主设备号 10，次设备号 53
3. ioctl 功能验证	用户态调用 `ioctl(fd, BINDER_WRITE_READ, &bwr)`	返回 0，驱动日志输出 `binder: release 0:...`
4. 权限校验测试	非特权进程尝试 `BINDER_SET_CONTEXT_MGR`	返回 `EPERM`（权限拒绝）
5. 压力测试	循环发送大事务（接近 1MB）	驱动层不崩溃，不泄漏，`slabinfo` 稳定

验收命令示例：

# 1. 检查设备节点是否存在
adb shell ls -l /dev/binder
crw------- 1 root root 10, 53  ...  /dev/binder

# 2. 尝试直接读写（预期失败，因为必须使用 ioctl）
adb shell "su -c 'echo test > /dev/binder'"
sh: /dev/binder: Permission denied

# 3. 内核日志确认驱动初始化完成
adb shell dmesg | grep binder
[    0.000000] binder: 1:1 device 'binder' initialized