TWRP for Fairphone 5

[oli.sax]

I asked AI for help to fix the decryption.
After provinding several logs here is an analysis of the problem:

Based on your latest findings, we’ve identified the core issues preventing FBE decryption. Here’s the complete solution:
Critical Problems Found

1. Library Loading Failure
   qseecomd can’t find libQSEEComAPI.so because it’s looking in /system/lib64/ instead of /vendor/lib64/
   Error: CANNOT LINK EXECUTABLE: library "libQSEEComAPI.so" not found

2. Keymaster Version Mismatch
   TWRP requests v4.0 but device provides v4.1
   SELinux denials for hal_keymaster_hwservice

3. SELinux Context Issues
   qseecomd has wrong context (rootfs:s0 instead of qseecomd_exec:s0)

It suggested me some changes to the config files ( BoardConfig.mk,vendor.prop, etc.) to address those issues. I’ll compile it and update you if it solves the encryption issue

[rokejulianlockhart]

@oli.sax, did it work?

[oli.sax]

@rokejulianlockhart

did it work?

Right now … no!

As you know, AI provides a probable answer, not the right answer

I made all the changes suggested by the AI and the build process is failing.
Providing logs, AI suggests new modifications and so on, but up to now never succeeded to build.

The task it tries to accomplish is to force the build in setenforce 0 to have SELinux to Permissive (instead of Enforcing) to solve the SELinux denials, but this is not allowed by the system: build fail with this message ERROR: permissive domains not allowed in user builds.

Even if this trial-and-error process is currently unsuccessful, I learn a lot in the process so I’m really happy to play with it. When last year I was building TWRP I had no clue where to start to solve the FBE issue; now I have several things to investigate…

The mistake I made was to ask AI how to solve all 3 critical problems mentioned earlier; it asked me to modify 5 files and to create 2 new files and now it’s a mess . I reverted to the original sync and I’ll try to solve those problems one by one, this should be easier also to check if a modification was helpful or not.

So today objective is to solve issue #1 : the library issue

adb shell LD_DEBUG=libs /system/bin/qseecomd
CANNOT LINK EXECUTABLE "/system/bin/qseecomd": library "libQSEEComAPI.so" not found: needed by main executable

adb shell ls -l /system/lib64/libQSEEComAPI.so
ls: /system/lib64/libQSEEComAPI.so: No such file or directory

adb shell ls -l /vendor/lib64/libQSEEComAPI.so
-rw-r--r-- 1 root root 45408 1969-12-31 19:00 /vendor/lib64/libQSEEComAPI.so

[rokejulianlockhart]

@oli.sax

The task it tries to accomplish is to force the build in setenforce 0 to have SELinux to Permissive (instead of Enforcing) to solve the SELinux denials, but this is not allowed by the system: build fail with this message ERROR: permissive domains not allowed in user builds.

@oli.sax, I was under the impression that setenforce applies to the OS, rather than CI. However, it might be that during the compilation process, it’s expected that SELinux at least be available to assist in compilation. However, I’ve solely utilised the command on Fedora.

Although I’m also not familiar with AOSP package creation, if you’ve the option to choose between user ^[1] and userdebug (or eng), maybe try a different release target, so that SELinux isn’t enforced?

---

1. gaozhipeng.me/posts/permissive-domain-in-userbuild ↩︎

[oli.sax]

Library issue solved with 3 symlink added in init.recovery.qcom.rc

BoardConfig.mk is primarily used for configuring the build environment, but it doesn’t automatically export the variable for your runtime environment. For the dynamic linker to use it when executables run, you’d typically need to set the variable in an initialization script or in a script that’s executed early in the boot process (e.g., an init.rc file or a similar startup script).

Next time (perhaps on Monday) I’ll go for the permission issues, or changing release target or fixing it file by file.

This came out of the logcat analysis.

The SELinux denials (AVC errors) in your log indicate that TWRP (recovery context) is being blocked from accessing various resources needed for FBE (File-Based Encryption) decryption. Here’s how to analyze and fix them:

