33c42f533a
my (loooong) debugging sessions reg my decryption issues on FBEv2 revealed the following: the issue occurs in [fscrypt.cpp](https://cs.android.com/android/platform/superproject/+/android-12.1.0_r27:system/extras/libfscrypt/fscrypt.cpp;l=334-353) - actually by this condition: [here](https://cs.android.com/android/platform/superproject/+/android-12.1.0_r27:system/extras/libfscrypt/fscrypt.cpp;l=337) so what happens? 1. `ioctl(fd, FS_IOC_GET_ENCRYPTION_POLICY, &policy);` actually gives: `-1` with `errno=17` (i.e. "Invalid argument")! 2. Due to that it will return `EINVAL` which is WRONG as this is the expected errno when a FBE v2 policy has been found! Which is **NOT** the case as the ioctl fails with "invalid argument" instead. This alone is (at least) a design bug as it should be catched and handled differently. 3. anyways due to 2. we now assume it is encrypted (with FBE v2) - see: [fscrypt.cpp](https://cs.android.com/android/platform/superproject/+/android-12.1.0_r27:system/extras/libfscrypt/fscrypt.cpp;l=130) 4. the next design (ihmo) bug is that **REGARDLESS** of the fact if the directory is encrypted (or not) it checks if it can set a policy on it. IMHO this should be done ONLY when an encryption has been found. 5. setting the (constructed) policy on a *non-empty* AND *encrypted directory* [will fail](https://cs.android.com/android/platform/superproject/+/android-12.1.0_r27:system/extras/libfscrypt/fscrypt.cpp;l=340) because the dir is non-empty AND encrypted AND the ioctl to **SET** the policy fails (likely due to the same issue as in 1.) 6. as a result TWRP decryption fails (due to the `break` [here](https://cs.android.com/android/platform/superproject/+/android-12.1.0_r27:system/extras/libfscrypt/fscrypt.cpp;l=340-342)) so what is the bug here actually? - Is it that the policy TWRP is trying to set (bc of maybe wrong options by me somewhere) is simply different then what Android is setting? I tested and tried a lot to compare the contents of `kern_policy` and `policy` without meaningful success (I am NOT a cpp pro!) - Is the code in fscrypt.cpp simply useless (for TWRP)? I mean from my point it makes zero sense to add a policy on a directory which is encrypted already (for TWRP). imho it should be even **avoided (!)** as if it would not abort there it means the policy might be changed(!) and that can break Android. imho TWRP should not even try to do that but instead skip the whole part - but that means forking the fscrypt code (dunno if that is smth the devs want to do) I mean even the comment in fscrypt.cpp states: > FS_IOC_SET_ENCRYPTION_POLICY will set the policy if the directory is > unencrypted; otherwise it will verify that the existing policy matches. which is NOT the (full) truth. it will NOT "otherwise" verify but fail instead - in that specific scenario I encounter here (failing ioctl with invalid argument). so [this condition](https://cs.android.com/android/platform/superproject/+/android-12.1.0_r27:system/extras/libfscrypt/fscrypt.cpp;l=355) now simply checks for the encryption state, too and all problems (I had) are solved. I had added debug outputs everywhere (including the kernel) and all leads to the prob "Invalid argument" when the kernel is doin the mentioned ioctl on `FS_IOC_GET_ENCRYPTION_POLICY`. The reason behind **why** that fails is still nothing I can tell. likely I miss smth in the kernel or kernel config. ofc the secondary issue with `FS_IOC_SET_ENCRYPTION_POLICY` still could happen due to misconfigured policy options - but that does not explain why the `FS_IOC_GET_ENCRYPTION_POLICY` fails as that one should at least give the current policy (bc it **IS** encrypted). IMHO both GET and SET are related and a general issue within (likely) the kernel. [FS_IOC_GET_ENCRYPTION_POLICY source/info](https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html#fs-ioc-get-encryption-policy). so as I do not have any further ideas I patch fscrypt.cpp with vendorsetup.sh on-the-fly (yea dirty as.. ) and get at least a working result. Change-Id: I59eca3413e75712af3e23b195cd32b96704c0a93 Signed-off-by: Mohd Faraz <androiabledroid@gmail.com>
13 KiB
13 KiB