几周前，国际监管机构发布信息，波音787运营商在运行51天之时，必须不间断地完全关闭飞机的电源。美国联邦航空局发布了详细说明该问题的适航指令，我很好奇这份文件中包含了哪些细节。

我发现FAA指令中一些可用信息，有足够的信息使我步入正题以了解问题的根本原因。这篇博客文章将利用FAA指令中有趣的信息来获得有关某些航空电子概念的知识。

首先，我们需要介绍与该问题相关的787架构和系统的各个部分。FAA指令明确使用了诸如CDN或CCS之类的首字母缩写词，然后才需要进行根本原因分析。

0x01 通用核心系统介绍（CCS）

与使用分散式航空电子功能打包成独立单元的联邦航空电子体系结构相反，集成模块化航空电子（IMA）体系结构采用了高完整性的分区环境，该环境可在一个飞机上承载多个具有不同关键性的航空电子功能——共享计算平台。波音工程师为787开发了通用核心系统（CCS），这是基于开放IMA航空电子技术的进一步增强版本。

本质上，CCS是一个硬件/软件平台，可提供计算、通信和输入/输出（I / O）服务，以实现实时嵌入式系统。

多个托管功能在虚拟系统环境中共享平台资源，该虚拟系统环境由依赖于VxWorks 653 3,4 OS 的分区机制组成，该分区机制是作为平台设计的一部分实施的。

这种虚拟系统分区环境可确保托管功能相互隔离，因此它支持高度关键的应用程序，还支持较低级别的应用程序完整性。国际法规将故障条件定义为五个级别，按其对飞机，机组人员和乘客的影响进行分类：

A级-Catastrophic

故障可能会导致多人丧生，通常会造成飞机损失。

B级–Hazardous

故障会对安全或性能造成很大的负面影响，会因身体不适或工作量增加而降低机组人员操作飞机的能力，或者会给乘客造成严重或致命的伤害。

C级-Major

故障会大大降低安全裕度，或者会大大增加机组人员的工作量。可能导致乘客不适（甚至轻伤）。

D级–Minor

故障会稍微降低安全裕度，或者会稍微增加机组人员的工作量，例如可能导致旅客不便或更改常规航班计划。

E级-No Effect

故障不会影响安全，飞机运行或机组人员的工作量。

批准为A，B或C级的软件高级认证，其中涉及用于验证和可追溯性的正式流程

DO-178B 6 Level-A软件可能与Level-E应用程序共存于同一物理共享资源中。

图1. VxWorks 653体系结构

理想情况下，无论托管功能或平台资源中是否可能发生故障，这些应用程序都不会相互干扰，这些功能是预先确定的，并通常通过XML或专有二进制格式的可加载配置文件传达给平台组件。

在CCS中，我们可以找到以下主要组成部分：

· 通用处理模块（GPM），可满足功能处理需求

· 支持系统模拟信号，模拟离散信号和串行数字接口（CAN总线8，A429 9等）的远程数据集中器（RDC ）

· 航空电子全双工（A664-P7）交换式以太网10网络，用于平台元素之间的通信

· 这些元件可以包装为线路可更换单元（LRU），也可以模块或卡的形式包装，然后可以组合在机箱或集成的LRU中。

CCS由以下组成：

· 两（2）个通用计算资源（CCR）机箱

· 通用数据网络（CDN）

· 21个RDC

图2. CCS体系结构A

通用计算资源柜

每个CCR机箱具有：

· 两（2）个功率调节模块（PCM）

· 八（8）个通用处理模块（GPM）

· 两（2）个ARINC 664-P7网络机箱交换机（ACS）

· 两（2）个光纤转换器模块（FOX）

· 两（2）个图形生成器（Display and Alert Crew系统的一部分）

图3.波音787 CCR机箱

每个GPM是一个独立的计算平台，可承载飞机系统的运行软件，并为承载的应用程序提供基于ARINC 653标准的分区环境。每个GPM具有相同的硬件和核心操作系统。

这些CCR机箱中的GPM运行托管功能，例如远程配电系统（RPDS），发电机/公共汽车电源控制单元（GCU / BPCU），13个断路器指示和控制，起落架指示和控制，推力管理功能以及飞行管理功能。

通用数据网

CDN是使用IP寻址和相关传输协议（UDP）的高完整性IEEE 802.3以太网。作为符合A664-P7的网络，它还实施确定性定时和冗余管理协议。CDN同时使用光纤电缆和铜线，并直接或通过ACS，FOX或RDC在与其连接的各种飞机系统之间移动系统信息。

图4. 787网络架构

CDN由每个连接端节点中托管的网络端系统（ES）和多个网络交换机组成。

终端系统

在按照A664-P7规范定义的航空电子网络的范围内，我们发现：

