基于RTOS实现微控制器系统的高安全性分析

　　现在，网络钓鱼、弱密码、不充分的身份验证和薄弱的权限执行等唾手可得的成果正在消失，黑客被迫寻找新的方法来渗透企业网络和设备。目前连接到企业网络的大量完全易受攻击的设备为此提供了大量机会。到目前为止，设备安全已经得到了很多讨论，但很少行动。这种情况即将改变。

　　在过去几年中，我们一直致力于为基于MCU的设备，尤其是Cortex-v7M和v8M开发安全RTOS。这种RTOS具有许多创新功能来遏制和限制安全漏洞。本文的目的是介绍这些特性，并说明利用这些特性可以实现高度安全的设备。

　　SecureSMX基于SMX实时多任务内核，在过去30年中，该内核为数百个嵌入式系统提供了可靠的操作。它提供灵活和广泛的解决方案，使原始设备制造商能够在合理的时间和成本限制内，将有效的安全保护纳入其嵌入式和物联网设备。这种安全性的基础是隔离分区这对于这样的系统是不容易实现的。分区有许多优点：

　　允许硬件强制分离特权和非特权代码，并控制对系统服务、数据、内存区域和I/O寄存器的访问。

　　使其他保护成为可能，如运行时限制和限制对对象的访问。如果没有硬件强制分区，这种限制很容易被绕过。

　　允许将稀缺的程序员人才集中在加强最关键的分区上。

　　防止零时差。这些通常可以卖到很高的价格，并且是国家安全机构的高度机密［参考文献1］。然而，黑客也可以使用未打补丁的已知漏洞，因为无论哪种方式，他都将在一个隔离的分区中结束，在不触动绊线的情况下，他可以做的事情受到很大的限制。如果一个非关键分区被穿透，系统将继续执行其基本功能。这给了安全团队时间来解决问题，而不是总是玩追赶游戏。

　　硬件实施模块化代码的良好编程实践，具有定义良好的接口。这不仅会产生更高质量的代码，还会缩短集成和调试时间。

　　仅分区恢复。当黑客触发了众多检查中的任何一项时，就会出现立即内存管理故障（MMF）异常。这可以用来关闭分区，然后重新初始化它。这比重启整个系统更可取，因为它不会停止正常操作。

　　仅分区更新。如果没有其他东西移动，分区可以单独更新。这消除了将关键任务代码暴露给内部攻击。更新仅限于易受攻击的分区。遗留和可信代码通常已经过全面测试，很少需要更新。内部攻击是一个比普遍认为的更大的问题［参考文献2］。

　　没有完美的安全措施。但是，增加系统的安全性可以减轻损害和潜在的责任。

　　目标

　　这个安全RTOS的目的是促进现有系统的安全改进，并作为新系统的安全基础。开发者可以根据需要使用或多或少的特性。易受攻击的代码，如开源［参考文献3］或网络堆栈和新开发的包，可以通过一系列明确定义的步骤与系统的其余部分隔离。隔离的强度可以根据需要而定，如果需要，可以施加限制。同时，系统的其余部分可以继续运行，基本不受影响。因此，对于开始被黑客攻击的现有系统，有一个解决方案。

　　操作

　　SecureSMX利用Cortex-v7M和v8M架构的所有硬件安全功能，但不需要TrustZone。重要的是将操作硬件分离成处理程序模式（hmode），特权任务模式（pmode），以及非特权任务模式（乌莫德）。内存保护单元（MPU）用于限制每个任务可以访问的内存。SVC指令用于允许umode任务访问系统服务。背景区域（BR）仅在hmode中使用。

　　当前典型的嵌入式系统完全运行在hmode中。第一步是将代码分成运行在pmode （ptasks）中的任务和运行在hmode中的系统服务（例如RTOS）、异常处理程序和ISR。ptasks在MPU使能、BR禁用的情况下运行。每个ptask可以有一个唯一的存储器保护阵列（MPA ），当ptask开始运行时，该阵列被载入MPU。或者，ptask可以使用默认MPA。在这一点上，根据每个任务拥有自己的MPA的程度以及MPA区域定义的紧密程度，任务获得了一定程度的相互隔离。为了实现更好的隔离，可以将任务转移到umode中。那么系统的所有其余部分都将受到硬件实施的保护pmode势垒。

　　

