macos 持续强化 sip 对 kext 的管控，要求签名、用户授权与启动配置三重验证，强制向用户空间系统扩展迁移。未签名 kext 被内核直接拒绝；已签名但未授权的需手动批准并重启；driverkit 等系统扩展成主流替代方案，无需内核权限、安装即用、稳定性更高。
macOS 系统更新持续强化 SIP（系统完整性保护）对内核扩展（kext）的管控，核心趋势是限制收紧、替代方案明确、验证链条更严。这不是简单的“开关问题”，而是苹果推动整个生态向用户空间迁移的安全演进。
内核扩展加载门槛显著提高
SIP 默认禁止未签名或未经用户显式批准的第三方 kext 加载。自 macOS 10.10 Yosemite 起，所有 kext 必须由苹果认证的开发者证书签名；从 macOS 11 Big Sur 开始，搭载 Apple 芯片的 Mac 还需将安全启动配置为“降低安全性”才能加载第三方 kext；macOS Sequoia 15.2（2024年12月）进一步修复了 CVE-2024-44243 漏洞，堵住曾被用于绕过 SIP 安装恶意驱动的路径。这意味着：即使关闭 SIP，也无法绕过签名和启动配置双重校验。
- 未签名 kext 直接被内核拒绝加载，不触发提示
- 已签名但未获用户批准的 kext，在“系统设置 > 隐私与安全性”中显示为待授权项，需手动点击“允许”
- 批准后仍需重启系统，kext 才能真正注入内核
系统扩展（System Extensions）成为主流替代路径
苹果明确不再推荐使用 kext，转而推广在用户空间运行的系统扩展。这类扩展基于 DriverKit、NetworkExtension 等框架，无需内核权限即可实现 USB 设备控制、网络代理、音频路由等功能。它们受 SIP 保护机制影响极小，因为不触碰 /System 或 /Library/Extensions 等受保护路径，也不依赖内核级注入。
- 安装即用，无需重启
- 权限粒度更细，例如仅申请访问特定 USB 接口或网络流量
- 崩溃不会导致内核 panic，系统稳定性更高
开发者必须适配三重验证链
以 360Controller 为例，其驱动能否运行取决于完整通过三个环节：安装包签名验证 → 用户在隐私设置中授权开发者证书 → 内核加载时再次校验 kext 文件签名。任一环节失败都会导致功能不可用。macOS 更新常伴随签名策略微调（如证书有效期缩短、哈希算法升级），旧版驱动可能因签名过期或格式不兼容而失效。
- 测试环境需覆盖不同 macOS 版本（尤其是新发布的 Sequoia 及后续更新）
- 发布前必须用最新 Xcode 和 Developer ID 证书重新签名
- 不能复用开发阶段的 ad-hoc 或测试证书用于正式分发
用户侧操作空间持续收窄
虽然可通过恢复模式运行 csrutil 修改 SIP 配置（如 csrutil enable --without kext），但该操作本身在 Apple Silicon Mac 上受限于安全启动策略，且 macOS 更新后 SIP 会自动重置为启用状态。更重要的是，单纯关闭 kext 保护并不能解决签名缺失或证书未授权的问题——系统仍会拦截加载。
- 普通用户几乎无法绕过证书授权步骤
- 企业设备可通过 MDM 配置描述文件预授权指定开发者或类型扩展
- 个人用户若频繁需要加载第三方 kext，应优先考虑是否已有对应功能的系统扩展版本
