如何保持c语言程序的安全

《如何保持c语言程序的安全》由会员分享，可在线阅读，更多相关《如何保持c语言程序的安全（4页珍藏版）》请在金锄头文库上搜索。

1、如何如何保持保持 C 语言语言程序程序的的安全安全 作者作者 Anders Holmberg, IAR Systems 翻译翻译 BMR 如何如何避免避免 C语言语言固有的固有的一些危险一些危险 本文将涉及用语言开发带有安全关键功能系统的一些问题。尽管这种语言充满不确定行为、依赖硬件 和包含其他陷阱等都是事实，但它仍然是一个安全关键开发领域使用的最广泛和最流行的语言。随着一些深谋远虑和规划，我们可以把这个潜在的问题变成了优势。 1. 移动你的脚步移动你的脚步 早在 1991 年， 开发者的洞察力杂志发表一个有趣的标题为如何搬起石头砸自己的脚文章的开头说： “随着现代编程语言的大量扩散（所有这一

2、切似乎彼此已经被盗了无数的功能）有时记得您目前使用什么语言都是很困难的。本指南作为一项公共服务，以帮助程序员发现自己是否处于这样的困境。 ” 由 C 开始的语言列表和其简单的状态： C -你搬起石头砸了自己的脚 此判决可能显得有点苛刻，但还是有些道理的。然而，即使替代编程语言可能没有如类型安全和不确定的行为等方面的问题，但他们往往缺乏编程控制硬件功能。如果我们坚持用 C 语言，我们就需要在明显 的和不那么明显的陷阱之间找一个平衡点，同时善用其特点。我们可以从两个不同的角度看看 C 语言安全关键功能编程的发展情况： 在安全关键的项目中有哪些外部需求，需要对于编程语言进行选择吗？ 你可以做些什么弥

3、补一些明显的 C 语言的缺陷呢，还有就是你是面对的是工作时遗留代码？ 2. 标准的答案标准的答案 如果您正在涉及如汽车、工业控制、医疗设备、或铁路等方面的产品，它们有正式的功能安全要求。 这种要求可以归结为一个非常具体的产品耐受性故障率的要求，或产品中某些特定功能的允许故障率。它也可以是一个按照 IEC61508（电气和电子可编程器件） ，ISO26262（汽车） ，或 EN50126x（铁路）等特定的功能安全标准开发的产品。10 年了，一个明显的趋势是安全功能的实施正在远离纯机械或 PLC 控制的自动 化而进入单片机的世界，因此这种要求也渗透到了软件领域。 由于各种标准对软件要求的意图是类似

4、的，我们使用 IEC61508 标准作为一个例子。本标准规定了许多 部门的具体标准的基础要求，对 IEC61508 有效的要求很大程度上对例如 ISO26262 也是有效的。 这些标准将严重影响你的工作方式和您的工作文档：从收集需求到你的产品如何在客户现场部署和退 役计划。这不是您和您的项目利益相关方单独决定是否你已经成功地在一个选择标准时达到了目标，还必 须说服来自认可机构的第三方评估员，或者是在您的组织中扮演这部分角色的相关人员。 这些标准大部分使用的是安全完整性等级概念的变种。所以根据您产品的分类，在你如何运用合适的标准时将会有一些变化。 3. 标准适用吗？标准适用吗？ 让我们说一个有趣

5、的问题：在我选择编程语言是要做什么呢？不可小视，它开始了。下表给出了如何 选择一个合适的编程语言的建议，具体内容取决于您的应用程序或安全功能的安全完整性水平。 人力资源是短缺的，这是一个普遍的共识。否则，即正当的理由，你可以备份 100。 表表 A.3 软件设计和开发支持工具与不编程语言软件设计和开发支持工具与不编程语言 技术/测量* 参考 SIL1 SIL2 SIL3 SIL4 1 合适的编程语言 C.4.5 HR HR HR HR 2 强类型编程语言 C.4.1 HR HR HR HR 3 语言子集 C.4.2 HR HR 4a 认证工具和认证的翻译 C.4.3 R HR HR HR 4b