　　分区应用程序

　　什么是分区？

　　分区是由它们包含的一个或多个任务定义的。它们没有控制块。通常，一个分区对应于系统的一个逻辑部分，通常称为组件，如文件系统。像这样的分区通常有一个顶层任务和一两个子任务来帮助它。然而，为了适应特定的系统，一个分区可以由多个顶层任务组成，并且可以包括多个模块。例如，在一个给定的系统中，所有的中间件或所有的utasks可能被合并到一个单独的分区中。分区灵活性允许在投入的精力和实现的安全性之间达到最佳的平衡。

　　v7M分区

　　众所周知，Cortex-v7M MCU的分区很难实现，因为v7M MPU要求每个区域的大小是2的幂，并且大小一致。显然，这可能导致严重的内存浪费，并导致v7M MPU在很大程度上被嵌入式软件社区拒绝【参考文献4】。这对于安全MCU设计来说是一个不幸的挫折。然而，我们已经找到了许多方法来克服这个问题，这些都被纳入我们的新RTOS。以下段落详细描述了这些方法，以便提供一个令人信服的画面。

　　定义部分

　　系统中的每个任务都需要一个区域用于它所使用的每个活动MPU插槽。通常所有MPU插槽都是活动的，因此每个任务需要8个区域。尽管一些区域可以在任务之间共享，但是对于典型的系统，通常需要定义大量的区域。在代码中，区域的定义从使用pragmas［脚注i］开始，以定义部分（例如。.sys_bss和。 sys_data），它们包含在该区域中（例如sys_data）。一个区域的各个部分可能分布在几个模块中，但是链接器将一个区域的所有部分组合成一个模块区域块。

　　链接器命令文件

　　我们开发了一个简单的方法来创建v7M链接器命令文件。在其顶部，系统所有区域的大小都是以十六进制定义的。要成为2的幂，区域大小必须只有一个非零数字，并且该数字必须是1、2、4或8。因此很容易避免区域尺寸误差。在区域大小以下，每个区域块定义为其大小= region_size*5/8、6/8、7/8或8/8，其对齐方式= region_size，以及其包含的部分。这种方法的一个很好的特性是，在开发过程中，当链接器报告一个区域被超出时，很容易将其大小增加1/8，或者如果已经是8/8，则增加到2 * 5/8的下一次幂。

　　

　　模板、内存保护阵列和任务

　　MPA模板

　　每个任务都有一个内存保护数组，MPA，或者默认MPA，当任务被分派时，它被加载到MPU中。任务的MPA是从其MPA模板在任务创建之后。一个任务可能有自己的MPA模板，或者与其他任务共享一个模板。MPA模板是使用特殊的宏定义的，它允许每行定义一个区域，由RBAR、RASR和region_name组成。（region_name仅在调试期间使用。）子区域禁用are自动地从区域块大小生成（例如，如果区域块大小= region_size*5/8，则设置SRD 5、6和7）。这为用户避免了很多复杂性，同时最小化了区域大小。

　　缩小地区之间的差距

　　链接器按照指定的顺序将区域块分配给内存。这可能会导致块之间出现很大的间隙，从而浪费大量内存。为了解决这个问题，MPUPacker以找到区域块的最佳排序。然后，在链接器命令文件中更改顺序以匹配，链接器再次运行。为了帮助将代码和数据分配给区域，MPUMapper可以运行来修改地图文件，以显示每个符号所在的区域。这在开发过程中非常有助于修复MMFs并检查系统是否分区良好。

　　一般来说，我们发现内存浪费可以控制在20%以下，通常是10%。如果需要，还可以使用其他方法来减少内存浪费。但是，如果有足够的内存，将未使用的内存分布在分区中是有利的，因为这有助于仅分区更新。

　　v8M分区