---

Key Issues Identified

1. Service Manager Access

• Denied { add } for service_manager (needed for keystore, gatekeeper, hwservicemanager, etc.)
• • avc: denied { add } for pid=389 uid=0 name=android.system.keystore2.IKeystoreService/default

2. Keymaster/Gatekeeper HAL Access

• Denied { find } for hal_keymaster_hwservice and hal_gatekeeper_hwservice.
• • avc: denied { find } for interface=android.hardware.keymaster::IKeymasterDevice

3. Vold Metadata Access

• Denied read/write to /metadata/vold/metadata_encryption/key/version.
• • avc: denied { read } for path=“/metadata/vold/metadata_encryption/key/version”

4. QSEECOM/ION Device Access

• Denied ioctl on /dev/ion (needed for qseecomd).
• • avc: denied { ioctl } for path=“/dev/ion” ioctlcmd=0x4901

5. Property Service Writes

• Denied { set } for properties like ro.crypto.state, vold_config_prop, etc.
• • avc: denied { set } for property=ro.crypto.state

6. Block Device/DM-Crypt Access

• Denied ioctl on /dev/block/dm-* (critical for decryption).
• • avc: denied { ioctl } for path=“/dev/block/dm-2” ioctlcmd=0x5331

[oli.sax]

Key finding of today : even if there are lots of AVC errors like this one
avc: denied { set } for property=ro.crypto.state pid=400 uid=0 gid=0 scontext=u:r:recovery:s0 tcontext=u:object_r:vold_status_prop:s0 tclass=property_service permissive=1
that doesn’t mean there is a permission error, because of the permissive=1 at the end of the line

The key is that getenforce and the androidboot.veritymode=enforcing flag refer to global SELinux mode, but what you’re seeing in the AVC logs with permissive=1 refers specifically to the context of the domain involved in the denial, which is often locally permissive.

What’s going on:

• Your system is globally in Enforcing mode—confirmed by both getenforce and /proc/cmdline.
• However, TWRP (or more specifically, the recovery SELinux domain) may have been compiled or patched to run in domain-level permissive mode, even when the rest of SELinux is enforcing.

This is a common practice in custom recoveries like TWRP to avoid breaking functionality due to strict SELinux restrictions.

The Denials Are “Real” but Not Blocking

• The avc: denied lines show policy gaps that would break TWRP if the recovery domain were enforcing.
• Since the domain is permissive, operations succeed, but you’re seeing what would fail under full enforcement.

So for the moment no need to deal with the permissions (suggested tool audit2allow).

Tomorrow investigation : a possible version mismatch for Keymaster v4.0 vs. v4.1

[hermann-san]

Hi, am I right in assuming that TWRP is not (yet?) available for Fairphone 5? Also not for FP5 with a custom ROM (with or without root) and there is also no alternative, right?
Thanks

[yvmuell]

You did post in the TWRP for FP5 topic. So what are you looking for?

[hermann-san]

I had the impression that TWRP will not work properly with FP5 and a custom ROM and I wanted to check if that is correct.

[AnotherElk]

@hermann-san

I had the impression that TWRP will not work properly with FP5 and a custom ROM

Please define “work properly”.
What exactly do you want to do with it?

It’s available … https://twrp.me/fairphone/fairphone5.html … but not fully functional right now depending on the use case. And depending on what you plan to do with it, it might not be the first choice of tool anymore anyway.

[hermann-san]

I always used it for device imaging/backup and I thought that is the main use case.
From the link you’ve kindly send, I understand that this will work. Thanks for that!

[AnotherElk]

Hmmm … perhaps I misread something and it indeed works on the Fairphone 5 and only still fails on the Fairphone 4.

Good luck! And please report back whether it actually works.

[hermann-san]

I’ve just though about TWRP again and I’ve remembered that my phone’s /data partition is encrypted (default for /e/OS 3). As far as I know, TWRP for Fairphone 5 doesn’t support encryption yet. If so, there is no point for me installing TWRP, considering I use Neo Backup for /data anyways, correct?