全局变量 有着 1 万个全局变量的一大坨代码

本文由黄晓飞博乐在线翻译。未经允许禁止转载！

英文来源:safetyresearch。欢迎加入翻译团队。

2013年10月，丰田仓促了结“意外突然加速”(以下简称“突然加速”)一案。经过几个小时的讨论，俄克拉何马法院陪审团认定丰田汽车制造商“不顾一切地忽视”(用户的安全)，并责令丰田公司赔偿原告300万美元。这不包括可能对丰田造成的巨额惩罚性赔偿。

陪审团根据其掌握的证据对丰田做出了“严重忽视安全责任”的裁决。原告的两位软件专家就丰田的软件设计和设计过程作证，令人惊讶。在回顾了2005年丰田凯美瑞的软件开发流程和源代码后，两位软件专家得出了一致的结论，丰田的系统不仅有缺陷，而且有危险。因为故障保护机制充满了错误和不一致性，这是事故的根源。

布克特和施瓦茨对丰田提起的诉讼源于2007年9月“丰田汽车突然加速造成严重车祸”事件。当时，让·布克奥特和她的朋友芭芭拉·施瓦茨(当时坐在副驾驶位)正准备从俄克拉荷马州的69号州际公路上离开，但她驾驶的2005年丰田凯美瑞的油门失去了控制。当时她踩刹车没用，只好拉起手刹。结果，右后轮留下了150英尺的制动痕迹，左后轮留下了25英尺的制动痕迹。然而，丰田凯美瑞并没有停下来，而是从坡道上飞驰而下，在底部横穿马路，撞上了路堤。施瓦兹受重伤死亡；布克特在医院呆了五个多月，才从严重的头部和背部受伤中恢复过来。

比斯利·艾伦律师事务所的格雷厄姆·埃斯代尔(原告律师)是第一个做出类似最终判决的人。他的判断是基于坡道上的两个刹车痕迹。

“丰田无法解释到底发生了什么，”埃斯代尔说。"刹车痕迹证明她当时确实刹车了."

虽然技术讨论已经(客观地)决定了证词的内容，但陪审团的态度还是很谨慎细致的。陪审团意识到案件已经结束后，陪审员问帕特里夏·帕里什法官是否可以继续讨论审判的内容。十二名陪审员、帕里什法官和被告律师再次讨论了此案。被告表示，从他们讨论的内容来看，很明显，陪审团将进一步惩罚丰田公司的行为和掩盖事实的企图。

虽然有刹车痕迹作为证据，但原告聘请了菲利普·库普曼(Phillip Koopman)和迈克尔·巴尔(Michael Barr)两位软件专家作为专家证人，让他们从程序员独特的视角洞察丰田汽车软件开发过程和源代码中的各种问题:例如，位翻转、任务终止导致的故障保护机制失效、堆栈爆炸和内存溢出保护机制不足、单一故障隔离区、 以及滥用全局变量(多达数万个全局变量)(调查结果显示)丰田在软件开发流程和软件产品上的缺陷太多，无法一一列举。

迈克尔·巴尔是一位广受尊敬的嵌入式软件工程师。他花了20多个月审阅丰田的源代码，源代码位于一个酒店套房大小的房间里，房间有五个隔间，巴尔在其中一个隔间工作。检查过程由保安监控。参与者工作时不能带皮带或手表，甚至一张纸也不能带进带出。巴尔为丰田源代码提供了法庭证词，该源代码基于他所做的测试报告，长达800多页。Pillip Koopman是卡内基梅隆大学计算机工程系的教授。他是嵌入式系统安全领域的专家，也是《更好的嵌入式系统软件》的作者。他的工作还包括私营企业的软件设计审查，他的许多客户是汽车制造商。他还为丰田的工程安全流程作证。

两者都使用了程序员使用的反语——“大量代码”(翻译:原文是意大利面条代码，即通心粉代码，把代码结构描述成通心粉一样的一坨，互相纠结，一点都不清晰，这是明显的讽刺。)，暗示丰田的代码无论是编写还是结构都很乱。

巴尔的证词:

函数很多(丰田的源码里)，都太复杂了。在标准行业的规模上，这些方法有的根本无法测试，也就是说它们的代码组成过于复杂，所以没有可靠的测试工具或方法来测试代码的所有可能情况。

有些代码甚至非常复杂，无法维护。具体来说，如果您试图删除bug或对此类代码进行任何修改，可能会出现新的错误。你的车下载了最新版本的固件——也就是我们所说的嵌入式软件——并不代表比以前更安全……而且可以断定故障保护机制不足。他们(丰田)的故障保护机制存在缺陷和漏洞。

