iot2050-efivarfs-helper: handle efivarfs dynamically during runtime #578
Conversation
Instead of enforcing a persistent read-write (rw) mount via /etc/fstab, this change ensures efivarfs is mounted and remounted dynamically during command execution. This approach improves flexibility, avoids potential conflicts, and ensures efivarfs is available with the correct permissions only when needed. Key improvements: * Removed the need for a persistent rw entry in /etc/fstab. * Ensures efivarfs is correctly mounted and remounted as needed during execution. * Prevents unnecessary system-wide modifications while maintaining secure access. This update enhances robustness and ensures a controlled, on-demand handling of efivarfs. Signed-off-by: Rakesh Kumar <[email protected]>
|
@BaochengSu , could you please review the changes, thanks! |
|
Changes have been tested on iot2050 device, below are the logs `root@iot2050:~# iot2050-efivarfs-helper -- -f db.auth db Return code: 0 Adding the immutable flag of /sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f... Done. root@iot2050:~# iot2050-efivarfs-helper -- -f nodb.auth db Return code: 0 Adding the immutable flag of /sys/firmware/efi/efivars/KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c... Done. |
| if mount_err_msg == 'not mounted.': | ||
| ''' | ||
| By default, the kernel or systemd mounts efivarfs as read-only (ro) to prevent | ||
| accidental modifications to UEFI variables, which are critical for system operation. |
There was a problem hiding this comment.
I doubt that. Also efibootmgr needs this as r/w, and I don't think it remounts it on demand.
Furthermore, your patch leaves efivarfs r/w mounted behind - where is the improvement then?
There was a problem hiding this comment.
I guess most of the related tools/applications expect this efivarfs mounted as R/W for a normal operation.
Additionally, there is already an immutable flag on the efivarfs, which need to be toggled before/after the manipulating of the security database. And the current script has been handling this flag - remove this immutable flag before any efivarfs update, then added it back after the operation, under the root permission. I think this is the mechanism part, and the policy part is left to the tools/application or even level 8.
BTW, the latest head has an issue on the r/w efivarfs: even declared as r/w in the /etc/fstab, the filesystem is still mounted as ro. A bisection told me it was due to the latest kernel update, however, hadn't got the enough time to dive deeper. Workaround is to remount the efivarfs.
There was a problem hiding this comment.
Thanks @BaochengSu and @jan-kiszka for you inputs,
Yes, In the older kernel version (6.1.54-cip6), remounting efivarfs as read-write was working fine. However, in the newer kernel version (6.1.102-cip26), which we are currently using, efivarfs is not being mounted as read-write at any stage of the boot process.
We have attempted to mount efivarfs as read-write both in the initramfs and using a systemd service running at the multi-user.target phase, but in all cases, the system does not allow it.
However, once the system has fully booted, we are able to successfully remount efivarfs as read-write using the following command:
mount -o remount,rw /sys/firmware/efi/efivars
There was a problem hiding this comment.
@rakeshk7097 , I think the real issue here is that the efivarfs is mounted as read-only. (Maybe our backporting of the efi_stmm has some flow?) The current postinit of adding the r/w into fstab is already a workaround...
There was a problem hiding this comment.
I think eventually we will fix the readonly issue, before then, I think downstream can hold their own whatever workaround, just make it easier to be 'uninstalled'.
There was a problem hiding this comment.
Sure @BaochengSu , thanks for your input on this.
Instead of enforcing a persistent read-write (rw) mount via /etc/fstab, this change ensures efivarfs is mounted and remounted dynamically during command execution. This approach improves flexibility, avoids potential conflicts, and ensures efivarfs is available with the correct permissions only when needed.
Key improvements:
This update enhances robustness and ensures a controlled, on-demand handling of efivarfs.