好了，到现在我们已经写完了整本关于TPM的书，并且你也阅读的了所有内容。或许我们试图让这本书有趣的努力成功了；又或者你超乎寻常地坚持了下来；又或者你仅仅是忽略了大部分内容直接跳到每章的总结部分。
不管是哪一种情况，我们已经到最后一哆嗦了。TPM博大精深并且很酷，它的安全程度就跟切片面包一样（这又是什么梗？），不用怀疑。并且TPM本身会提供级别很高的安全性。比方说，像微软BitLocker这样的应用程序可以使用TPM来保存一个硬盘加密密钥以及访问控制。
不仅如此，还有很多平台级别的技术结合TPM以及其他的平台或者厂商相关的安全特性，来提供更强大的安全解决方案。本章的目的就是介绍其中的三个技术，并说明它们是怎样集成TPM的。
当前有三种主要的平台在使用TPM。这一章会概括性地介绍这些技术，以及它们是怎样使用TPM2.0设备的，还有它们怎样支持应用软件使用TPM。这章的描述试图尽量客观，不带任何偏见。因此，我们会避免对这三种技术作比较，并且避免市场相关的声明（但是，不得不说的是，这本书的出版得到了Intel的大力支持，包括出版费用。Intel致力于应用TPM2.0设备来构建更好的安全计算生态）这是一本TPM2.0的书，因此关注的重点是TPM怎样应用在这些环境中。为了维持中立性和准确性，以下关于这几种技术的章节均由相关公司的经验丰富的员工或者前员工完成。
在我们介绍后面的内容之前，先定义一些术语：
- 可信计算基（Trusted Computing Base）：用于构建一个计算机系统安全环境的所有事物。主要是指，一组必须相信的软件硬件用来为系统提供安全保证。
- 经过测量的启动：这是一种启动方法，在这种启动方式下，前一个组件要测量下一个将要运行的组件。通常情况下，这些测量值会通过扩展操作被累计到PCR中。
- 信任链：组成“经过测量的启动”的一组操作构成的链。
- 用于测量的信任根（Root of Trust for Measurement）：一个信任链中被认为默认可信的基础组件。因此，它必须很小并且不可改变（在ROM中，或者受硬件保护）
- 静态信任根（Static Root of Trust for Measurement）：由上电到OS启动之前这个信任链中的最基本的组件。在服务器版本的Intel IXT技术中，SRTM就是CPU的微码。在其他的架构中，SRTM是一个ROM镜像。
- 动态信任根（Dynamic Root of Trust for Measurement）：由OS启动以后构建的信任链的基础组件。这允许系统构建一个动态的受测启动环境。在IntelTXT中，CPU的微码也是DRTM。DRTM有时候也叫做延迟启动。
- 可信代码模块（ACM）：ACM是经过IntelTXT数字签名的代码模块，这些代码模块由特殊的Intel TXT指令GETSEC启动。ACM是SRTM和DRTM执行之后紧接着要执行的模块。具体需要执行哪一个ACM模块以及需要执行GETSEC哪一个子功能，这都由执行GETSEC指令时的一个寄存器的值决定（Intel 有相关的SPec）。
- UEFI：现代BIOS。
- SEC 阶段：UEFI的安全阶段，复位后的第一段代码。
- PEI 阶段：UEFI的pre-EFI阶段。SEC之后要执行的diamagnetic。SEC和PEI共同构成BIOS启动块。
Intel TXT技术在2002年就开始在客户端机器上交付，并且在2010年开始在服务器上交付。Intel TXT提供了提供了一个根植于微处理器的硬件的可信链，并将可信链扩展到了OS甚至到应用软件，当然相应的软件要实际应用这个技术才可以。
这一节首先从高层次描述Intel TXT，主要包括这个技术特性，它比仅仅使用TPM的方案更有优势。然后详细介绍这个技术是怎样使用TPM功能的。概括来说，Intel TXT技术相对于仅有TPM的解决方案的优势是，基于硬件的信任根，更小的TCB，以及ACM所做的软硬件配置检查。这一节会重点介绍这些技术优势是怎样实现的。
还有其他的Intel技术也会使用TPM，包括Intel Boot Guard。这一章并不会介绍这些技术，或者这些技术怎样使用TPM2.0设备的，因为Intel TXT是现在最流行最具代表性的TPM2.0设备应用技术。同时还要说明的是TXT有两类：一种用于客服端平台，另外一种用于服务器。许多操作的原理是共通的，但是我们将集中在服务器的版本，因为它使用了TPM功能的一个超集。
Intel TXT的服务器版本可以防御BIOS攻击，复位攻击，rootkit，以及软件攻击，并且允许系统集成商和用户对保护进行多级配置。尽管这个技术确实可以阻止或者减少一些攻击，但它的初衷是通知用户和系统软件存在可能的攻击，并且如果检测到攻击就阻止启动。Intel TXT软硬件和TPM紧密地集成在一起，这使得TPM和TXT相关的寄存器在未经授权的情况下不能被访问。重要的测量值会保存在TPM中从而保证不被篡改，并且TPM还能阻止OEM和用户的Policy被执行未授权的修改。
那TXT究竟是怎样做到上述的特性的呢？简要的概括来说就是一个可信链会由Intel处理器或者芯片组硬件扩展到BIOS。然后，当OS启动以后，如果用户希望在OS层面进入安全模式，那么OS或者运行在OS上的软件会启动一个测量过的启动序列（DRTM）。这个测量过的启动保证在系统启动OS并进入安全模式之前系统不存在安全漏洞。一个可信链可能会由硬件一路扩展到最高层软件，使得系统管理员护着用户可以创建和使用Policy。这个可信链在执行组件之前总是会先测量它们。
Intel TXT技术有很多平台组件：
- CPU和芯片组：芯片组中包含特殊的TXT寄存器，其中许多寄存器只能由ACM和CPU的微码来读写。
- CPU微码：这是固化在微处理器中的一组CPU微操作，其中包括一些CPU汇编指令和CPU内部操作。
- Intel ACM：这些ACM只能由Intel来构建，并且使用一个仅仅Intel知道的私钥来签名。公钥被固化到芯片组的寄存器中，因此只有使用正确私钥签名的ACM才可以被执行。ACM的启动是由Intel 的CPU微码来触发的，这作为微码的一个扩展来实现。对于服务器版本的额Intel TXT技术，有两类ACM，分别叫做BIOS ACM和SINIT ACM：
- BIOS ACM包含几个子过程调用，其中的两个如下：
- StartupACM调用是在系统上电启动SRTM时由CPU微码来实现的。它通常会测量BIOS的启动模块，或者说UEFI启动模块，以及BIOS的SEC和PEI模块。
- Lock Config调用则由BIOS在退出部分BIOS测量模块之前实现。这个调用会做一些记录并锁定一些寄存器，从而防止恶意软件或者固件修改重要的硬件配置。
- SINIT ACM仅仅包含一个调用，它是被OS或者OS之前的软件（tboot）调用的，用于创建一个测量过的启动（DRTM）。
- BIOS ACM包含几个子过程调用，其中的两个如下：
这些ACM总是在特殊的CPU内部存储空间中运行，这个空间可以阻止DMA访问，从而保证ACM的代码和数据不会被篡改。
-
GETSEC：这是TXT的一个特殊指令，它可以根据寄存器的配置启动特定的功能。这些功能能够启动特定的微码执行流来实现进入，启动，退出ACM以及退出测量过的启动环境（Measured Launch Environment）。GETSEC指令具体会执行哪一个子功能由一个寄存器的配置决定。BIOS ACM的Lock Config和SINIT ACM调用就是这样调用的。
-
使能Intel TXT的BIOS：BIOS中有一个表，叫作固件接口表（FIT），它会告诉微码和ACM 是否已经使能了TXT功能，BIOS ACM在什么位置，以及BIOS的那些部分需要被测量。
-
TPM:
- TPM的PCR用于存储启动过程涉及的组件测量值。其中的一些PCR只能由微码来执行扩展操作，有一些只能由ACM扩展。
- NV索引用于存储验证过的启动过程需要的状态信息。
TCG的PC客户端平台TPM规范（google TCG PC Client Platform TPM Profile Specification）描述了PC兼容的TPM的细节。这个规范描述了PCR的数量和访问特性，测量BIOS启动代码的特殊接口，以及其他用于支持PC平台的TPM特殊功能。
- OS/middleware enabling for Intel TXT：OS或者中间件软件负责启动测量的系统加载过程。在某些情况下，这可能是一个运行在OS之下的应用或者软件模块；在另外，它还可能是一个商业虚拟机管理软件（VMM）包。
- 使用Intel TXT来做安全相关决定的高层应用软件：Intel的Mount Wilson是其中一个例子。如果想了解更多例子及更详细的解释，请阅读《Building the Infrastructure for Clound Security：A Solutions View》。
所有以上的组件共同协作来实现Intel TXT技术。
现在我们进一步详细地介绍一种可能启动顺序。如果你想了解更多这方面的内容，请参考《Intel Trusted Execution Technology for Server Platforms》。
在进入正题之前我们先说明一下错误处理，这样一来我们就不用不断地重复下面的错误处理过程：如果在启动过程中的任何一个地方出现了错误，芯片组中的一个寄存器会会记录响应的错误信息。这个寄存器，TXT.ERRORCODE，只能由ACM和微码来写，这样就可以阻止权限低的或者恶意的代码将错误信息清除。这个寄存器中的错误信息能够在后续阻止测量的启动过程，稍后我们将介绍。
图22-1和图22-2描述 了Intel测量的启动过程以及其中各种各样的模块是怎样和TPM交互的。图22-1是一个由上电到启动一个可信OS的完整过程。这个过程包括OS启动之前的SRTM以及由OS启动的DRTM。图22-2提供了关于安全启动过程的更多信息，尤其是用来验证平台和系统软件是否可信的步骤。
图22-1描述的启动过程包含两个阶段：SRTM阶段和DRTM阶段。SRTM由CPU微码开始，直到OS开始启动。DRTM阶段由SINIT ACM开始知道OS完全启动。
第一部分由系统上电开始，它能够阻止BIOS和复位攻击：
-
微码：当复位信号被释放以后，微码会检查BIOS的FIT从而知道BIOS ACM在BIOS镜像文件的什么位置。微码会验证BIOS ACM的签名，并且对ACM做一些合规性检查。如果没有问题——也就是说ACM没有被破坏，并且是正确的ACM——微码就会在保护的CPU内部存储中启动ACM。
-
Startup ACM：这个BIOS ACM包含一些可以由微码或者BIOS触发的不同程序入口。Startup ACM调用由微码在平台上电或者复位时启动。这个调用的主要功能是测量BIOS特定的内容，这些内容必须保证可信，从而进一步保证系统的可信，同时这个调用还需要将测量值扩展到PCR0中。需要测量的BIOS区域在FIT中指定，这是由BIOS OEM来定的。FIT的一些重要的区域本身和复位向量，以及一些BIOS其他区域需要被测量，BIOS ACM会保证这一点。BIOS的其他区域可以选择性地测量，这需要BIOS开发者合理地配置FIT表来增加正确的对应区域。不需要测量整个BIOS镜像，并且在正常启动过程中可能会被修改的任何区域都不会被测量，因为一旦包含这些内容启动过程将会失败。最低的要求是，为了保证系统的完整性，一定要测量BIOS的启动模块——这个启动模块包括基本的系统和内存初始化代码。如果StartACM检测到一个错误（很可能意味着这是一些安全问题），它将会在TXT.ERRORCODE中设置一个错误代码然后复位CPU，然后微码会让CPU重新执行复位向量。在这种情况下，仅仅可能启动一个未经验证的环境。如果StartupACM成功执行，接下则会执行BIOS代码。
-
BIOS继续扩展静态信任链：BIOS将测量额外的BIOS代码并把测量值扩展到PCR0，以及测量其他的平台组件并扩展到其他的PCR中，BIOS通过这样的方式来继续延伸信任链。BIOS还会将自己所测量内容的记录扩展到一个PCR中。所有BIOS信任边界上的代码都必须在执行之前被测量。在BIOS执行任何未经测量的代码之前（BIOS可信边界之外的代码），它都会调用BIOS ACM来锁定平台配置从而阻止不可信的代码修改平台的配置。这些BIOS ACM的调用同样也会做测试和安全检查，从而保证系统的完整性。
-
Option ROMs：除非这些ROM由OEM来提供，否则option ROMs就在可信边界之外。ROM的代码将会被测量并扩展到PCR2中，而ROM的配置信息会被测量并扩展到PCR3中。
-
OS启动：当BIOS执行完成以后，它会启动到OS。OS运行在正常的没有被验证的模式下，但是它会被锁定并加载，然后来执行系统启动的DRTM阶段。
启动过程的第二部分由GETSEC（SENTER）指令开始，这个指令是由OS或者运行在OS中的软件触发的。这部分可以提供动态信任根测量，比如SINIT ACM和MLE（有时候也是VMM）
- 测量启动：当OS想要启动到可信模式时，它会执行GETSEC（SENTER）指令。这会触发一个验证SINIT ACM的微码流，验证过程与BIOS ACM类似，然后SINIT ACM被加载，然后开始执行。
- SINIT ACM：SINIT ACM会通过检查TXT.ERRORCODE寄存器来验证系统是否存在安全问题。它还会针对特定的安全问题做硬件配置检查。然后测量可信OS代码。ACM还包含LCP（Launch Control Policy）引擎，这个引擎用于Policy检查，检查又包括将测量过的OS代码和PCR与已知的正确值比较。如果SINIT ACM的执行出现错误，将会产生一个复位信号。如果一切正常，ACM将会执行测量启动，并且OS就会进入安全模式。这个就称作MLE（Measured Launch Environment）。SINIT ACM，policy，OS代码的测量值会被扩展到PCR17和PCR18中。
- 可信模式：此时，一个可信的环境已经被建立起来了，并且OS又权限访问TPM的Locality2以及动态PCR（什么叫dynamic PCRs？）。可信OS通过测量其他的OS组件和配置信息并扩展到PCR18-22中来延续动态可信链。
- 应用：本地应用可以使用PCR中的值来密存一些秘密信息，这个信息只能在平台处在相同的可信环境中时可能解封。举例来说，OS可以密封一个用于加密隐私和特权信息的密密钥。只有当平台成功执行测量启动后，OS才能恢复这个密钥并解密数据。这个过程有时候又叫做local attestation。Remote Attestation则是指外部机构使用PCR的值来做可信决策——可能是将生产环境网络连接到可信平台时隔离不可信的平台。
- 终止：最后一个阶段是OS终止可信执行环境。这个终止可以是平台关机或者仅仅是退出可信模式，在后者的情况下OS可以在不重启的情况下通过执行另外一次测量启动，从而重新进入可信模式。MLE关闭之后，OS就不能再访问TPM的Locality2了。
上述这些内容看起来有很多很多细节，但是我们已经略过了Intel TXT Policy的底层信息，ACM执行的安全检查细节，以及怎样使用TXT NV索引来交换TXT状态，同时还有TXT相关的BIOS使能和配置过程。
因此，TPM到底是怎样应用于这个技术中的呢？Intel TXT主要使用了TPM的PCR和NV索引。TPM2.0的一些其他特性可以帮助我们搞清楚PCR和NV索引是怎样被访问和使用的：特殊的由硬件触发的TPM命令，Policy命令，以及Loality。我们将在这里概括性地介绍它们。
NV索引在TXT中扮演了重要的角色。它们会用于以下操作：
- 在不同的ACM之间安全地传递信息和状态。
- 在平台多次复位或者上电之间安全地维持状态信息。
- 允许OEM和平台拥有者提供两个好的平台配置的Policy列表的哈希，分别对应平台提供者和平台所有者。
- 保护OEM和用户的Policy不被恶意修改。 这些索引的访问由索引的属性和第13，14章中描述的Policy授权和口令共同控制。ACM会在信任索引的值之前验证这些索引的属性是否正确。
前面介绍的两类ACM都会使用PCR。因为TPM2.0支持灵活的算法配置，Intel TXT也全面地支持这个算法灵活性，从ACM到Intel TXT测量启动的Policy和BIOS可信Policy。这个算法灵活性的细节在《Measured Launched Environment Devoloper's Guide》中有详细的描述，你可以在Intel官方网站上下载这个技术文档，同时还有对OEM厂商开放的《Intel TXT BIOS Writer's Guide》。
BIOS ACM会将BIOS的测量值以及其他早期的初始化测量值扩展到PCR0中。BIOS本身会将其他的平台配置组件测量值扩展到PCR0-7中。
当执行测量启动时，GETSEC(SENTER)指令的微码会触发_TPM_Hash_Start，_TPM_Hash_Data，以及_TPM_Hash_End命令。这些命令是通过对TPM的特殊接口寄存器的些操作来触发的，并且这些寄存器只能通过Locality4被访问。芯片组硬件会限制Locality4寄存器的访问，在这个例子中，只能由微码访问（注：TPM的通信结构通常是SPI，Locality的信息包含在SPI总线上的每一笔命令数据中，这又称为TPM SPI Bit Protocol，具体信息请参考之前提到的PTP Spec.。同时芯片组的SPI控制器会负责以硬件的方式将CPU（TSS）下发的命令数据打包成SPI Bit Protocol格式的数据，因此在芯片组中做Locality控制最合适不过了）。这个特殊的哈希命令会在GETSEC(SENTER)执行过程中把MLE的相关信息扩展到PCR17中。
当执行流进入SINIT ACM后，ACM会扩展其他的动态启动测量值到PCR17和PCR18中。如果Intel TXT的测量启动Policy能够被满足，那OS就是可信的并且OS也就可以访问PCR17-22；OS会使用这些PCR继续测量其他的OS代码和OS配置。之后，当更高层次的软件在做系统可信级别的决策时，会使用这些PCR中的测量值。
这一节概括地介绍了Intel TXT时怎样使用TPM2.0设备的。如果你感兴趣，可以深入学习我们之前提到的Intel相关技术文档。
ARM TrustZone自2002年起就称为ARM处理器架构的一个特性，在稍后的2003年第一次出现在真正的处理器中——1176JZF。自那时起，TrustZone本身没有多大的变化了，但是围绕这个技术增加了很多额外的特性，技术和应用场景。
TrustZone和Intel TXT经常被放在一起作为各自架构的安全扩展做比较，但是在一个很浅显得比较中，这两者其实并不相似，并且这样的比较并不会有助于帮助理解它们。这一节将会简单讨论一下TrustZone是什么，它怎样工作，以及它怎样会TPM技术联系起来。概括地说，TrustZone为实现一个软件TPM提供了安全的执行环境。
简单来说，TrustZone技术提供了一种在一个SOC上创建一个虚拟处理器的方法。通过实现一个特殊的操作模式，SOC能够创建两个隔离的并行的软件栈（或者“世界”）：Normal World（NWd），它运行主要的OS和用户接口，和Secure World（SWd），它运行实现了安全功能的可信软件栈。这两个世界被SoC硬件隔离开，这样就保证主OS不能干预安全世界中的程序和数据。这就使得用户即使不信任整个设备，也可以获得SWd数据的完整性和保密性。
通常来说，一个系统设计者不想影响设备的用户体验，因此会将SWd隐藏起来，通常来说是，当主OS需要的时候就使用这个技术创建一个虚拟的安全处理器。大多数情况下，虚拟安全处理器的想法是很有用的，但是必须澄清的一个重要细节是：当SWd被保护并阻止NWd访问时，反过来却不是这样。SWd代码原则上可以访问系统的任何内存和设备（注：最新的TrustZone貌似已经不是这样了，强调SWd也不能随便你访问NWd。再注：这里其实是想说，SCR_EL3.SIF，即安全模式下不能到标记为非安全的内存区域取指）。这种不对称的配置有很多正向的影响——高速数据交换以及能够对NWd的内存做完整性检查——但是这也让SWd能够控制整个设备，而不仅仅是相关的安全模块。
关于TrustZone，首先需要理解的是，它是ARM处理器的一个架构属性。并且为了理解这一点，你需要知道ARM生态是怎样工作的。
ARM公司自己不制作芯片：它设计处理器和子系统，并且控制一个架构级别的规范，其他公司讲这个规范作为自己芯片的设计蓝本。一个架构级别的特性是嵌入到架构规范中的内容，这些特性通过标准的机制，信号来实现，并且要保证与基于ARM的实现了不同特性的SOC保持兼容。基于ARM的SOC被要求遵守架构规范，因此通过架构的方式来指定这个技术，就能保证遵循这个架构规范的SOC（这里特指Cortex A系列，ARM的R和M系列并没有这样的技术（再注：现在已经出现M系列中包含TrustZone的情况了，M8系列（SC3xxx）））都包含TrustZone技术（仅仅实现是不够的，还需要足够的技巧和细心）。
另一个将TrustZone实现为架构级别特性的驱动力是，一旦这样做了，安全隔离技术就会强制由芯片硬件实现，从而不用依赖软件或者逻辑访问控制系统（这通常会产生很多bug）。尽管在这在实际应用中会有一定的限制，到底有多少设备商能够依赖这个技术不得而知，在理想情况下这个好处可以实现，并且这让TrustZone非常优雅而又兼具鲁棒性。
TrustZone设计的初衷是防御软件攻击，比如说来自流氓网站，错误下载，root包等相关软件的攻击。它不能保护事先协商好的，有针对性的硬件攻击或者实验室攻击。如果我们考虑近十年来计算机设备的进化，这其实是合理的：这些设备已经越来越网络化，更具连接性，以及更加动态。大量数据传输称为标准，应用和数据可以在有限的检查和平衡下无缝地从一个设备流到另外一个设备。在这样一个环境中，针对已经泛滥的可扩展软件的攻击的潜在增长远远超过物理攻击。
需要澄清的是，在TrustZone的威胁模型中，所有在NWd中的软件都被认为是潜在的威胁。因此当SWd和NWd内核协作来提供设备整体和应用安全是，SWd应该做到，在做安全相关的决策时从不依赖它从NWd获得的信息。这在考虑类似TPM的应用案例时很重要。
ARM经常将TrustZone描绘成系统级别的安全技术，但是这到底是什么意思呢？在这里，系统是指SOC中通过AMBA AXI总线连接到中央处理器的一切事物。所以除去为两个世界提供简单的内存和进程隔离外，它还需要将保护扩展到外设处理的数据和中断上。
master总线可以被标记为安全，这就意味着它们是由运行在SWd中的软件来控制的，或者非安全，这就意味着它们可以被两个世界访问。当一个安全设备与系统交互时，非安全世界时看不到的，或者不能直接干预它：即使是内核代码也不行。一个典型的应用案例是SE（Secure Element，一个用来存储密钥的设备，不能被非安全代码访问）芯片或者一个触控屏幕UI（Trusted User Interface）。
TrustZone在SOC和系统上的成功实现需要依赖很多方面的设计，但是其中有如下三个主要的考虑：NS位，监视器，安全中断处理。
NS（或者说是'Non-Secure'）位是TrustZone在ARM处理架构中的核心体现。它是伴随所有到系统总线master端读写传输事物的控制信号，包括内存设备。它的名字也体现出来，为了访问SWd的资源，NS位必须为低。
为了理解如此简单的信号是怎样可靠地实现两个世界的隔离的，有时候将NS位看作是一个额外的地址位更有用，这个地址位可以有效地将内存空间分割成两个平行的逻辑区域：32位空间加NS信号。这个类比可以让TrustZone的隔离和错误行为变得更加直观：试图从NWd访问SWd的内存将会失败，甚至是攻击者明确地知道它想要攻击的32位地址也不可以，因为第33位不同（NS的状态不同），因此就不能映射到它想要的内存区域中。
很明显，如果NWd代码可以在某种情况下以直接申请资源的方式设置NS位，系统安全将会遭到破坏。因此，NS位的设置，维护以及检查都是由处理器寄存器和总线组件比如内存控制器和地址空间控制器来控制的。返回到第33比特的类比，代码只能请求32比特的内存；处理器硬件，在知道代码是在非安全模式下执行时，会在传输中增加NS=1.
当然了，在架构中从来都不是像一个比特位这样简单。为协调两个世界，实现两个世界的切换等等功能，需要一个小的固件来完成。这个固件模块就叫做Monitor。
除了两个明显的操作模式外（安全和非安全），还有第三种处理器模式，叫做Monitor模式，它运行在第三种隔离的软件栈中。为了实现NWd到SWd的过渡（或者是相反的过程），这个请求必须首先通过Monitor模式，并且在Monitor固件确保这个转换是被允许的，转换有序并且安全地进行。
Monitor可以访问所有系统的关键安全数据，因此他的质量和完整性是最重要的。Monitor代码应该尽量小，并且经过标准的测试和审查从而保证没有BUG（如果有可能的话）。
当NWd软件希望联系SWd时，它必须执行SMC（Secure Monitor Call）指令。这个指令会启动Monitor代码，这个代码必须正确设置系统控制处理器的安全配置寄存器的NS位，以及其他两个世界相关的寄存器，从而保证系统安全和一致。
SMC调用非常简单：它仅仅将一个用于向SWd软件指示何种服务请求的4字节的立即数作为参数，系统设计者要负责协商这个值得使用惯例。
之前我们介绍过，安全设备的中断被直接路由到SWd，并且不用经过任何特权级别的不可信代码。此时，有必要介绍另外一种外设的配置：非安全，但是可以切换。一些外设（比如触摸屏）只需要在部分时间段内保持安全：当执行敏感传输事物时。其他时候，让NWd来控制它是可接受的，甚至是必需的。
为了管理这些事情并保证正确的软件在正确的时间能具备控制权，所有相关的中断实际上都由Monitor来捕获，Monitor根据配置列表决定哪个驱动（SWd或者NWd）来处理这个中断。当时一个安全传输事物时，SWd可以保留外设，这就意味着它会接收所有的中断。当它完成时，可以释放这些外设，通知Monitor应该将中断发送到NWd的驱动。
为了处理各种各样的实际问题，比如性能，潜在的冲突等等，一个典型的ARM系统会保留两个中断信号用于隔离：IRQ用作普通中断，FIQ用于安全中断。这就允许一些事件使用可以提高效率的静态路由表。
注：最新的中断处理细节请参考github上的ARM官方文档，以及ATF实际代码。
ARM SOC已经成为移动设备上最流行的架构：智能手机，平板电脑，以及其他类似产品。因此，TrustZone系统通常不会使用一个独立的硬件TPM，而是将TrustZone技术用作TPM。
在大概十年以前开始的移动端可信模块（Mobile Trusted Module Specification）规范，一直延续至今天的TPM2.0移动和PC客户端规范，可信计算社区发展了固件TPM的概念。使用fTPM，而不是依赖独立的硬件芯片，TPM的功能在一个受保护的附件执行空间中实现，比如TrustZone。然后通过NWd的OS调用来以通常的方式完成测量，密封，以及其他事情。
虽然并没有fTPM精确实现的要求或者规范，但是操作环境需要提供一些基本保护从而实现TPM的信任根和PCR。与TrustZone的保护目标一致，TPM实现之外的软件不能直接修改或者访问信任根，或者不能修改PCR，除非是通过授权后的接口。
一个实现良好的TrustZone系统能够提供上述的保证（实际上，一些商业实现已经可以达到这样的要求）。
AMD的安全处理器（之前称作平台安全处理器（PSP））是一个专用的安全子系统，它独立于平台的主处理器并被集成到SOC中。它提供一个隔离的环境，在这个环境中，安全敏感的组件可以在不受运行在主处理器上的软件影响下独立运行。PSP可以执行系统运算任务也可以执行可信第三方的运算任务。尽管系统的运算负载是预先安装好的，并且提供SOC特定的安全服务，系统管理员能够完全控制是否可以以及哪一个第三方运算负载可以被安装在PSP上。PSP由以下组件构成：
- 专用32位控制器（包含TrustZone的ARM架构）。
- 隔离的片上ROM和SRAM。
- 使用硬件屏障隔离并加密的DRAM。
- 可以访问系统内存和资源。
- 安全片外NV存储用于存储固件和数据。
- 平台独有的密钥材料。
- 用于安全控制CPU启动的硬件逻辑。
- 密码学协处理器（CCP）。
PSP使用ARM TrustZone架构，之前的章节已经介绍过TrustZone，但是有一些不同：PSP是一个物理上不同的集成到SOC的内核，而不是一个虚拟内核，这个内核由专用的SRAM和专用的CCP。PSP提供不可修改的硬件信任根，这个信任根可以作为可选的由硬件直到OS的信任链基础。
CCP由随机数生成器（RNG），处理标准密码学算法的的处理引擎（AES，RSA，以及处理器型号相关的其他引擎），以及一个密钥存储块组成。密钥存储块包含两个密钥存储区域：一个专门用于系统密钥，这些密钥可以被特权软件使用但是不用被读取；另外一个用于PSP或者主OS运行的软件在正常操作中加载，使用，以及擦除密钥。在启动期间，SOC独有的efuse密钥会被分发到CCP的系统密钥存储区域。
硬件验证启动（Hardware Validated Boot）是AMD形式的安全启动，这个启动过程由不可修改的PSP片上ROM开始，验证系统ROM固件（BIOS）的完整性。PSP的ROM包含初始的不可修改的PSP代码。PSP ROM之后会验证一个安全启动密钥，然后使用这个密钥来验证PSP固件，固件是PSP从系统Flash中读取的。PSP固件会加载系统应用并启动他们。系统厂商可以选择是否让PSP来验证BIOS的平台初始化代码。PSP之后会启动BIOS的执行。PSP完成自己的初始化后会进入一个确定的状态，在此期间BIOS和OS会完成在x86主处理器上的启动。平台生产商也可以自己决定给用户提供什么样的接口供用户选择是否开启UEFI安全启动功能。在这种情况下，平台厂商决定什么时候停止根植于不可修改的硬件的信任链构建（安全启动与否会影响到信任链延伸的长度）。
图22-3展示了HVB与UEFI安全启动的关系。
图22-3
作为可信计算组织的创建成员，AMD致力于为OEM和平台所有者提供多种多样的选项。目前为止，平台厂商在将TPM集成到基于AMD的平台上时有几种选项可供选择。平台厂商可以继续选择独立的广泛可用的TPM硬件；或者他们可以选择集成一个AMD提供的TPM应用作为运行在PSP SWd中的系统应用。这个固件TPM会使用CCP做密码学计算。
SKINIT用于在系统启动后期CPU重新初始化并启动DRTM。SKINIT有一个参数：安全加载器（Security Loader）代码的地址。SL必须存放在具有64KB大小的安全加载块中，这个区域会被保护以免恶意软件非法修改。CPU微码保证CPU会重新初始化到一个已知的状态，这样一来，开发者就可以启动任何他们需要在安全状态下执行的SL代码。SL代码会验证并初始化一个安全内核（Secure Kernel），然后将控制权交给SK。SKINIT指令会将SLB的内容写到一个地址，这个地址会被硬件使用_Hash_Init，_Hash_Start，_Hash_End信号重定向到TPM。这些信号会测量SLB的内容并扩展到PCR17。关于SKINIT指令怎样工作，CPU特性怎样被验证的细节可以在《AMD64 Architecture Programmer's Manual Volume2:System Programming》中找到。
这一节快速介绍了AMD安全技术，包括重点说明的AMDSOC片上硬件信任根。更多信息请参考AMD官方网站：www.amd.com/en-us/innovations/software-technologies/security。
这一章讨论了三种使用TPM2.0的平台级安全技术：Intel TXT，ARM TrustZone，以及AMD安全技术。还有其他的PC技术以及其他平台也使用TPM2.0设备，而且我们希望未来可以发展越来越多的技术。现在此地就是你，读者，进来的地方。走出这本书并使用TPM做精彩的事情吧！