　　Cortex-v8M解决了区域问题，只要求区域是32字节的倍数，并在32字节边界对齐。因此，尽管基本方法是相同的，但是上述许多措施对于v8M来说是不必要的。然而，v8M引入了一个新问题：如果分区重叠，就会出现MMF。这给任务堆栈、pmsgs和动态区域带来了致命的弱点。可以通过从不同于主堆的堆中分配它们来解决这个问题，但是需要注意避免被这个不必要的架构缺陷所困扰。

　　来自umode的系统服务

　　

　　来自umode的系统服务

　　ptasks可以直接进行系统调用，因为它们有系统代码和sys_data他们海洋保护区内的区域。这些区域被替换为ucom _代码和ucom_data对于utasks，它不能直接进行系统服务调用。相反，utasks必须使用SVC异常由触发SVC n指令，其中n表示256个服务调用中的一个。utask代码中包含一个特殊的头文件，用于将服务调用映射到具有相似名称的shell函数。一个枚举定义了n的值，一个跳转表，以同样的顺序，被SVC处理器SVCH（）用来跳转到所需的服务调用。在ucom_code中，每个系统服务都有一个shell函数，它使用enum定义的n值调用SVC n。该系统使添加或删除服务呼叫变得容易。

　　当SVC n执行时，它导致创建一个异常帧，切换到hmode，切换到主堆栈，并启动SVCH（）。SVCH（）从异常帧重新加载r0-r3，从任务栈复制参数5及以上到主栈，通过跳转表（在sys_code中）调用系统服务。当系统服务完成时，SVCH（）进行一些调整，然后异常返回到调用点。返回值（如果有）在r0中。除了生成错误异常，这是utask访问hmode中代码的唯一方式。

　　来自umode的系统调用开销相当小，并且不会显著影响系统性能，因为系统调用并不频繁。明显有害的系统调用无法通过SVC n获得。在某些情况下，当从umode调用时，系统调用的有害部分会被禁止。此外，一些服务（如中断启用和禁用）在umode中不起作用。中断禁用和启用必须替换为中断屏蔽和取消屏蔽，并提供一种方法来限制哪些IRQ可以从utask屏蔽或取消屏蔽。

　　一个umode分区通常只使用少量的系统服务调用。因此，提供了一种允许为分区定义自定义枚举、自定义跳转表和自定义外壳函数的方法。这通过最小化对ucom_code的访问来提高隔离。一般来说，标准的枚举、跳转表和shell函数应该减少到umode分区实际需要的程度，从而节省内存并提高安全性。

　　虽然没有必要，但是ptasks也可以访问SVCH（）来获得系统服务，而不是直接调用。这为pmode到umode的转换过程提供了一个步骤。

　　普塔斯克vs尤塔斯克

　　支持ptasks主要是为了方便将分区从pmode移动到umode。然而，在提高系统可靠性方面，它们和utasks一样有效。将任务转换为ptasks后，通过分配MPAs，潜在的bug如未初始化指针、堆栈溢出等。很可能会出现。

　　安全性方面，utasks比ptasks好。这是因为如果ptask被穿透，只需要一条指令就可以关闭MPU。这在umode中是不可能的，因此umode提供了更强的安全性。此外，pmode屏障使得从umode访问pmode和hmode几乎是不可能的。

　　门户网站

　　为了实现完全的分区隔离，有必要引入门户网站。这是因为函数API要求用户可以访问函数本身，这违反了隔离原则。

　　门户提供了一个间接的API来将一个分区中的服务与其在其他分区中的调用者隔离开来。呼叫照常进行，但是它们使用smx消息指导服务器任务执行服务并通过门户返回结果。

　　smx消息由链接到包含实际消息的数据块的消息控制块（MCB）组成。消息可以发送到消息交换任务可以等待的地方。它们可以从消息等待的消息交换中接收。消息可以有优先级，并且可以按优先级顺序在交换中排队。因此，较高优先级的消息可以绕过较低优先级的消息。交换中的消息队列可以作为服务器的工作队列。

　　受保护的消息（pmsg）

