Mac OCSP末日的六个月后，我们又来了，我又来了。那时，我发现信任进程在连接ocsp.apple.com时遇到了问题，通过阻止连接该域的尝试可以暂时解决这个问题(例如在《Little Snitch》中)。昨天我开始注意到信任的另一个问题，但这次的问题有点不同:非常高的CPU使用率。昨天我也从其他几个人那里听说了同样的问题，其中一个很有帮助地向我推荐了reddit上的这个帖子，还有更多的报道。经过调查，我发现nsurlsessiond进程正在连接服务器valid.apple.com，然后信任CPU立即从0%跳到了100%。似乎这个问题可以通过阻止nsurlsessiond连接到valid.apple.com来临时解决。您可能必须重新启动或强制退出信任，以使其CPU使用恢复正常。需要注意的是，这只是针对CPU使用问题的临时解决方案;trust是一个重要的macOS系统进程，它检查证书的有效性和撤销状态，所以你可能不想永远阻止valid.apple.com。
我可以在运行最新macOS 11.3.1的M1 Mac mini上轻松地重现这个问题。我也可以在我的英特尔MacBook Pro笔记本电脑上复制它，不过不那么可靠，我运行的macOS 10.14.6打了最新的安全更新。(我能听到我的MacBook Pro上风扇的声音，这是我第一次注意到这个问题。而我几乎从未听到过Mac mini粉丝的声音。)我无法用macOS 11.2.1或未打补丁的10.15.7重新启动它到我的外置磁盘，所以这个问题可能与4月26日的安全更新有关。稍后我将尝试更新那些未打补丁的卷，但我还没有时间，因为更新可能需要几个小时(唉)。无论如何，我没有花太多时间测试外部引导卷，所以我不想肯定地说这个问题不能在旧的macOS版本上重现。
在我的MacBook Pro上，我把Little Snitch设置为请求nsurlsessiond连接尝试。这里你可以看到，在我把我的MacBook Pro插入电源适配器之后，它正试图连接到valid.apple.com。此时信任的CPU使用率为0%。
我点击允许按钮，突然信任CPU跳了很多。
这是我的Mac mini的截图，因为CPU使用率高，我被迫退出信任。
当信任重启时，CPU使用率再次上升，并且每次我在Console日志中看到关于com.apple.powerlog.plxpclogger.xpc的消息。
在我的Mac mini上，这种情况大约每5分钟发生一次，当然，它总是连着交流电源。我的印象是，这都是由某种与电源管理相关的macOS诊断日志引起的，这就是为什么当我插入电源线时，它发生在我的MacBook Pro上。(注意，我在这两款mac电脑的系统首选项的安全与隐私窗格的隐私选项卡中都禁用了分析功能。)
我选取了一个信任过程的样本，它在sqlite函数中花费了大量时间。这是有意义的，因为信任将证书信息存储在SQLite数据库中。可以使用lsof命令行工具查看trustd打开了哪些文件。我还没来得及分析数据库。我的理论是，valid.apple.com上的配置发生了某种变化，而macOS由于某种原因在下载数据时遇到了麻烦。因此，如果你阻止到valid.apple.com的连接，你就可以避免这个问题。
附录:解决方案
我相信我已经找到了解决这个问题的“永久”办法。这在我的M1 Mac mini和Intel MacBook Pro上都适用。我引导到恢复模式，并重命名sqlite3文件。(我保留了这些文件，而不是删除它们，以防万一。)这些文件位于目录/private/var/protected/trustd/ 在 Big Sur 系统上 和/Library/Keychains/crls/ 在Mojave 系统上 。当我重新引导到macOS时，文件重新生成。下一次nsurlsessiond连接到valid.apple.com时一切正常。信任的CPU使用率确实暂时上升了，但它在几秒钟内回到了0%，并停留在那里。到目前为止，一切顺利!
出于取证的目的，我尝试比较新旧数据库，但它们的大小都超过了10mb，而且有足够的差异，我不想在上面花太多时间。我已经在这上面花了太多时间了!我的事后分析理论是，在某个时候，苹果的证书撤销列表中出现了一些错误数据，每个人都下载了这些错误数据，然后信任系统就卡住了。不管怎样，看起来在删除并重新生成valid之后，阻塞valid.apple.com不再是必要的。数据库sqlite3。和往常一样，你自己冒险黑进你的系统，做备份，我不负责。
在 /private/etc/hosts 中增加
0.0.0.0 valid.apple.com
