Fix some bugs in FRP hardening
ebiggers@ identified some problems:
1. The formatting of the persistent data block was incorrect, it
shortened the FRP challenge section by the size of the FRP
secret and magic, but then failed to advance the channel write
position past them, causing subsequent sections to be written
at the wrong locations. The data being written to incorrect
locations was all zeros and it seems unlikely that this could
have caused any problems, but this fixes it.
2. `writeFrpMagicAndDefaultSecret()` failed to recalculate and
write the digest, meaning that the PDB would subsequently be
viewed as corrupted and reformatted on the next boot in some
obscure cases.
3. `setFactoryResetProtectionSecret()` failed to check that the
caller has permission to configure FRP. This isn't strictly
necessary (nor is the similar check on
`deactivateFactoryResetProtection()`, but it's also not the
case that anyone without the permission needs to be calling
these methods.
4. There was a bug in the FRP secret file display in the status
command of the persistent_data_block shell command.
5. `deactivateFrpWithFileSecret()` logged a warning if the secret
file was not found, but this could happen in correct
operation, so it should be an informational log. (In general
FRP hardening makes PDBService too noisy, but this is good in
the short term; logging will be reduced in the future).
Test: atest PersistentDataBlockServiceTest
Bug: 290312729
Change-Id: Ief505a634d355a97bb6b99efc52cef68649a025f
2 files changed