　　对于门户，区域信息被添加到消息中，创建所谓的受保护的邮件， 血清促性腺激素。当接收到一个pmsg时，它的区域被加载到MPU的一个空槽中，接收任务的MPA。这允许任务访问数据块，但不能访问sys_data中的MCB。对于门户，接收任务称为计算机网络服务器发送任务称为客户。通常，一台服务器可能有许多客户端。客户机可以给pmsg一个优先级，当它接受pmsg时，这个优先级将被传递给服务器。

　　创建门户时，会给出一个允许访问门户的客户端列表。创建过程初始化服务器控制结构，并将门户交换句柄和门户名称加载到每个客户机结构中。只有这些客户端可以访问门户，因为只有他们知道向哪里发送pmsgs。

　　提供了两种类型的门户：

　　免费信息门户

　

　　免费信息门户

　　对于这个门户，当消息被发送时，交换成为它的所有者，然后当消息被接收时，服务器成为它的所有者。发送后，MPU和客户端MPA中的pmsg区被清零。此后，客户端既不能访问也不能更改消息。当服务器完成时，它将pmsg发送到应答交换，客户端可以从应答交换中检索它。一旦发送，服务器就不能再访问pmsg。免费的消息门户旨在传输少量的数据和命令。

　　隧道洞口

　　

　　隧道洞口

　　隧道入口旨在快速发送大量多块数据。在这种情况下，客户端保留对pmsg区域的所有权和访问权。数据块变成了隧道在客户端和服务器分区之间，因此允许发送和接收多个数据块。信号量用于协调操作。传输完成后，入口关闭，pmsg释放。

　　操作

　　对于这两种类型的门户，头文件将服务器函数API映射到名称略有不同的shell函数。这个头文件包含在每个进行服务器函数调用的客户机文件中。每个shell函数创建一个带有函数ID、参数和数据的pmsg，并将pmsg发送到门户交换。服务器接收pmsg，并使用switch语句将ID转换为函数调用，进行调用，然后将函数返回发送给shell函数，后者将函数返回给应用程序。所有这些对应用程序来说都是透明的，只是运行速度较慢。

　　由于切换到服务器任务，门户操作可能与直接调用有很大不同。如果pmsg的优先级比客户机高，服务将抢占并立即运行。这最像是直接的服务呼叫。如果pmsg具有相同的优先级，服务将不会运行，直到客户端被挂起。如果pmsg具有较低的优先级，服务将在未来的某个时间运行。当服务是一些低优先级的功能时，例如事件日志记录，后者是有用的。

　　免费消息门户提供100%隔离；隧道入口只提供了一点点。

　　表演

　　性能良好，因为pmsg操作不需要拷贝pmsg数据块（与基于MMU的系统不同）。事实上，数据块可以用作客户端中的工作缓冲区，以便进一步减少数据复制。通过增加pmsg数据块的大小，性能得到了极大的提高。

　　以下是在相同的处理器（STM32F746，Cortex-M7）上，使用MPU和portalss与不使用MPU和portal的情况下，将我们的文件系统（FS）写入SD卡的性能测量值（KB/sec）。它还显示了非复制模式的轻微增益，在这种模式下，客户端使用门户缓冲区作为工作缓冲区。

　　FS+SD 7969 / 4855

　　FS+SD+portal no copy 6788 / 4544 85% / 94%

　　FS+SD+portal copy 6685 / 4419 84% / 91%

　　MPU和门户的使用使读取性能降低了16%，写入性能降低了9%，而在客户端直接使用门户缓冲区（无拷贝）时性能略有提高。

　　eheap

　　现代嵌入式系统比过去更频繁地使用堆。但是，如果分区共享一个堆，就无法实现隔离，因此需要多个堆。

　　eheap堆仓结构

　　eheap是我们包含在SecureSMX中的完善的堆管理器。它是专门为嵌入式系统设计的；它支持多个堆，并且使用垃圾箱，比如dlmalloc，来加速分配。与dlmalloc不同，每个堆的仓的数量和大小是可定制的，以满足应用程序的要求。例如，如果一个分区经常需要256的块大小，那么可以创建一个只包含这个大小的bin。此外，eheap可以分配2的幂的对齐块，并且可以分配v7M区域。这些对于动态区域特别有用，这是安全RTOS的一个特征。eheap的多任务版本为每个堆提供了一个互斥体，以避免该堆的访问冲突。