6、 工具和翻译: 增加使用者的信心 C.4.4 HR HR HR HR 注释 1 看表 C. 3 注释 2 在引用的第 3 栏中（这里内容翔实，但不规范）”B.x.x.x”, “C.x.x.x” 表明 IEC61508-7 的附件 B 和 C 中给出技术/措施的详细说明。 *依据安全完整性标准选择合适的技术和测量。替代或等效的技术/措施被由一个字母和其后的数字表示。它的目的是只有一个替代或等效的技术/措施应该被满足。合理的替代技术应根据附录 C 中给出的特定的应用需要的属性来选择。 表 1：来自 IEC61508 第 3 部分附录 A 表 3.1 说什么呢？说什么呢？ 正如你在表中看到的，使用合

7、适的编程语言是被强烈建议的，但是真这么做确并没有很大的意义。但 表中引用的 C 附录给出了一个合适的编程语言定义如下： 语言应充分和明确的定义。语言应该是面向用户或问题的，而不是面向处理器/平台的。广泛使用的语言或它们的子集是首选的专用语言。语言应鼓励使用小的和可管理的软件模块；在特定的软件模块中限制对数据的访问； 变量子范围定义；以及限制错误性构造的任何其他类型。 让我们看看上述定义的各个部分，C 是如何堆叠出他们来的： 语言应充分明确定义：嗯.这取决于你如何考虑，可以说 C99 包含至少 190 未定义行为。 语言应该是面向用户或问题的，而不是面向处理器/平台机器的：嗯，C 最初创建是为

8、PDP-11 架构的系统开发语言；给定的一个特定目标一个特定的 C 实现必然与另一个目标的实现是不同的，有时甚至与相同目标的另一种实现都不同，我们真的很难认为 C 符合这个定义的这部分. 广泛使用的语言或它们的子集是首选的专用语言：最后，对 C 我们可以要求的东西是事实！有大量知道 C 或任何其表兄弟像 C + +的开发人员在那里。 语言应该鼓励使用小的和可管理的软件模块; 限制在特定的软件模块中访问数据；变量子范围定义; 限制错误性构造的任何其他类型：虽然 C 没有明确禁止支持这些概念的抽象创作，但是可以说 C 语言本身是彻头彻尾的绝对没有支持它们。事实上，它甚至可以被认为与此正好相反。 在

9、标准方面 C 没有完全辜负我们的期望。我们可以做些什么呢？ 其实，答案很简单，至少只要我们在读这些标准。如果我们阅读，我们会发现一个特定语言的判断表， 这就是它的对 C 说的： 9 C R _ HR HR 10 C 子集和编码标准，并使用静态分析工具。 HR HR HR HR 表 2：来自 IEC61508，第 7 部分，附录 C 尽管 C 不是一个值得被推荐的语言，但是，如果与编码标准和静态分析工具一起使用，带有一个适合 的子集 C 甚至是强烈推荐的语言。但是，在此背景下子集和编码标准意味着什么？ 4. 子标准子标准 在此背景下，语言子集的目的就是为了减少编程错误的概率，增加寻找悄悄以任何途

10、径进入到代码库 中错误的可能性。对于 C 语言，这意味着消除了使用未定义或实现定义的行为的可能。有很多这样的语言子集可供使用，但最广为人知的可能是 MISRA-C。 MISRA-C 规则集开始是英国汽车工业软件可靠性协会的一项倡议，仅仅着眼于汽车软件。多年来，MISRA-C 规则已经扩展到世界各地，和其它细分行业，其规则集 是现在在嵌入式行业使用最广泛的 C 子集。 还有我们在 IEC61508 编码标准的问题上说了很多。下面是一些 MISRA-C 规则之外的主题的例子： 如何来保护共享资源，如全局变量的访问。 使用用于对象分配栈和堆的内存。 允许或不允许递归？ 复杂性的限制，如允许的函数圈复

11、杂度的限制。 例如如何免除 MISRA-C 在一定情况下不适用的规则。 如何使用编译器的具体功能，如本征函数或语言扩展。 如何使用范围检查，断言和前置和后置条件和类似的结构来捕获错误。 模块之间接口的组织和访问。 文档要求。 从本质上讲，编码标准应提供一些如何处理影响代码质量和完整性的问题的意见，但是现在没有明确 的语言或子集涉及这个。 5. 孰能生巧孰能生巧 现在，我们将接触上一节出现的一些话题，以及如何在一个项目中处理他们。 5.1 MISRA-C 如果您打算使用 MISRA-C， 你开始一个新项目和你正在使用的旧代码的方法略有差别。 对于新开发的代码，请考虑以下建议： 不要停止你自己的方