终端系统（ES）的主要功能是提供服务，以确保与分区软件进行安全可靠的数据交换。

本质上，ES承担着网络接口控制器（NIC）的角色，它能够维护多个托管应用程序写入和读取的消息的通信端口（排队，采样或SAP）。这是通过虚拟链路（VL）交换以太网帧来完成的，虚拟链路是一种概念上的通信对象，它定义了从一个源到一个或多个目标ES的逻辑单向连接。VL中的业务流的形状应设置为不超过配置的带宽分配间隙（BAG），该带宽表示两个连续帧的第一位之间的最小时间间隔。

图5. CDN中的ES通信

CDN（也在交换机中）中运行的ES与主处理器在物理上是分开的，并通过PCI总线进行接口。从高层的角度来看，它包括：

· 一（1）个定制ASIC

· 两（2）个COTS以太网PHY收发器

· 两（2）个串行配置存储器

· 内存

图6.最终系统板的高级概述

可以通过专有API从主机配置ES。之前已使用DO-178B A级工具（ESBIN）生成了此配置数据，然后将其存储在自定义文件（es_config.bin）中。

CDN交换机中的ES实现了几乎相同的功能，除了一些寻址和冗余操作。

远程数据集中器

CCS中有21个RDC。

图7.远程数据集中器

这些RDC提供了飞机系统之间的接口，这些系统不支持CDN中的A664-P7。

RDC将这些信号转换为ARINC 664数据，反之亦然，因此有效地充当了各种模拟设备的网关，例如传感器或阀门，ARINC 429总线和CAN子网。

从A664-P7的角度来看，这些RDC映射：

· 模拟信号到参数

· A429至通讯端口

· 到参数和通讯端口的CAN总线

结果，高级架构将如下。

图8. CCS的高级概述

为了从整体上更好地说明此体系结构，我们可以简化其中一个托管函数，以了解所有部分如何协同工作。

起落架控制软件在GPM分区中托管的一个CCR中运行。此托管功能分区通过CDN从21个RDC之一接收变速杆的上/下数据以及齿轮和齿轮门位置数据。然后，根据接收到的信号，起落架控制软件可以通过CDN向适当的RDC发布起落架排序命令。然后，RDC可以将特定信号传递给那些致动器，例如，这些致动器会向控制阀供能，以缩回和伸出起落架或打开和关闭起落架舱门。

0x02 根本原因分析

FAA的指令在技术细节上很少。它仅包含对该问题的高级描述；但是，它为读者提供了一些有助于根本原因分析的关键事实：

FAA已收到一份报告，指出连续打开51天后，CCS的过时数据监视功能可能会丢失。这可能会导致CDN消息期限验证的未检测到或未通知丢失，以及CDN切换失败。CDN处理所有对飞行至关重要的数据（包括空速，高度，姿态和发动机运行），并且这种情况可能导致几种潜在的灾难性故障情况。潜在的后果包括：

· 显示两名飞行员的误导性主要姿态数据。

· 在两名飞行员的主要飞行显示器（PFD）上显示误导性的高度。

· 在两名飞行员的PFD上显示误导性的空速数据，但不进行通知

· 故障，失速警告丢失或超速警告。

· 在两个发动机上显示误导性的发动机运行指示。

如果不解决，连续上电51天，CCS的陈旧数据监视功能可能会丢失，这可能导致错误的飞行关键数据被发送并显示为有效数据，从而降低机组人员的能力。保持飞机的安全飞行和着陆。

我将仔细分析每个句子。

FAA已收到一份报告，指出连续打开51天后，CCS的过时数据监视功能可能会丢失。

早在2015年，美国联邦航空局（FAA）颁布了类似的指令，尽管在此情况下对潜在问题的描述更为明确。

波音已向我们建议在实验室测试中发现一个问题。

发电机控制单元（GCU）内部的软件计数器在连续通电248天后将溢出。

因此，基本上，我们可以假设情况大致相同：波音公司在实验室测试中发现了当前问题。

2015年美国联邦航空局（FAA）指令还明确提到波音公司正在开发软件补丁以解决该问题；但是，此当前指令中未提及任何即将发布的补丁。正如我们稍后将看到的，如果漏洞与硬件相关，这是有道理的。

再次提到“ 51天”，最初是指向机箱上的某种溢出。

这可能会导致CDN消息期限验证的未检测到或未通知丢失，以及CDN切换失败。

这句话告诉我们有关问题性质的许多事情。首先，在787中未被检测到或“未通知”的CDN中的任何灾难性错误都是非常意外的，尽管对于我来说，尚不清楚CDN消息时间验证的丢失和CDN切换失败是未被检测到还是仅仅是第一个问题。维护工程师和飞行员都可以通过Flight Deck的维护页面检查CCS交换机和CDN LRU的状态。此外，任何重大故障都将通过中央维护计算功能（CMCF）进行集中，记录和处理。

