config-gui.sh is growing in features.
Current board configs either comment board options when deactivated or set them to option=n
The later is better, concrete example:
- DEBUG is commented in board config, which is packed into CBFS through board.cpio. Since this is commented, the debug=x doesn't exist (not considered)
- User toggles debugging into config gui. This sets
debug=y into config.user overlay, which is applied on boot by cbfs-init.sh and considered when flashed to rom and rebooted.
- Heads picks the change as tampering. User can reseal or not secrets, produce debug.log and upload for bug report.
- User deactivated debug, expects logic to save as override which if the same as board config, produce no change and save, flash back to cbfs, reboot
- since board config never had debug=n, but now config.user has debug=n, Heads measures config.user and sees a change, reports it as tampering.
- User has to reseal secrets since debug=n was never set at the first place.
Tldr: if we want users to be able to test settings without resealing and rollback, options that are deactivated needs to be set to =n in board config so that when toggled back, Heads doesn't see a change because there are none.
config-gui.sh is growing in features.
Current board configs either comment board options when deactivated or set them to
option=nThe later is better, concrete example:
debug=yinto config.user overlay, which is applied on boot by cbfs-init.sh and considered when flashed to rom and rebooted.Tldr: if we want users to be able to test settings without resealing and rollback, options that are deactivated needs to be set to =n in board config so that when toggled back, Heads doesn't see a change because there are none.