　　大多数任务堆栈、受保护的消息（pmsgs）、受保护的块（pblks）和许多系统结构都是从v7M系统的主堆中分配的。对于v8M系统，由于其非区域重叠要求，这些对象中的一些可能需要从另一个堆中分配。在需要的地方，可以为需要它们的分区创建自定义堆，比如用C++编写的那些。eheap可以为小型C++对象合并小型块池以加速操作。通常，分区堆比主堆简单得多，也小得多。此外，eheap支持自动扫描和修复每个堆及其箱中的断开链接。

　　调度程序回调

　　大多数RTOSs提供退出和进入回调。前者可用于在任务挂起时保存扩展状态，后者可用于在任务恢复时恢复扩展状态。smx还提供启动和删除回调。当一个任务第一次开始运行时，前者可以用来进行任务初始化和获取任务需要的资源。当任务被删除时，后者可以用来释放资源和进行任务清理。因为在switch语句中，DELETE通常是START case下面的一个case，所以很容易确保没有遗漏任何内容。因此，分区可以无泄漏地循环打开和关闭，以便支持仅分区恢复。

　　运行时间限制

　　不幸的是，即使完全分区隔离也不足以抵御黑客。即使黑客无法从分区中逃出来，他也可以从分区内部进行大量破坏。一种简单的攻击是将分区中的任务放入一个无限循环中。那么所有同等或更低优先级的任务都被阻止运行。最终，这可能会导致任何系统崩溃。为了防止这种情况，有必要使用任务运行时间限制。

　　不幸的是，在实时系统中，运行时限制可能是一种诅咒，也可能是一种祝福——例如，我们不希望关键任务在紧急情况下被束缚，比如当起重机即将倾覆时。但是开发人员很难估计需要多少运行时间来避免这样的灾难。所以重要的任务可以不受运行时间限制地运行。这一点，再加上他们的高优先级，确保他们可以运行所需的时间来完成工作，即使在极端的情况下。

　　不太可信的任务用计数器分配运行时限制。在一帧开始时，所有计数器都被清零。结果是节拍分辨率太粗糙了，所以改用CPU时钟。每次任务运行时，它使用的时钟数被确定并添加到它的计数器中。如果这超过了任务的运行时限制，任务将在门信号量再也跑不动了。在每一次滴答，当前任务的计数器被更新，如果它超过了它的运行时间限制，任务在门信号量上被挂起。

　　运行时间限制

　　很难在任务优先级之间取得良好的平衡，这使得任务能够在截止日期前完成。添加一个固定的运行时框架只会增加这个难度。相反，当空闲任务有足够的次数来完成它的工作时，我们就结束运行时帧。由于空闲任务的优先级最低，这确保了所有任务都充分运行。然后门信号量被发信号通知，所有等待的任务被恢复，它们的计数器被清零。此外，相同优先级的任务以暂停时的顺序恢复。这避免了任务运行中的大间隙，这可能会导致问题。

　　子任务共享其顶级父任务的［脚注ii］运行时限制和计数器。如果超过限制，子任务将立即挂起。只有当父对象和它的其他子对象试图在此之后运行时，它们才会被挂起。给任务族分配运行时限制比试图给每个任务分配运行时限制要容易得多，因为它是衍生的。

　　代币

　　在第二次世界大战期间，家家户户都收到红色的代币买肉，蓝色的代币买鱼，银色的代币买手推车。这样，我们的政府控制了消费。类似地，我们需要管理一个分区可以使用多少资源，以及该分区如何使用该资源。我们的RTOS为此使用代币。

　　A 处理是存储的地址的内存位置目标，例如任务，即它是一个特殊指针。A代币是句柄的地址。句柄是在链接时创建的，因此它们的地址在运行时是已知的。有两种类型的令牌：HI令牌允许创建、删除、修改和访问对象，而LO令牌只允许访问对象（例如信号量测试和信号）。程序员为每个任务编译一个令牌列表，并在任务创建后分配给该任务。如果未分配令牌列表，则该任务不需要令牌来访问或修改对象。后者对于诸如恢复任务之类的任务来说是必要的，并且它使可信任务变得更简单。

　

