Bootctrl is being unreliable during repacking. This overrides the slot
while repacking recovery in boot.
Change-Id: I0a04357af4e5f24591792bcfb27ccbd10b0a813b
- During OTA upgrades if security state or ROT changes then Keymaster
keys requires upgrade. So for such usescases, if the FBE ephemeral
key export fails, check whether KM key requires upgrade and try for
exporting ephemeral key again.
CRs-Fixed: 2632902
Change-Id: I3ee2fcd97a56b628dc4304867c8f2b8da875f883
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
- Commit 77df7f2 / http://aosp/1217657 ("Refactor to use
EncryptionPolicy everywhere we used to use raw_ref") unintentionally
made fscrypt_initialize_systemwide_keys() start specifying keepOld=true
(via default parameter value) when retrieving the system DE key, and
likewise for read_or_create_volkey() and volume keys.
As a result, if the associated Keymaster key needs to be upgraded, the
upgraded key blob gets written to "keymaster_key_blob_upgraded", but it
doesn't replace the original "keymaster_key_blob", nor is the original
key deleted from Keymaster. This happens at every boot, eventually
resulting in the RPMB partition in Keymaster becoming full.
Only the metadata encryption key ever needs keepOld=true, since it's the
only key that isn't stored in /data, and the purpose of keepOld=true is
to allow a key that isn't stored in /data to be committed or rolled back
when a userdata checkpoint is committed or rolled back.
So, fix this bug by removing the default value of keepOld, and
specifying false everywhere except the metadata encryption key.
Note that when an affected device gets this fix, it will finally upgrade
its system DE key correctly. However, this fix doesn't free up space in
Keymaster that was consumed by this bug.
Test: On bramble:
- Flashed rvc-d1-dev build, with wiping userdata
- Flashed a newer build, without wiping userdata
- Log expectedly shows key upgrades:
$ adb logcat | grep 'Upgrading key'
D vold : Upgrading key:
/metadata/vold/metadata_encryption/key
D vold : Upgrading key: /data/unencrypted/key
D vold : Upgrading key: /data/misc/vold/user_keys/de/0
D vold : Upgrading key:
/data/misc/vold/user_keys/ce/0/current
- Rebooted
- Log unexpectedly shows the system DE key being upgraded again:
$ adb logcat | grep 'Upgrading key'
D vold : Upgrading key: /data/unencrypted/key
- "keymaster_key_blob_upgraded" unexpectedly still exists:
$ adb shell find /data /metadata -name
keymaster_key_blob_upgraded
/data/unencrypted/key/keymaster_key_blob_upgraded
- Applied this fix and flashed, without wiping userdata
- Log shows system DE key being upgraded (expected because due to the
bug, the upgraded key didn't replace the original one before)
$ adb logcat | grep 'Upgrading key'
D vold : Upgrading key: /data/unencrypted/key
- "keymaster_key_blob_upgraded" expectedly no longer exists
$ adb shell find /data /metadata -name
keymaster_key_blob_upgraded
- Rebooted
- Log expectedly doesn't show any more key upgrades
$ adb logcat | grep 'Upgrading key'
Bug: 171944521
Bug: 172019387
(cherry picked from commit c493903732d0c17b33091cf722cbcc3262292801)
Merged-In: I42d3f5fbe32cb2ec229f4b614cfb271412a3ed29
Change-Id: I42d3f5fbe32cb2ec229f4b614cfb271412a3ed29
Change-Id: I0449b812e91c13020a8b653f2149c33e46027b97
Since recent kernels seem to limit the number of loopback
devices to 7, we now just mount the required apex files in TWRP.
To mount additional apex files specify TW_ADDITIONAL_APEX_FILES
in your BoardConfig, for example:
TW_ADDITIONAL_APEX_FILES := "apex1 apex2"
To disable Apex in your builds use:
TW_EXLUCDE_APEX := true
Change-Id: Ib55529a4dc17ce2b737b01b86100dca3dc75e6c9
Change-Id: I3b4dfbb164838ffb126016b0d862f67d3f170bf3
This patchset introduces support decryption for Android 11.
In this update we deprecate ext4crypt. To specify the
policy version to use, use TW_USE_FSCRYPT_POLICY := 1 or
TW_USE_FSCRYPT_POLICY := 2. By default policy version will
be set to 2 if this variable is omitted.
Change-Id: I62a29c1bef36c259ec4b11259f71be613d20a112
Simplifies code for retrieving this list rather than using
every possible specified super partition group
Change-Id: I1a3bd8e4b73ce18a176c74a52eb91d25709080f4
* Fixes Boot caused because graphics nodes were not creating
* Fixes the following error:
cannot find/open a drm device: No such file or directory
...
cannot open fb0 (retrying): No such file or directory
cannot open fb0 (retrying): No such file or directory
cannot open fb0 (retrying): No such file or directory
cannot open fb0 (retrying): No such file or directory
cannot open fb0 (retrying): No such file or directory
cannot open fb0 (retrying): No such file or directory
cannot open fb0 (giving up): No such file or directory
...
Change-Id: I78b7e0f649800eebea4e816a166e77db94c9d929
Signed-off-by: Mohd Faraz <androiabledroid@gmail.com>
* After bad merge c387622389
libguitwrp module get reloaded into the makefile, to fix this merge this patch added and TW_SCREEN_BLANK_ON_BOOT is
set in golang module
Change-Id: I68d2b9b93959a9b7a35251ed2118b8d5d2b84c90
Signed-off-by: Mohd Faraz <androiabledroid@gmail.com>
Between Android versions, there may be different partitions
that make up super. Just because a partition that in fstab
is not in super doesn't necessarily mean there's a problem.
Change this message to information only so the end user
doesn't think there's a problem when there isn't one
Change-Id: I9cb99aabe20e20059e66cf0cf13cff5ed056f529
(cherry picked from commit e432fb0214b49549e99396db512be98d53e1ed8b)
This is required on some devices where previous to 8.1/8.0 the blank
screen flag worked but don't now.
Test: Tested on begonia, screen is now no longer black
Change-Id: Ib4ff607d220bcb1aa5166fea23cc7ecb0e012fdd
(cherry picked from commit 28d8dec40d60a31309fcf6259dad38cd328f0717)
