fwupd项目中的EFI变量空间检测问题解析

在Linux固件更新工具fwupd的最新版本中，用户在使用较旧内核版本时可能会遇到"getting efivars free space is not supported"的错误提示。这个问题主要出现在尝试更新UEFI CA证书时，特别是在6.1.141等较旧的内核版本上。

问题背景

fwupd作为一个系统固件管理工具，需要与UEFI固件交互，其中就包括对EFI变量的读写操作。在较新版本的fwupd中，开发团队引入了一项重要的安全检查机制——在执行更新操作前，会先检测EFI变量存储空间(efivarfs)的剩余容量。

这个检查机制的引入背景是：随着新的安全数据库(db)和黑名单数据库(dbx)体积的不断增大，很多用户在更新时由于NVRAM空间不足而导致失败。因此，fwupd现在会在更新前确认系统有足够的空间来容纳这些更新。

技术细节

在Linux系统中，EFI变量通过efivarfs这个特殊的文件系统暴露给用户空间。虽然它看起来像一个普通的文件系统，但实际上它的存储介质是主板上的SPI-NOR闪存芯片，而非传统的存储设备。

问题出现在较旧的内核版本上，这些版本虽然支持efivarfs，但没有实现获取总空间和剩余空间的统计功能。当fwupd尝试查询这些信息时，内核返回0值，导致工具误认为没有可用空间而拒绝执行更新。

解决方案讨论

开发团队针对这个问题提出了两种可能的解决方案：

1. 宽松策略：当检测到空间统计功能不可用时(返回0值)，仍然允许更新操作继续进行，寄希望于实际有足够的空间。

2. 严格策略：只允许在支持空间统计功能的内核上运行更新操作，确保每次更新都有可靠的空间保障。

目前看来，开发团队更倾向于第一种方案，因为：

• 许多企业发行版(如RHEL)会向后移植功能，单纯依赖内核版本检查不可靠
• 在大多数情况下，即使统计功能不可用，实际空间也是足够的
• 完全阻止更新会影响用户体验，特别是对那些无法轻易升级内核的用户

用户建议

对于遇到此问题的用户，可以考虑以下解决方案：

• 升级到更新的内核版本(如6.15.3)，这些版本通常已经实现了完整的空间统计功能
• 如果必须使用旧内核，可以等待fwupd的下一个版本，预计会采用更宽松的空间检查策略
• 对于关键系统更新，可以考虑临时切换到较新内核完成固件更新

这个问题反映了固件管理工具在兼容性和安全性之间的平衡考量，也展示了Linux生态系统中内核与用户空间工具协同工作的复杂性。随着UEFI安全功能的不断增强，这类空间管理问题可能会变得更加常见，值得系统管理员和开发者持续关注。