[LA.UM.7.1.r1] ICE ext4 encryption about kernel HOT 3 CLOSED

After a year, I'm back on this.
I've noticed that on kernel 4.4, the derive_key_aes method is always called, while on 4.14 it's called only for directories:
4.4 (Sony, but it's the same also on OnePlus for example): https://github.com/sonyxperiadev/kernel/blob/aosp/LA.UM.6.4.r1/fs/ext4/crypto_key.c#L336
4.14: https://github.com/roberto-sartori-gl/4.14-kernel-oneplus-msm8998/blob/msm8998_op_new/fs/crypto/keyinfo.c#L120

This would explain why on 4.14 I can only read directories and files names, and in fact after applying the same change on 4.14, I can read directories and files name (as before the change) but I can also read some file contents. For example, I can read the content of /data/unencrypted/.

Reading '/data/unencrypted/mode', I verified that both 4.4 and 4.14 uses the "ice:aes-256-cts:v1" mode (ice for file contents, aes-256-cts for filenames).

I said that I can read some file contents because the device is still not booting: there are improvements, as the device does not go into bootloop, but after some seconds during boot I cannot read any file or any directory anymore (not even file names). All commands get stuck (e.g. 'ls /data' never returns, I have to close the adb process).

Analyzing the situation, I found out that a kworker is using 100% of the cpu (so 100% of a single core, actually). I'm now trying to debug this kworker, and:

cheeseburger:/proc/523 # cat stack                                                                                                                                                                        
[<0000000000000000>] __switch_to+0x11c/0x138
[<0000000000000000>] try_to_wake_up+0x264/0x45c
[<0000000000000000>] wake_up_process+0x18/0x20
[<0000000000000000>] __queue_work+0x3b0/0x534
[<0000000000000000>] queue_work_on+0x4c/0x6c
[<0000000000000000>] ufs_qcom_pm_qos_req_start+0xfc/0x128
[<0000000000000000>] ufshcd_queuecommand+0x2d8/0x94c
[<0000000000000000>] scsi_dispatch_cmd+0xd8/0x2a0
[<0000000000000000>] scsi_request_fn+0x430/0x67c
[<0000000000000000>] blk_run_queue+0x5c/0xa8
[<0000000000000000>] scsi_run_queue+0x228/0x2a4
[<0000000000000000>] scsi_requeue_run_queue+0x14/0x1c
[<0000000000000000>] process_one_work+0x144/0x438
[<0000000000000000>] worker_thread+0x244/0x450
[<0000000000000000>] kthread+0x118/0x130
[<0000000000000000>] 0xffffffffffffffff

Not sure where the issue may be at this point, but I'll continue looking at this.

from kernel.

Update 2:

So, the issue mentioned above - the kworker stuck after my change - is present even if I format data on 4.14. That means that it is not related to the 4.4 encryption method, my change simply break encryption on 4.14.
Looking into that, I verified that for some reason the kernel is not able to find the decryption key for the file contents anymore:
https://github.com/roberto-sartori-gl/4.14-kernel-oneplus-msm8998/blob/msm8998_op_new/security/pfe/pfk_kc.c#L283

Here, it just returns NULL after trying all the indexes up to PFK_KC_TABLE_SIZE.

Not sure what's happening at the moment.

from kernel.

I finally fixed this issue.
This is the commit: OnePlus-5-T@f9f700b

Basically, support for ICE calls for UFS > 2.0 is not correctly implemented on 4.14 from the Sony repo. Not sure if Yoshino is actually using UFS 2.x.
OP5/5T uses UFS 2.1, so the method ufs_qcom_ice_cfg_end (from ufs-qcom.c) was never called, causing ICE to be unable to overwrite keys - limiting the total number of keys to 32 (for encryption purposes).

With the patch above, when a key is not needed it can be overwritten by ICE with a new key succesfully.

from kernel.