Project

General

Profile

Issue #1659

The website and device pages don't warn about proprietary (and likely signed) TrustZone TEE

Added by Paul Kocialkowski almost 3 years ago. Updated over 1 year ago.

Status:
New
Priority:
High
Category:
Website and wiki content
Target version:
-
Start date:
03/06/2016
Due date:
% Done:

0%

Resolution:
Device:

Description

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 user

However, 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).

History

#1 Updated by Paul Kocialkowski almost 3 years ago

  • Tracker changed from Feature to Issue

#2 Updated by Paul Kocialkowski almost 3 years ago

  • Category changed from Infrastructure (web, git) to Website and wiki content

#3 Updated by Paul Kocialkowski almost 3 years ago

There is some generic documentation about TrustZone available.

From ARM: From various research and articles: From TEE implementations:

There are also more specific details about how it's used available.

From source code regarding some devices/platforms: From documentation regarding some devices/platforms: From analysis: From forums:

#4 Updated by Denis 'GNUtoo' Carikli almost 3 years ago

Open questions:
  • 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.
Variations:
  • 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).
We could also add a wiki page with research done on it:
  • 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 almost 3 years ago

Some initial information about Trustzone on smdk4412 devices

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.

Kernel side

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.

What could be done to improve the situation:

Partitions

The EFS partition contains some files related the PlayReady truslet in drm/playready.
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 over 1 year 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.

#7 Updated by Wolfgang Wiedmeyer over 1 year ago

For sake of completeness, the Galaxy Tab 2 devices seem to have a similar TEE as the Galaxy Nexus with the difference, that I didn't see it used anywhere in user space. I disabled related code in the kernel in the same way as for the Galaxy Nexus.

Also available in: Atom PDF