sip 与 kext 签名是分层验证关系：先验签名（gatekeeper 接受、team id 有效、arm64e 架构），再由 sip 决定加载；即使签名合规且用户点击“允许”，sip 仍静默拦截非 apple 驱动；关闭 sip 不豁免签名要求；推荐迁移至 driverkit 或 system extension。
macOS 的系统完整性保护（SIP）和内核扩展（kext）签名不是并列关系，而是分层验证机制：SIP 是运行时的“守门人”，签名是它放行前必须查验的“通行证”。两者缺一不可，且顺序固定——先验签名，再由 SIP 决定是否加载。
签名是 SIP 放行的前提条件
SIP 默认启用时，不会直接拒绝所有第三方 kext，而是先检查其代码签名是否有效。签名无效（如未公证、Team ID 错误、证书过期或被撤销），系统连“允许”按钮都不会显示在「隐私与安全性」设置中。这意味着用户根本无法完成手动批准这一步。
- 验证签名是否被 Gatekeeper 接受：
spctl --assess --type execute /Library/Extensions/YourDriver.kext，返回 accepted 才算通过第一关 - 查看签名详情：
codesign -dv --verbose=4 /Library/Extensions/YourDriver.kext，确认含有效 TeamIdentifier 和 Notarization Date - 仅验证不加载：
sudo kextutil -t /Library/Extensions/YourDriver.kext，无 error/warning 才说明签名与架构（如 arm64e）均合规
SIP 控制加载行为本身
即使签名完全正确、用户也已在设置中点击“允许”，SIP 仍会拦截绝大多数非 Apple 的 I/O Kit 驱动。它不是简单地“阻止加载”，而是在内核层面静默拒绝——kextload 命令不报错、不提示、也不生效。
- 检查 SIP 状态：
csrutil status，显示 enabled 即处于受保护状态 - Apple Silicon Mac 上，SIP 还强制要求 kext 必须为 arm64e 架构，x86_64 或通用二进制均无法通过验证
- 关闭 SIP 并不能绕过签名要求：macOS Ventura 起，即使 SIP 关闭，未经 Apple Developer ID 签名并公证的 kext 依然无法加载
用户批准是 SIP 框架内的授权环节
用户在「系统设置 > 隐私与安全性 > 安全性」中点击“允许”，不是绕过 SIP，而是在 SIP 框架下登记信任。该操作将 bundle ID 或 team ID 写入本地策略数据库：sudo sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy "SELECT * FROM kext_policy WHERE allowed = 1;"。未出现在此表中，kext 就不会被纳入 AuxKC（辅助内核缓存）构建流程。
- Monterey 及更早版本：批准为单次有效，系统升级后需重新点击
- Ventura 及更新版本：支持“长期信任”，但前提是签名持续有效且未被撤销
- 终端命令（如
sudo kextload）无法跳过此步骤，未批准则静默失败
替代路径比硬刚 kext 更可靠
苹果自 macOS Catalina 起持续弱化 kext 支持，Big Sur 后进一步收紧，Sequoia 中已明确推动迁移。当前推荐路径不是对抗 SIP，而是适配新架构：
- 驱动应优先迁移到 DriverKit（用户态驱动框架），无需内核权限，天然兼容 SIP
- 功能类扩展改用 System Extension（如 Network Extensions、Endpoint Security），运行于用户空间
- 黑苹果等特殊场景若必须用 kext，需确保使用 OpenCore 引导 + 正确配置
Kernel -> Add与Quirks，且所有 kext 均经重签名与公证
