Replicant

There is some generic documentation about TrustZone available.

• http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0210c/Cihhcjia.html
• http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.prd29-genc-009492c/ch04s02s02.html
• https://www.arm.com/products/processors/technologies/trustzone/tee-smc.php
• https://github.com/ARM-software/arm-trusted-firmware and https://github.com/ARM-software/arm-trusted-firmware/tree/master/docs

• https://en.wikipedia.org/wiki/ARM_architecture#TrustZone
• http://genode.org/documentation/articles/trustzone
• http://firmwaresecurity.com/2015/10/03/libsboot-secure-boot-for-u-boot/
• http://prosauce.org/blog/2013/2/11/embedded-trust-p2-u-boot-secured-boot.html
• https://www.blackhat.com/docs/us-14/materials/us-14-Rosenberg-Reflections-on-Trusting-TrustZone.pdf
• http://lwn.net/Articles/513756/

• https://www.trustonic.com/technology/trustzone and https://www.trustonic.com/technology/trusted-execution-environment
• https://en.wikipedia.org/wiki/Trusted_execution_environment#Implementations

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

• http://lists.denx.de/pipermail/u-boot/2013-June/155544.html
• https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/omap-secure.c
• https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/omap-smc.S

• http://lists.denx.de/pipermail/u-boot/2014-June/181446.html
• http://linux-sunxi.org/TrustZone_Protection_Controller_Register_Guide
• http://marc.info/?l=linux-arm-kernel&m=133941020000560&w=2
• http://lists.xen.org/archives/html/xen-devel/2014-02/msg01587.html

• http://www.fredericb.info/2014/12/analysis-of-nexus-5-monitor-mode.html
• http://bits-please.blogspot.fr/2015/08/full-trustzone-exploit-for-msm8974.html

• http://stackoverflow.com/questions/29533692/i-mx53-qsb-and-arm-trustzone

• 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.

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.

• Disable the Mobicore driver, so Replicant does not cooperate with Mobicore OS. I already did this some time ago:
  https://code.fossencdi.org/kernel_samsung_smdk4412.git/commit/?h=replicant-6.0&id=7fbe662a46f3bb994b6f7a9adea731f3d8a5620c
• 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.

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.

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.

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.