总的来说，他们(丰田)的安全架构像纸牌搭的房子一样摇摇欲坠。所以故障保护机构失效和油门控制失效的概率很大。

巴尔还从资料中了解到，2007年10月，甚至有一位丰田的程序员将发动机控制应用代码描述为“像坨东西”。他在证词中提到了这一点。

Koopman专注于丰田的计算机工程流程管理。行业第一个工业编码标准由汽车行业软件可信性协会(MISRA)于1995年制定。虽然这个标准只是厂商为了自己的目的而制定的，但已经成为业界普遍认可的行业标准。这个标准以一系列的规则为准绳，把违规的程度等同于违规的次数:每违反30条规则，你可以认为会出现3个小bug，1个大bug。库普曼说，按照工业标准，丰田犯了一个严重的错误。

2010年，由于与美国高速公路安全管理局(NHTSA)的合同关系，NASA(美国国家航空航天局空 NASA)的软件工程师检查了丰田的一些源代码，结果，根据MSIRA-C第35条规则，他们在可审计的源代码中发现了7134处违规。巴尔在2004年根据MISRA标准在丰田的源代码中发现了81514处违规。

丰田有自己的软件流程标准，与行业标准有些重叠。即便如此，丰田程序员还是屡屡违反自己的标准。他们未能有效跟踪自己与标准的偏差，会为偏差辩护，认为符合实际标准。Koopman在证词中说:如果一开始产品研发不包含软件安全，即使你以后想添加也不会添加。

“在开发与安全相关的软件时，你必须学会极其小心。你骗不了。丰田的确关心一些安全方面的事情，但未能达到设计安全相关软件可以接受的水平。”他说。

丰田违反的最大安全标准之一是允许系统中存在单点故障机制。(单点失效是指把整个系统的安全控制权交给单个软件或硬件，就像单引擎飞机一样。)Koopman在证词中提到。

“如果采用单点失效的机制，在我见过的任何安全标准中，都属于不安全的定义，没有对策，解决这个问题的故障保护机制也不多。所有的方法只能降低失败的概率，并不能彻底根除问题。我们有数百万辆汽车在路上行驶。(这么庞大的数字)出现问题的可能性真的很奇怪，问题真的会发生。”

另一个偏离标准的非常恶劣的行为是系统中全局变量的大量使用。(变量表示内存中存储数字的位置。全局变量是指系统中任何地方的任何软件都可以读写。)唯心主义的全局变量个数应该是0。丰田使用了一万多个全球变量。

“在工程实践中，总共采用5个或10个全局变量，都可以。一万块不行，那我们就完了。这不安全。我不想一次看到一万个全局变量，才知道哪里出了问题。”库普曼在证词里是这么说的。

巴尔和库普曼在软件设计中发现的其他错误包括:缺乏同行代码审查，丰田使用电装的副CPU，但未能检查其源代码——而丰田董事会告诉美国国会和NHTSA，这一“突然加速”事故不可能是由发动机软件引起的。

巴尔作证说，很多机动车行为故障都是由于CPU中某个任务死亡造成的，因此可以推断，Bookout的突然加速事故很可能是由于CPU中某个未知任务突然失效造成的，法庭审理中称之为“X任务”。巴尔也给这个任务起了一个生动的名字，叫做“厨房多功能水槽”任务。因为这个任务同时控制着汽车的很多功能，包括油门控制、巡航控制、转向控制、恒速和熄火控制等。-很多功能的故障保护功能逻辑运行在主CPU上。

巴尔批评了丰田“看门狗”监控程序的设计，该程序是专门用于检测任务失败的软件。他在证词中表示，丰田的“看门狗”测试程序“从未能够检测到重大任务的失败”。这个程序的唯一目的是检测任务失败，但它做不到。它不是为正确的目的而设计的。”

“相反，丰田公司设计了监控程序来监控CPU是否过载，巴尔作证说:”事实上，他们(丰田公司)在监控CPU过载方面甚至没有做好正确的工作。CPU过载就是一瞬间有很多任务产生，这些任务要在一段时间内处理掉。如果这个场景持续时间太长，也会让车有危险，因为任务太多导致很多任务根本没有机会在CPU上执行，这和临时任务失败的效果是一样的。"

巴尔还作证说，丰田的软件也抛弃了操作系统产生的错误代码，直接忽略了任务产生的错误代码。巴尔在审判中说:

关于任务失败的问题，虽然我的重点是任务X，这个确实很重要，因为它控制油门，负责故障保护，但是当任务X和其他任务以不同的组合执行时，总会出现任务失败的现象。例如，任务3和任务X一起执行，任务3与任务7和任务X一起执行，或者只执行任务9(所有这些都可能导致故障)。这大大增加了汽车异常性能的不可预测性。而“突然加速”只是众多异常表现中最危险的一种。

