The website and device pages don't warn about proprietary (and likely signed) TrustZone TEE
Most of the devices currently supported by Replicant (except the GTA04) support TrustZone, which is likely used on most devices. It is likely the reason why manufacturers enforce signed bootloaders while allowing unsigned kernels to run.
TrustZone TEE runs in parallel to and with greater privileges than the regular operating system (Replicant). Since it is proprietary and stored with/loaded by the (signed) bootloader, it is a great threat to both freedom and privacy/security. TrustZone is often used to allow decoding DRM contents without any possibility for the userHowever, since little is known about TrustZone TEE implementations (and exactly how it's loaded, how it's contacted), we should do some research about:
- Whether there are TrustZone bindings in the kernel (e.g. related to DRM decoding).
- How the (signed) bootloaders load the TrustZone TEE image and where it is stored. If not part of the bootloader image, knowing whether it is signed would be crucial.
Looking at some documentation and known free implementations for that could help (ARM's reference trusted firmware). Some platforms and devices come with more documentation about TrustZone (e.g. i.MX53 and USB armory, Tegra X1).
#3 Updated by Paul Kocialkowski about 3 years ago
There is some generic documentation about TrustZone available.From ARM:
- https://github.com/ARM-software/arm-trusted-firmware and https://github.com/ARM-software/arm-trusted-firmware/tree/master/docs
- https://www.trustonic.com/technology/trustzone and https://www.trustonic.com/technology/trusted-execution-environment
There are also more specific details about how it's used available.From source code regarding some devices/platforms:
#4 Updated by Denis 'GNUtoo' Carikli about 3 years ago
- How can we summarize the differences and similarities between trustzones implementations.
- How can we check if TrustZone is disabled? How can we check if it's RAM is accesible?
- What software, in practice sets up(or disable) TrustZone. Is it the Bootrom or the bootloader, and which part of the bootloader?
- How is TrustZone linked to other hardware blocks like (AES/SHA1/MD5 engine)? What is the relationship with the bootrom?
- How is it linked to hardware blocks hidden after early boot.
- What does the bootrom really do in practice (Analysis of its code).
- Is the bootrom always specific to a SOC? is it customized for high volume clients?
- Are there different revsions of the bootroms on the same SOC? Does it differ within the same SOC family.
- Can the hardware and TrustZone be customized for high volume clients? (Software like the bootloader is taken out of the equation here, but the bootrom isn't).
- Links that points to software capable of dumping it
- If we manage to dump it on some devices, we could add its checksum (sha)
We might also want to check our legal rights regarding the bootrom. Since it's the only way to initialize hardware, we may be able to redistribute its code, or a derivative of it in some ways.
#5 Updated by Wolfgang Wiedmeyer about 3 years ago
There are various news stories from some years back that the Galaxy S3 is the first Exynos device generation with a TEE implementation called Mobicore. My research so far confirms this claim but there is more that needs to be checked.
Mobicore has some user space parts (not included in Replicant), a dedicated kernel driver and the TEE implementation seems to be called Mobicore OS.
some information: https://www.sensepost.com/blog/2013/a-software-level-analysis-of-trustzone-os-and-trustlets-in-samsung-galaxy-phone/
It's main and probably sole purpose on factory images is DRM related and linked to the PlayReady trustlet that is used by the Samsung VideoHub app.
The kernel has the config
CONFIG_ARM_TRUSTZONE. It is enabled for i9300 and n7100, but not for i9100 and n7000. The i9300 does not boot with a kernel that has this config disabled.
There is also the config
CONFIG_EXYNOS_CONTENT_PATH_PROTECTION that is probably needed for the video DRM.
The Mobicore driver resides in
drivers/gud and is in charge of talking to the TEE. I only skimmed over the code so far, but it seems to contain some useful information about the interface.
- Disable the Mobicore driver, so Replicant does not cooperate with Mobicore OS. I already did this some time ago:
- Write a driver that checks if Mobicore is running. This is hopefully possible in a reliable way.
- In the case that we can't get rid of Mobicore OS, try to suspend of even shut down the TEE with the driver at boot.
The EFS partition contains some files related the PlayReady truslet in
Mobicore OS seems to have its own partition which is called TZSW. If this partition is not present on i9100 and n7000, then this may be another hint that there is no TEE implementation running on these devices.
PIT print from heimdall:
--- Entry #1 --- Binary Type: 0 (AP) Device Type: 2 (MMC) Identifier: 81 Attributes: 5 (Read/Write) Update Attributes: 1 (FOTA) Partition Block Size/Offset: 1734 Partition Block Count: 312 File Offset (Obsolete): 0 File Size (Obsolete): 0 Partition Name: TZSW Flash Filename: tz.img FOTA Filename:
Running strings against tz.img from a factory image reveals some strings that confirm that it contains at least parts of Mobicore OS:
MobiCore/MTK: ### SYSTEM HALT, code=%x *** <t MTK, Build: Oct 3 2013, 15:42:44 *** *** jenkins-Samsung-Pegasus-Release-Rebuild-27 ### RTM Exception: ### MOBICORE HALT ### CR Exception: ### MOBICORE HALT ### SIGABRT: Abnormal termination : Heap memory corrupted SIGRTMEM: Out of heap memory tbase-200_Exynos_4X12_V006_Patch1 N10__cxxabiv117__class_type_infoE N10__cxxabiv117__pbase_type_infoE N10__cxxabiv119__pointer_type_infoE N10__cxxabiv120__si_class_type_infoE N10__cxxabiv121__vmi_class_type_infoE N10__cxxabiv123__fundamental_type_infoE St10bad_typeid St13bad_exception St9exception St9type_info
The bootloader makes some checks on the TZSW partition. Strings from the bootloader:
s5p_check_tzsw %s: invalid tzsw type! dummy?
I was not able to access the TZSW partition from Replicant. It seems to be hidden. I also couldn't make heimdall accept a modified or empty tz.img. It would be interesting if the system boots with a non-functional TZSW image. Another option would be to patch Heimdall in order to make it possible to format the TZSW partition.
#6 Updated by Wolfgang Wiedmeyer almost 2 years ago
The Galaxy Nexus also has a TEE. I disabled the HAL and related services in this commit
Guessing from the log, it wouldn't have worked anyway, probably because proprietary code was missing.
It was not enabled in Replicant 4.2 (see here) because there was a power usage bug with the kernel driver.
On the kernel side, related code is now disabled with this commit.