图9.飞行甲板中的CCS状态

同样，飞行员可以在顶置面板上重置左右CCR。但是，正如FAA指令所述，需要完全关闭电源，因此我们可以假定CCR复位不能解决问题。这意味着问题不仅在CCR中而且在CDN的其他部分中都存在于组件的硬件中。

图10 CCR重置按钮

所以我们有：

· CDN失去了执行能力。

· CDN切换失败。

让我们通过分析CDN中如何加强数据通信完整性来缩小潜在犯罪问题的范围。

CDN中的完整性检查

请记住，CCS是一个异步系统，其中每个分区不仅控制何时生成其数据，而且还将该操作与网络接口分离。在MAC级别，A664-P7规范要求不管PHY的状态如何，都必须输出输出接口，以防止错误传播或旧帧的重新传输。不过，在AFDX航空电子网络中，顺序很重要，因此，当发送分区生成某些数据时，接收方分区希望以相同的顺序收集该数据。

另外，尽管在理论上可以将CCS配置为独立运行，但CCS遵循具有两个不同通道（“ A”和“ B”）的冗余策略进行操作。

图11.帧处理逻辑

为了满足这些要求，ES在发送帧时在AFDX有效载荷之后添加序列号（SN）。ES重置后，此SN为0，然后为1-255。ES中收到的冗余帧遵循“首次有效获胜”策略。请注意，除了顺序完整性外，还有一个检测实际冗余帧的过程，其中使用配置的常数（Skew Max）来限制两个可能冗余帧的有效时间窗口。

图12.常规AFDX框架

这种逻辑对于所有AFDX ES都是通用的，我认为此功能并不是真正的缺陷所在，因为任何问题都将更多地取决于流经CDN的流量，而不是特定的时间段。但是，有趣的是，ES的完整性检查和冗余管理中有些东西使787有点特殊：波音专有的错误检测编码（EDE）协议。

EDE协议

EDE协议在VL级别上工作，以在CDN中添加一层额外的端对端完整性检测。

当波音（Boeing）要求使用EDE启用VL来处理关键和必要数据时，发送方ES将有效负载封装在EDE标头和页脚中。

图13. EDE包装的框架

EDE页眉和页脚包括以下字段：

· SN：绑定到特定COM端口的2字节序列号。对于每个传输的帧，此值都会增加。

· 时间戳：一个6字节的值，使用发送ES的本地时钟域保存发送消息的时间。

· CRC X和CRC Y：这些CRC是使用EDE源ID（仅VL中的ES发送器和接收器才知道的32位值），EDE时间戳和有效负载来计算的。

EDE时间戳与发送ES的时钟域有关，因此CCS需要一种方法来集中并跟踪所有本地时间参考，以便可以正确执行任何时间验证。此任务由“时间管理”功能循环执行，该功能维护一个相对偏移量表，以及CDN中每个ES的时间参考之间的关系。这要归功于请求/响应协议，其中每个ES中的时间代理都由时间管理器定期询问。

然后，通过时间偏移消息将所得的偏移表广播到每个ES，以便ES可以在从另一个ES接收数据时执行EDE时间验证。显然，计算和传播这些偏移量表所需的EDE时间管理数据包无需经过EDE时间验证。

在EDE协议的上下文中，CDN中的时间验证依赖于这些偏移量表的一致性。那么，如果由于某种原因失败了该怎么办？

有几种可能的方案：

· ES未收到偏移表。 该消息被转发到EDE Redundancy Manager，但设置了一个标志以指示其寿命无法验证。

· 时间大于最大配置的时间。 该消息被直接丢弃。

· 时间小于最大配置的时间。 这是预期的情况。该消息将转发到EDE Redundancy Manager，最终到达COM端口。

· 时间不一致。 由于某种原因，该消息似乎存在一个没有意义的时间。例如，假设发送ES设置的时间戳接近其环绕值。执行所需的计算后，接收方ES将获得一个已包装的时间戳记，因此，看起来该消息在实际发送之前就已被接收。该消息已被接受，但仍可以处理，因为它的时间未知。

请记住，此功能是在ASIC中实现的，并且时间戳应该从计数器中得出，我认为整个问题可能都围绕此逻辑。

可能的解释

6字节的EDE时间戳是确保CDN一切顺利的关键。根据定义，此时间戳中的最高有效位设置为0，因此理想情况下，我们将0x7FFFFFFFFFFFF作为EDE时间戳的最大相干值。

