安全之安全(security²)博客目录导读
目录
1 架构
1.1 问:支持哪些平台/架构?
1.2 问:是否支持32位和64位?
1.3 问:OP-TEE是否支持混合模式,在AArch64核心之上支持AArch32和AArch64可信应用程序?
1.4 问:堆和栈的最大大小是多少?可以改变吗?
1.5 问:OP-TEE本身的大小是多少?
1.6 问:NEON优化可以在OP-TEE中完成吗?
1.7 问:可以在OP-TEE中使用c++库吗?
1.8 问:在OP-TEE中使用malloc()会分配物理上连续的内存吗?
1.9 问:可以限制OP-TEE运行的cpu /core吗?
1.10 问:OP-TEE如何调度?
2 板级支持
2.1 问:如何将OP-TEE移植到另一个平台?
3 构建
3.1 问:得到了运行latest的构建错误,为什么?
3.2 问:运行stable标签x.y.z时出现了编译错误,为什么?
3.3 问:得到gcc XYZ或g++ XYZ编译器错误消息?
3.4 问:build.git是什么?
3.5 问:从build.git运行make时下载工具链失败?
3.6 问:如何构建启用了BTI的LLVM compiler-rt?
3.7 问:如何构建启用了BTI的GCC ?
3.8 问:尝试OP-TEE最快最简单的方法是什么?
4 认证和安全审查
4.1 问:TrustedFirmware.org会参与GlobalPlatform认证/资格认证吗?
4.2 问:有测试实验室在测试OP-TEE吗?
4.3 问:OP-TEE中列出的安全漏洞在哪里?
4.4 问:是否进行过代码审核/代码审查?
5 贡献
5.1 问:如何贡献?
5.2 问:可以从哪里得到帮助?
5.3 问:我是OP-TEE新手,但我想帮忙,能做些什么??
6 接口
6.1 问:在OP-TEE中实现了哪些API ?
6.2 问:在OP-TEE中实现了哪些API ?
7 硬件和外设
7.1 问:可以使用自己的硬件IP进行加密加速吗?
8 许可证
8.1 问:OP-TEE在什么许可下发布?
8.2 问:GlobalPlatform click-through许可证?
8.3 问:我用非BSD 2-Clause许可的代码修改了OP-TEE,能接受吗?
9 推广
9.1 问:想把我公司的标志放到op-tee.org上,怎么做?
10 安全漏洞
10.1 问:我在OP-TEE中发现了一个安全漏洞,我该如何披露呢?
11 源码
11.1 问:源代码在哪里?
11.2 问:在哪里下载名为xtest的测试套件?
11.3 问:Linux内核TEE驱动程序在哪里?
12 测试
12.1 问:如何测试OP-TEE?
13 可信应用
13.1 问:如何编写可信应用(TA)?
13.2 问:如何将库链接到可信应用?
13.3 问:应该把编译的可信应用程序放在设备的哪里?
13.4 问:什么是伪TA(Pseudo TA),怎么写一个?
13.5 问:是否支持伪用户空间TAs ?
13.6 问:静态TA可以打开/调用动态TA吗?
13.7 问:如何扩展GlobalPlatform Internal Core API?
13.8 问:如何验证可信应用程序?
13.9 问:TA 是否支持多核?
13.10 问:TA是否支持多线程?
13.11 问:如何从原生Android (apk)应用程序中使用或调用OP-TEE ?
13.12 问:听说有一个Widevine和PlayReady的TA,怎么才能获取呢?
缩略语
OP-TEE Open Portable TEE开源的可移植TEE
TA Trusted Application 可信应用
TEE Trusted Execution Environment 可信执行环境
TZASC TrustZone Address Space Controller TrustZone地址空间控制器
TZPC TrustZone Protection Controller TrustZone保护控制器
答:“Platforms supported”页列出了官方树中当前支持的所有平台和架构。
答:所有OP-TEE组件都完全支持32位和64位。
答:是的。
答:是的,可以更改。在当前的设置中(例如,对于vexpress),有32MB的DDR专用于OP-TEE。1MB用于TEE RAM, 1MB用于PUB RAM,剩下30MB用于可信应用程序。在可信应用程序中,可设置TA_STACK_SIZE和TA_DATA_SIZE。通常,我们将堆栈设置为2KB,将数据设置为32K。但是你可以根据可用的内存容量自由调整这些参数。如果你需要它们大于1MB,那么你还必须相应地调整TA的“MMU L1 table”,因为默认的映射是1MB。
答:截至2016.01,optee_os约为244KB(发布版本)。最好完全在SRAM中运行optee_os,但如果没有足够的空间,可以使用DRAM并使用TZASC进行保护。我们还在研究创建“最小”OP-TEE的可能性,通过消除尽可能多的内存消耗部件,即使在内存非常受限的环境中也可以使用有限的OP-TEE。然而,目前还没有这方面的预计时间。
可以通过optee_os中的make mem_usage命令查看内存使用情况,例如:
当然,根据运行make mem_usage时启用的编译标志,将获得不同的大小。
答:是的(更多信息,请参见Issue#953)。
答:目前不支持c++库。从技术上讲,这是可能的,但需要大量的工作来实现,特别是在需要异常的情况下。目前还没有这样做的计划。
相关信息,请参阅Issue#2628。
答:当前OP-TEE中的malloc()提供物理上连续的内存。这不能完全保证,因为文档中没有任何地方提到,但实际上堆在内存池中只有物理上连续的内存。OP-TEE中的堆通常非常小,约为24KiB(1KiB = 1024 Byte),并且可能有点碎片化。
答:目前是由kernel来决定在哪个core上运行,也就是说,它将与Linux中启动SMC的内核相同。请参见Issue#1194。
答:OP-TEE没有自己的调度程序,而是由Linux内核调度。有关更多信息,请参阅Issue#1036和Issue#1183。
答:1、首先阅读“Porting guidelines”。
2、参阅“Presentations”页面。在“LCU14-302如何将OPTEE移植到另一个平台”视频中可能会有一些有趣的信息。要注意,这份报告是五年前的,所以即使它是一个很好的来源,也可能有一些部分不再相关了。
3、以下作为一个很好的例子:
1)Armv8-A:在新设备上启用OP-TEE支持的补丁,请参阅在Xilinx UltraScale+ Zynq MPSoC上启用运行OP-TEE支持的ZynqMP。此外,Juno、Raspberry Pi3、HiKey也有类似的补丁。
2)Armv7-A:请查看飞思卡尔的ls1021a,另一个例子是TI的DRA7xx。
答:你想建造什么?只有optee_os ?一个完整的OP-TEE开发者设置使用QEMU, HiKey, RPi3, Juno?AOSP?OpenEmbedded?我们每天构建的是OP-TEE开发者设置(参见build.git支持的平台),但其他构建(如AOSP和OpenEmbedded)是我们不断尝试的构建,但我们没有为这些构建配置CI/回归测试。
运行最新版本而不是稳定版本也会带来由于版本相互依赖关系而导致构建错误的风险。现在,此类问题通常会影响xtest的运行,而不是构建。但是,如果您清理所有的git并执行repo sync -d。然后,我们几乎100%肯定您将再次回到工作状态,因为正如下一个项目所述,我们在发送到OP-TEE的所有补丁上构建(并运行xtest)所有QEMU。
OP-TEE中的每个pull request都在硬件上进行测试(参见Q:如何测试OP-TEE?)
答:在为所有支持的平台构建和在所有平台上运行xtest方面,稳定版本都经过了很好的测试,所以如果您无法构建和运行xtest,那么很有可能您这边出了问题。所有在稳定版本上测试过的平台都可以在CHANGELOG.md文件中找到。话虽如此,我们在稳定构建中也会时不时地犯错误。
答:最有可能的是,您正在尝试使用常规的x86编译器构建OP-TEE,而不是使用Arm工具链。请安装 Prerequisites,并确保您已经获得并安装了工具链页面中描述的Arm工具链。(有关更多信息,请参阅Issue#846)。
答:build是一个git,它与manifest一起用于创建完整的OP-TEE构建。它包含帮助程序生成文件,可以很容易地在使用repo的设置上启动和运行OP-TEE。
答:我们尝试在一定程度上跟上最新的GCC版本。但就像网络上的其他地方一样,事物也在变化。在某些情况下,如Issue#1195,URL在我们没有注意到的情况下被更改了。如果您发现并修复了此类问题,请将修复作为pull request发送,我们将很乐意合并它。
答:从发布页面下载llvm-12源代码,或者您可以从llvm的github checkout“release/12.x”(12以匹配您选择的clang版本)。
创建一个构建目录并cd其中。
运行cmake命令配置compiler-rt的独立构建。
将llvm-config的路径替换为您想要用来编译的clang安装的路径。这样做的目的是为c/cxx/assembly (compiler-rt中的所有类型)启用BTI保护,并禁用构建中不需要的某些部分。如果你需要更多的组件,你可以在compiler-rt/CMakeLists.txt中找到它们的cmake选项。
构建完成后,您将在
这应该为每个文件找到一个BTI行。
251 * 2 = 502,所以存档中的所有对象都是bti兼容的。
如何使用这组库并将其集成到整个构建系统中取决于您。需要注意的主要事情是,当启用BTI保护时,库的名称不会更改。
答:启用了BTI的GCC工具链可以使用crostool - ng轻松构建:
以上命令将在~/x-tools/aarch64-unknown-linux-gnu中安装新的工具链。然后你可以使用这个工具链来构建和运行完全支持BTI的QEMU v8的OP-TEE,方法是在make run命令中添加一些参数:
答:这将在本地PC上的QEMU上运行它。要做到这一点,你需要:
-安装OP-TEE Prerequisites。
-根据QEMU的说明构建QEMU。
-运行xtest。
综上所述,你需要:
答:不,目前还没有。大多数情况下,认证是在特定的软件版本和唯一的设备上执行的。也就是说,是软件+硬件的组合获得了认证。这通常是SoC或OEM需要自己做的。
但是值得一提的是,由于OP-TEE来自一个专有的TEE解决方案,该解决方案在过去的一些产品上获得了GlobalPlatform的认证,并且我们经常有来自一些成员公司的人员运行GlobalPlatform的扩展测试套件,我们知道获得GlobalPlatform认证/合格的差距并不是那么大。
答:Applus实验室在OP-TEE上使用HiKey 620设备进行了侧信道攻击测试和故障注入测试。他们的发现和修复可以在optee.org的“Security Advisories”页面上找到。
Riscure对OP-TEE进行了一次小型审计,生成了几个补丁(参见PR# 2745)。OP-TEE OS Github上的“Security Advisories”页面将在未来更新有关的更多信息。
答:请参阅OP-TEE操作系统“Security Advisories”页面。
答:完整的审计吗?没有!但在过去,Linaro一直在与Riscure合作,试图识别和解决潜在的安全问题。也有一些公司在内部进行了审计,然后在相关的地方他们与我们分享了结果,我们已经创建了patches报告给我们的问题的补丁(参见Q:是否有任何测试实验室在测试OP-TEE?)。
代码审查,是的!每个进入OP-TEE的补丁都在GitHub上的拉取请求中进行了审查。我们或多或少有一个要求,每个进入OP-TEE的补丁至少要有一个“review -by”标签。
第三方/测试实验室代码审查,没有!同样,一些公司已经在内部进行了审查,并与我们分享了结果,但除此之外没有(参见Q:是否有任何测试实验室正在测试OP-TEE?)
答:请参阅“Contribute”页面。
答:请参阅“Contact”页面。。
答:我们总是需要代码审查方面的帮助,请随时审查任何开放的OP-TEE OS Pull request。还请注意,其他OP-TEE gits中也可能有需要审查的公开拉取请求。
我们总是需要帮助回答OP-TEE OS Issues上提出的所有问题。
如果您想尝试解决错误,请查看OP-TEE OS Bugs或OP-TEE OS Enhancements。
如果不定期维护,文档往往会过时。我们尽力做到最好,但我们并不完美。请查看optee_docs并尝试更新您发现的差距。
为manifest和build(以及Platforms supported)中当前未使用repo的设备启用repo。
如果你想实现一个更大的功能,请联系我们(见Contact),我们可以讨论什么是最相关的。如果您已经有了一个想法,请随时将提案发送给我们。
答:
•GlobalPlatform(参见GlobalPlatform API了解更多细节)。
- GlobalPlatform的TEE Client API v1.1规范
- GlobalPlatform的TEE Internal Core API v1.1规范。
- GlobalPlatform的Secure Elements v1.0(现在已弃用,请参阅git log)。
- GlobalPlatform的Socket API v1.0 (TCP和UDP,但不支持TLS)。
•AOSP Keymaster (v3)和AOSP Gatekeeper(参见AOSP了解更多细节)。
•Android Verified Boot 2.0 (AVB 2.0)。
答:OP-TEE Linux驱动程序在kernel.org上的drivers/tee下的官方Linux树中维护。通常在这里可以找到最新的代码。话虽如此,为了在OP-TEE开发人员构建(manifest文件)中使用,一些平台需要少量的自定义,例如设备树更新。这就是在manifest文件中使用linaro-swg内核分支选项的原因。它基于上游定期更新。
旧的内核可能缺乏对新的OP-TEE特性的支持。为了评估在哪个内核版本中引入了一些提交,您可以使用以下shell命令:
输出结果如下:
答:是的,OP-TEE有一个加密抽象层(请参阅Cryptographic implementation),其设计主要是为了方便添加对硬件加解密加速的支持。在这里,您将找到有关抽象层本身的信息,以及您需要做些什么才能在OPTEE中支持新的软件/硬件“驱动程序”。
答:该软件主要在BSD 2-Clause许可下提供。
由于显而易见的原因,TEE内核驱动程序在GPLv2下发布。
xtest (optee_test)使用BSD 2-Clause用于运行在安全环境(可信应用程序等)的代码,使用GPLv2用于运行在正常环境(客户端代码)的代码。
答:由于OP-TEE是基于GlobalPlatform的TEE,它实现了GlobalPlatform指定的API,因此在开始使用OP-TEE之前,必须接受在尝试下载GlobalPlatform API规范时提供的click-through许可。
答:这是我们逐案处理的问题。但是作为一个一般的答案,如果它不污染BSD 2-Clause许可证,我们将接受它。联系我们(见Contact),我们将从那里着手。
答:如果您的公司对OP-TEE做出了重大贡献,请联系我们,我们将尽最大努力将您的公司包括在内。请注意,我们会定期进行审查,今后不活跃的支持公司可能会再次被删除。
答:请参阅“Contact”页面。
答:它位于GitHub上的OP-TEE和linaro-swg项目下。
答:所有的源代码都可以在名为optee_test的git中找到。
扩展测试(GlobalPlatform测试)可以单独购买。
答:从v4.12开始,您可以在正式的Linux内核项目中找到通用TEE框架和OP-TEE驱动程序。话虽如此,我们“缓冲”了Linux内核TEE框架分支上的未决补丁。也就是说,这就是我们为OP-TEE开发新功能的地方。从长远来看,我们的目标是完全停止使用我们自己的分支,直接将所有补丁发送到官方的Linux内核树。但目前我们还不能这么做。
答:有一个名为xtest的测试套件,用于测试完整的tee解决方案,以确保所有架构层之间的通信正常工作。测试套件还测试了大部分的GlobalPlatform TEE Internal Core API。它有近50,000个并且不断增加的测试用例,并且还可以扩展到包括官方的GlobalPlatform测试套件(参见扩展测试(GlobalPlatform测试))。
OP-TEE中的每个提交请求都是使用Azure DevOps管道和IBART自动为多种不同的平台构建的。在提交任何有关构建错误的问题之前,请查看那里,看看它是否在您正在使用的平台上构建失败。
有关更多信息,请参阅optee_test。
答:查看可信应用页面以及optee_examples页面。它们提供了关于如何实现基本可信应用程序的指导方针和示例。
如果您想了解更多可信应用程序的高级用例,那么我们建议您查看可信应用程序optee_test。
答:参见sub.mk目录中的示例。也可参考Issue#280,Issue#601,Issue#901,Issue#1003。
答:/lib/optee_armtz,这是tee-supplicant查找可信应用程序的默认位置。
答:伪TA是通过用于调用可信应用程序的通用API提供的OP-TEE固件服务。伪TA接口和服务都在TEE内核上下文中运行。也就是说,它可以访问与TEE核心本身相同的功能、内存和硬件等。如果我们说的是ARMv8-A,它是在S- EL1中运行的。
答:不支持。
答:是的,有关更详细的讨论,请参阅Issue#967,Issue#1085,Issue#1132。
答:可以开发自己的“Pseudo TA”,这是核心的一部分(参见Q:什么是Pseudo TA以及如何编写Pseudo TA)。获取更多关于伪TA的信息)。
答:请参阅移植指南中的“Trusted Application private/public keypair”一节。
另外,也可以构建可信应用程序并将其原始二进制内容嵌入到OP-TEE固件二进制文件中。在运行时,如果调用可信应用程序,将从OP-TEE固件映像加载,而不是从正常世界中获取并在安全世界中进行身份验证(有关更多信息,请参阅“Early TA”)。
答:是的,可以同时运行两个或更多的TAs。请参见Issue#1194。
答:不,没有pthread或类似的概念。也就是说,你不能从TA中生成线程。如果需要并行运行任务,那么可能应该考虑同时运行两个或更多个ta,然后让它们使用TA2TA接口相互通信。
答:1、使用Java本机接口(JNI:Java Native Interface)。
首先熟悉sample_hellojni.html,并确保可以运行该示例。之后,更换使用例如hello_world或optee_examples中的其他示例之一实现。
【注意】optee_examples中的hello_world和其他二进制文件是作为可执行文件构建的,必须修改构建为.so共享库,以便java端实现可以加载它。
请注意,*.apk应用程序默认情况下无法访问TEE驱动程序。有关详细信息,请参阅Issue#903。解决方法是在启动任何调用OP-TEE的*.apk应用程序之前禁用SELinux。解决方案是创建/写入SELinux域/规则允许任何所需的访问,但由于这不是与tee相关的问题,因此留给用户作为练习。
有关社区用户提供的参考实现,请参阅optee_android_hello_world_example。
答:TrustedFirmware没有这样的实现,但Linaro确实有参考实现,他们与谷歌和微软签署了WMLA和NDA/MLA的成员共享。所以建议是,如果你对此有疑问,可以去找Linaro。
参考文献
https://optee.readthedocs.io/en/latest.