你大概是想否定这两位软件专家的结论，因为他们只是原告聘请的技术专家，自然是想为原告利益说话，但是Koopman和Barr对软件错误的评价，以及对“突然加速”可能原因的解释，揭示了更多的事实:丰田的系统怎么会出问题而不留下任何系统痕迹；为什么丰田其他车型出现“突然加速”的问题，为什么丰田不能通过“召回地垫和刹车踏板”来解决问题，以及丰田如何通过长期隐瞒一些“突然刹车”的根本原因来逃避责任。

根据两位软件专家的描述，丰田软件系统的复杂程度令人难以置信，这也解释了为什么NHTSA会做出那样的反应，以及为什么NASA没能找到相关证据证明丰田存在“发动机马力全开、无视用户刹车指令、无错误码”等严重缺陷。例如，巴尔作证说，美国宇航局的工程师时间有限，无法访问所有的代码。他们不得不完全依靠丰田向他们汇报——在某些情况下，丰田已经成功误导了NASA。例如，美国宇航局错误地认为丰田为汽车设计了硬件保护机制EDAC(错误检测和纠正编码)。事实上，2005年版本的丰田凯美瑞根本没有EDAC，巴尔在证词中说，但丰田的电子邮件告诉美国宇航局，有。在审判时，他说:

美国宇航局不知道2005年凯美瑞没有EDAC。2005款丰田凯美瑞根本没有EDAC。所以当发生位反转时，肯定不会有硬件机制来检测。那么在某些情况下发生比特反转时，系统就无法对这个故障做出响应，软件保护措施也就无法对系统进行自然保护。因此可以得出结论(现实中)在一定情况下，比特反转故障是可能的。

软件专家的证词解释了为什么NHTSA不太可能发现被软件问题掩盖的丰田电气故障。在丰田的大多数调查中，NHTSA的故障调查办公室没有软件工程师参与。他们也没有真正的专家，能够理解现代汽车关键安全问题的复杂性。NHTSA手下这些断层调查处的工程师工作起来像古代人，工具简陋，效率低下。然后人们看到，这个政府机构的固执，翻了一倍，三倍，四倍，还像个老婆婆一样不停地说话，把“突然加速”的问题归咎于汽车的脚垫。

然而，即使NHTSA配备了专家，因为丰田的软件太复杂，故障调查办公室仍然没有足够的时间或预算来评估丰田的源代码。这就是为什么我们一直强调NHTSA需要制定功能安全规范——无论是出于他们自己的考虑还是国会的授权，他们都应该这样做。

我们把Koopman的初步调查结果草稿(第一部分和第二部分)、巴尔的法庭证言和巴尔写的幻灯片材料都贴在了网上。这些材料很长，但绝对值得一读，因为它们不仅可以满足你对这一事件的所有兴趣，还可以让你知道如何在汽车行业搞砸一个嵌入式系统，为什么NHTSA调查误入歧途，以及丰田电气架构上的软件是如何脆弱得令人难以置信。

通常，人们把“公司保守商业秘密”和“公司保护有价值的资产”这两件事联系起来。在这种情况下，我们认为所谓“有价值的资产”是技术本身，即丰田在生产汽车产品时使用的“秘密配方”。我们不能把汽车制造业的“保护资产秘密”等同于“可口可乐保护其配方”。但可口可乐1%的“秘密成分”是未公开的，其配方是可口可乐独特口味和公司“绝密”的决定性因素。据说这1%成分的配方，整个可口可乐集团不超过10个人才能接触到，估值上亿美元。)，Koopman和Barr在法庭证词中指出，丰田想要隐瞒的其实是一个会制造灾难的“配方”。根据2007年9月丰田员工之间的邮件内容:

“‘说实话，研发故障保护机制从来都不是丰田工程部的风格。’“，巴尔在法庭上看了邮件原文，“然后邮件写道，‘但是如果(这种风格)被解读为:丰田在工程控制领域很强，那么这也是一件好事。’电子邮件意味着丰田的工程部很强，产品质量很高，不需要在软件上再做一个故障保护机制。”然后，巴尔特意在另一封邮件中标注了这句话:“从长远来看，这不是一件好事。"

奖励和支持翻译人员多翻译好文章，谢谢！

奖励译者，支持译者多翻译好文章，谢谢！

1赞集点评

关于作者:黄晓飞

黄晓飞:毕业于重庆大学计算机系，SCJP南开大学软件工程硕士。目前在某国企信息中心做软件开发工程师。他的主要技术兴趣是Java平台、系统架构、C/C++、计算机图形学等相关技术。(新浪微博:@黄晓飞)个人主页我的文章34