12、式，而盲目支持每个规则！对于部分代码，你可能无法遵守一个或多个规则。这对硬件接口代码是特别真实的。 相反，做出一个偏离规则和文档的明智决定。如果你的目标应该支持所有规则，或者如果有一个项目层面上可以忽略不计的规则，应该尽早与项目股权持有人和你的外部评估员讨论。 在任何时候，力求符合处理基本类型以及与这种类型相关算术和转换的规则！这个区域是充满了陷阱和代码似乎可以完全在一个平台上运作，但在另一个平台上就完全不行。 如果你发现自己使用的偏差程序为同一规则，并且重复出现在类似的代码块中，你应该考虑它作为一个警告信号： 你正确地解释规则了吗？ 这种代码模式真的需要吗？如果是的话，可以考虑其作为一个独立

13、的函数或一组函数分解出有问题的代码。 使用静态的检查，可以在开发过程中交互检查您是否遵守规则。 如果你在遗留代码上应用 MISRA-C 规则，下面的建议是有益的： 一次使用一个规则。 先选择简单的规则，如规则，也包括由和形成的单个语句有条件构造体。 （MISRA-C：2004 规则 14.8） 仔细看规则说明，如 short、int 和 char 这样的简单类型不应该被使用，并考虑更换一个模块每次使用显式指定大小的类型，如 uint16_t等。 对一些简单的模块练习一下之后，再开始处理被认为是维护困难和问题多的模块。 5.2 同步吧！同步吧！ 现在，我们将改变焦点到 C 语言更广泛的误解区域之

14、一：volatile 关键字。不管你问谁，使嵌入式系统 崩溃和烧坏的事情列表中，滥用这个关键字的排名都很靠前。 声明一个对象为 volatile 的主要原因是通知编译器对象的值可以由编译器未知的方式改变，因此必须保 留所有这样的访问对象。volatile 对象创建需要有三种典型场景： 共享访问; 在多任务环境中多个任务之间共享的对象，或从一个执行的单一线程与一个或多个中断服务例程访问的对象。 触发访问；对于一个内存映射的硬件设备，那里一个访问发生的事实影响这个设备 修改访问：对象的内容可以以编译器不知道的方式改变 那么，如果你应用 volatile 关键字给一个对象声明，你能从编译器获得什么样

15、的保证呢？大意如下：所 有读取和写入访问被保留。就是这个！ 根据目标架构，如果适用，使用原子性操作，你也可能按抽象机器给定的顺序进行而完成所有访问。 图 1：一个 ARM/ THUMB 目标的 volatile 汇编 从不同执行环境访问 volatile 对象给出的图 1 中的代码是线程安全的和中断安全的吗？无论是从内存加载和存储到内存的 vol 值是原子性的，因为这是一个 32 位加载/存储架构。但源代码语句是不是原子性的！ 我们仍然可以通过上下文切换或在三个指令之间某个地方中断弥补 vol+语句而被击中。 如何处理如何处理？ 永远不要假设除了某些内存访问 volatile 意味着原子性！

16、如果该对象可以从不同执行环境访问，确保做更多的而不仅仅是一个原子读或写 volatile 对象的代码通过合适的像一个互斥量或禁止中断的系列化原语来保护。 在您的编码标准中覆盖 volatile 关键字和系列化原语正确用法。 考虑检讨在存在的代码中包括文件范围的静态对象的所有全局对象的用法。 5.3 增加堆栈吗增加堆栈吗？ 你的堆栈大小足够吗？对开发人员来说这是一个永恒的难题。如果你的堆栈大了，这可能意味着浪费 了板上存储器的一部分。如果堆栈太小了，我们可能会陷入灾难中，至少可以说，这对于有安全关键要求 的产品可不是什么好事。下面是确定的堆栈大小要考虑可能采取行动一个清单： 如果这样的功能是可用的，使用您的调试器的运行时堆栈检查功能。 可以在运行时由一个专用检查例程定期检查的一个神奇模式填写内存以上和/或堆栈之下。由于在 IEC60730 标准对家用电器的要求，你的MCU 供