I can envision a scenario where T2, when booted with Secure Boot disabled, tries to protect a Secure Boot OS and user data stored on the internal mass storage device in the event of the user subsequently re-enabling Secure Boot thus adding a layer of guarantee that everything is safe even during the time window when Secure Boot was disabled.
If intentional, this behaviour is nonetheless not documented in the whitepaper.
In such a scenario, a possible solution could be to offer an option to force an internal disk erasure upon toggling secure boot, in which case the internal device would be cleared for non-secure OS access.
Comments
I can envision a scenario where T2, when booted with Secure Boot disabled, tries to protect a Secure Boot OS and user data stored on the internal mass storage device in the event of the user subsequently re-enabling Secure Boot thus adding a layer of guarantee that everything is safe even during the time window when Secure Boot was disabled.
If intentional, this behaviour is nonetheless not documented in the whitepaper.
In such a scenario, a possible solution could be to offer an option to force an internal disk erasure upon toggling secure boot, in which case the internal device would be cleared for non-secure OS access.