　　控制信号量访问的令牌

　　黑客可以从分区内部做的一件阴险的事情是一遍又一遍地创建同一个对象，直到对象控制块池耗尽。那么任何其他任务都不能创建该类型的对象。这被阻止如下：首先，黑客使用的任务必须有一个对象的HI令牌。第二，一旦创建，该对象在被删除之前不能被重新创建。

　　另一种可能的攻击是猜测一个句柄，并利用这个句柄制造麻烦。例如，可以向另一个分区中的信号量发送信号，从而导致该分区中的任务在不应该运行的时候运行。这通过要求该对象的令牌来阻止。

　　除了令牌之外，所有句柄参数在使用之前都被验证为有效句柄。对每个句柄进行范围检查，并检查其cbtype字段。这可以防止黑客在系统服务调用中使用无效对象。

　　ISR问题

　　Cortex-M中一个严重的架构缺陷是ISR运行在hmode中。大多数RTOSs都允许从ISR调用内核服务，这就更复杂了。这些共同为黑客创造了一个巨大的目标。这个目标特别有诱惑力，因为入侵它会让他进入hmode，在那里他可以关闭MPU并访问任何他喜欢的东西。

　　smx一直支持不同的设计理念，其中ISR被最小化，大多数中断处理被推迟到链接服务例程（LSR）。这些任务按调用的顺序运行，并在所有任务之前运行。LSR不受优先级反转问题的影响，因此比任务更适合延迟中断处理。LSR的开销也少了许多。当处理时间不重要时，LSR可以简单地向一个信号量发送信号，让一个延迟的中断处理任务等待。最小化ISR大小既减少了目标大小，又允许ISR程序员更专注于使代码难以破解。

　　有三种类型的LSR:tlsr、pLSRs和uLSRs。tLSRs是信任LSRs。它们在hmode中运行，开销非常低。它们应该尽可能的短，比如仅仅发一个信号量。pLSRs和uLSRs被称为安全LSR。每个都有自己的栈和自己的MPA，行为就像一个微任务。当从LSR队列调度时，LSR的MPA被加载到MPU中，并且它的栈成为操作栈。因此，安全LSR可以在它们所服务的分区中运行，这使得除了一小部分之外的所有中断处理都进入了它所属的分区。这对uLSRs来说是一大收获。

　　开发人员通常编写长的ISR来调用内核。安全LSR允许将尽可能多的代码转移到LSR，然后将LSR转移到相关的分区。因此，如果黑客侵入了ISR代码，而不是在hmode中，他会发现自己在一个隔离的umode分区中，并受到其限制。

　　要注意的一个有趣的事情是，一个安全LSR可能使用与分区中的任务相同的MPA，或者它可能更像一个子任务，并且具有一些共享区域和一些唯一区域（例如IO）。安全LSR具有非常小的控制块，并且通常需要非常小的堆栈。此外，它们的运行优先级介于ISR和任务之间。因此，它们提供了一种有趣的IO处理方式，比通常的ISR方法更安全。

　　smxAware

　　smxAware为IAR C-SPY调试器提供了内核意识。当与SecureSMX一起使用时，增加了MPU和MPA显示。这使得在跟踪MMF时更容易看到区域大小和属性。此外，门户操作显示在事件时序图中，MPU区域显示在存储器映射概览图中。

　　事件监督

　　大量内核事件被监控，如服务调用、ISR运行、LSR运行、任务操作、错误等。每个事件的相关信息存储在事件缓冲区EVB中。此外，可以定义和记录用户事件。可以对日志进行过滤，这样EVB就不会太快填满。EVB可以定期上传到安全监控网站，在那里特殊的软件寻找异常行为，这可能表明攻击正在进行中。如果是这样，安全控制可以采取适当的措施，例如关闭分区。

　　监控一个大型系统的所有元素的操作可能是阻止高度复杂的攻击的唯一方法，这些攻击规避安全机制并慢慢渗透到计算机网络中。

　　目标