ES通过PCI以33MHz的频率从托管应用程序接收数据，因此以类似的时钟频率实现计数器是合理的，以便ASIC可以使用该时钟参考来为准备就绪的消息加盖时间戳。因此，让我们假设计数器理想情况下工作在33MHz上，并且时间戳以某种方式从该计数器导出，同时还要考虑到不同的参数，例如由于跨不同接口（RMII，PCI等）移动数据而导致的延迟和延迟。

通过计算理想计数器（从0开始）运行的频率，以便在51天后回绕EDE时间戳（0x800000000000），我们获得了〜32MHz。这非常接近我们的假设。

CDN处理所有对飞行至关重要的数据（包括空速，高度，姿态和发动机运行），并且这种情况可能导致几种潜在的灾难性故障情况。

我们之前曾介绍过DO-178B认证级别，其中A级对应于灾难性故障，这阻止了持续的安全飞行或着陆。

潜在的后果包括：

· 显示两名飞行员的误导性主要姿态数据。

· 在两名飞行员的主要飞行显示器（PFD）上显示误导性的高度。

· 在两名飞行员的PFD上显示误导性的空速数据，而不会提示故障，以及失速警告或超速警告的丢失。

· 在两个发动机上显示误导性的发动机运行指示。

美国联邦航空局（FAA）文件中涵盖的后果似乎与飞行员不再相信自己的仪器的情况密切相关，在过去的事件中，这一问题已导致悲剧性后果。

在波音787中，所有这些数据都由显示机组警报系统（DCAS）处理。该系统为飞行员提供了飞机安全运行所必需的所有音频，触觉或视觉指示，如下图所示。

图14. DCAS包括多个显示器

如果不解决，连续上电51天，CCS的陈旧数据监视功能可能会丢失，这可能导致错误的飞行关键数据被发送并显示为有效数据，从而降低机组人员的能力。保持飞机的安全飞行和着陆。

最后一段，作为对本博文中阐述内容的总结。

0x03 研究总结

航空安全研究是一个复杂的领域，不仅因为围绕这些技术的机密性，而且由于商业和公司壁垒阻碍了对所需设备的访问。尽管存在所有这些挑战，但我认为促进此类研究的任何努力总能取得回报。

时机也很有趣，因为在将我们的研究报告给波音公司后将近一年，这个缺陷就暴露出来了。波音公司承认他们建立了一个功能齐全的飞机实验室来评估我们提交的问题（涉及CDN），因此我想，他们的后续研究可能会发现这一问题。概括而言，这将是任何安全研究的良好副作用，所有这些研究都在于在人们所依赖的设备和组织中建立适当的信任级别。

不要将我在这里介绍的内容当作波音公司发现的问题的真正根本原因。我可能是对的，但很可能我错了，这是为了满足我的好奇心。

0x04  参考信息

[A] [IOActive White Paper: Arm IDA and Cross Check: Reversing the 787’s Core Network](https://act-on.ioactive.com/acton/attachment/34793/f-cd239504-44e6-42ab-85ce-91087de817d9/1/-/-/-/-/Arm-IDA and Cross Check%3A Reversing the 787's Core Network.pdf)
[1] https://www.federalregister.gov/documents/2020/03/23/2020-06092/airworthiness-directives-the-boeing-company-airplanes
[2] https://www.aviationtoday.com/2007/02/01/integrated-modular-avionics-less-is-more/
[3] https://en.wikipedia.org/wiki/ARINC_653
[4] [https://www.windriver.com/products/product-overviews/vxworks-653-product-overview-multi-core/vxworks-653-product-overview-multi-core.pdf](https://resources.windriver.com/vxworks/vxworks-653-product-overview)
[5] https://www.windriver.com/customers/customer-success/aerospace-defense/boeing/ (404 link broken)
[6] https://en.wikipedia.org/wiki/DO-178B
[7] http://www.artist-embedded.org/docs/Events/2007/IMA/Slides/ARTIST2_IMA_WindRiver_Wilson.pdf
[8] [https://en.wikipedia.org/wi](https://en.wikipedia.org/wiki/CAN_bus)[k](https://en.wikipedia.org/wiki/CAN_bus)[i/CAN_bus](https://en.wikipedia.org/wiki/CAN_bus)
[9] https://en.wikipedia.org/wiki/ARINC_429
[10] https://pdfs.semanticscholar.org/5db4/b539ed7bdec182448ac8d7219db12a8bbc12.pdf
[11] https://en.wikipedia.org/wiki/Line-replaceable_unit
[12] https://bioage.typepad.com/.a/6a00d8341c4fbe53ef0162fbf813b6970d
[13], [14] https://s3.amazonaws.com/public-inspection.federalregister.gov/2015-10066.pdf
[15], [16] https://www.instagram.com/787guide/

本文翻译自：https://ioactive.com/reverse-engineers-perspective-on-the-boeing-787-51-days-airworthiness-directive/如若转载，请注明原文地址：