　　在优化系统中，尽可能多的代码已从pmode转移到彼此高度隔离的umode分区，门户用于分区间通信，所有不受信任的任务都受到运行时和令牌的限制，延迟中断处理在安全LSR中完成，关键任务代码和数据受到pmode屏障的双重保护。

　　虽然这一目标在新设计中是可以实现的，但在现有设计中不太可能实现。将所有不可信的代码转移到一个umode分区中并对其进行一些限制可能是一个合适的解决方案。SecureSMX专门设计用于提供实施部分解决方案的灵活性。它还被设计为允许增量改进，其中安全团队一次解决一个问题，从而实现渐进的安全改进，而不需要倾家荡产。

　　认识到仍然可以使用其他安全措施是很重要的，例如信任根、安全引导、安全更新、加密和代码改进。相反，它提供了一个坚实的安全基础，并提供了许多处理安全问题的新选项。

　　将应用移植到SecureSMX

　　为了方便将现有应用程序移植到我们的安全RTOS，它包含了FRPort和TXPort。这些提供了移植功能，将应用程序中使用的90%以上的FreeRTOS和ThreadX服务调用移植到等效的smx服务调用。更多的港口正在规划中。试图在其他RTOS上运行SecureSMX是行不通的，因为它与SMX的丰富内核特性紧密相关，而这些特性是其他RTOS所没有的。将应用程序转移到it部门应该会带来更好的操作，并允许访问上面讨论的所有安全特性。

　　未来

　　到目前为止，许多设备都被黑客攻击过，但黑客们主要关注的是网络钓鱼等唾手可得的东西。进入计算机网络。然而，随着公司采用更好的安全软件和更好的安全实践，这个唾手可得的果实开始消失。如前所述，黑客的下一个主要目标很可能是已经连接到计算机网络的数千台未受保护的设备。这些很容易破解。

　　设备供应商的高层管理人员需要决定是现在就开始采取谨慎的措施，还是以后雇佣一支军队来应对对他们设备的攻击。将来，法院可能会裁定不充分的安全措施构成疏忽，因此设备制造商将面临损害赔偿［参考文献5］。这可能会让许多公司破产。即使这不会发生，可证明的安全性也可能成为许多类型设备的主要卖点。

　　纵观整个软件行业，在大多数嵌入式系统中，可能只有大约10%的软件执行关键工作。这个准则是公司业务的精髓。它可能是经过严格编写、彻底测试和现场验证的，因此不太可能改变。其余90%的代码混合了第三方、开源和新开发的代码，并且很可能存在许多漏洞。如果没有分区，这段代码中任何地方的黑客攻击都会暴露整个系统，从而为勒索攻击和窃取关键数据提供便利。让一家公司如此脆弱是没有道理的。

　　此外，应该预见到内部攻击将变得更加普遍。当提供大量资金时，员工忠诚度可能是可以协商的。关键任务代码是公司皇冠上的宝石。它应该被锁起来，除了少数高度信任的员工外，其他人都不能访问。因为关键任务代码可能不需要更新，所以它不需要包含在仅分区更新中。如果关键任务代码不包含在更新中，它就不能被篡改，这给避免灾难性攻击带来了一些希望。

　　结论

　　我们的新RTOS旨在提供一套灵活的工具和结构，以提高现有基于MCU的系统以及新系统的安全性。它允许对受信任的遗留代码进行最少的修改。其固有的灵活性允许首先修复最重要的问题，从而逐步提高系统安全性。

　　如果使用SecureSMX作为新系统的基础，很可能只需很少或不需要增加时间或开发成本就可以实现强大的安全性。这是因为它提供了设计实践的硬件实施，证明可以减少集成和调试时间。在安全保护方面，下游的回报是巨大的。对于上面介绍的所有功能，与SMX相比，SecureSMX的代码量增加了大约20 KB。考虑到典型MCU上的大型片内闪存，以及典型应用代码的大小，这可以忽略不计。一个更大的问题是节省宝贵的片内SRAM，我们提供了工具和技术来最大限度地减少v7M架构对齐造成的浪费，如“缩小区域间的差距”一节所述。

　　审核编辑：黄飞