标签: 编码标准

技术发展比以往任何时候都要迅速，每天我们都能见到新产品和功能，它们可以完成各种难以想象的任务。这不仅仅是因为移动应用和计算机；而是因为嵌入式系统和物联网(IoT)设备，它们在我们的日常生活和工业自动化等行业中迅速变得司空见惯。 这些设备几乎靠软件运行着一切：婴儿监视器、扬声器、健身追踪器、安全摄像头、恒温器和车辆等。 关于这个新世界，建筑师、MIT教授和作家Nicholas Negroponte说：“像空气和饮用水一样，我们只有在数字化缺席时才会注意到它，而不是它存在的时候。”按照内格罗蓬特的观点，我们已经让数字技术包围了我们，我们甚至在它缺席或造成功能安全或信息安全问题时才会注意到它。 我们所知道的物联网设备——包括嵌入式系统——具有通过互联网连接的处理器、传感器和其他特性。而当我们谈论嵌入式系统时，我们指的是在更大的数字、机械或电力系统中具有特定功能的处理器。嵌入式系统可以是物联网设备中的固件，或者是汽车、机器人、信用卡读卡器、手机、小工具、网络设备、医疗设备或几乎所有东西的电子控制单元(ECU)。 对于组织来说，工业4.0正在改变产品的制造和分销。随着嵌入式系统中增加更多组件以促进生产力和创新，物联网信息安全和工业4.0网络安全的挑战日益增加。再加上云计算与分析、机器学习和人工智能等技术，工业4.0突然成为一个更加复杂的环境——不仅跨越多设备和系统，还跨越多位置和贡献者。 管理维护物联网和嵌入式系统的信息安全（和功能安全）不能是一个孤立的过程。相反，组织和开发团队应该专注于保护物联网所依赖的软件，因为软件负责每个设备的性能，并促进设备和系统之间的通信。 C和C++对嵌入式系统软件安全的重要性 由于规模和成本限制，嵌入式系统中的软件使用有限的计算机资源进行处理、内存和供给。由于对轻量级软件的需求，像C和C++这样的编程语言在嵌入式系统中占据主导地位，就像它们目前在云中运行大多数服务器的Linux内核一样。虽然C++比C需要更多的计算资源，但更强大的微处理器可用性使C++成为全球数百万嵌入式系统的优选语言。 其他编程语言如Python也用于嵌入式系统，但C和C++是首选的主要语言。还有嵌入式C++（EC++），它是C++语言的一个子集，允许在具有完整C++语言主要功能的同时实现更大的空间和速度效率。当今的微处理器可以内置C++编译器，这让嵌入式系统编码变得更容易。 为嵌入式系统编码与任何其他类型的应用程序都不同。首先，你有资源限制，然后你必须为容错性、实时功能、可靠性设计，而且大部分时间没有停机时间。但更重要的是，代码必须是功能安全和信息安全的。想想嵌入式系统和物联网设备在医疗保健和制药行业，或汽车和航空行业的重要性。不仅这种技术的缺陷会很显眼，如果它们不功能安全信息不安全将成为一个关键问题。 静态分析对嵌入式系统和物联网软件安全的重要性 软件安全漏洞通常在开发过程中产生，因此在编码过程的早期发现它们可以预防未来的信息安全问题。确保源代码没有可能导致漏洞和缺陷的最重要的工具之一是静态分析。也称为静态应用程序安全测试或SAST，静态分析扫描应用程序的源代码，包括嵌入式系统和物联网的源代码，用于工业4.0网络安全应用程序。高度专业化的代码扫描根据使用的相应编程语言和框架查找特定缺陷。静态分析工具——如Perforce Helix QAC和Klocwork——报告符合编码标准的合规性。 静态分析工具使开发和安全团队能够分析数千至上百万行代码。它们寻找代码中的缺陷，并根据规则和政策执行编码标准。最重要的是，它们已经成为软件开发生命周期中不可或缺的一部分，并且是必须每次代码更改或在发布新版本之前定期在源代码上运行的步骤。 随着组织对嵌入式系统和物联网使用的增加，信息安全和功能安全的重要性也在增加，特别是在跨行业的任务关键功能方面。通过静态分析发现的功能安全性和信息安全性缺陷可以防止有缺陷设备的大规模生产，并节省资金和公司的声誉。 嵌入式设备中的安全性是关于减少漏洞数量。严重程度级别不同，高度严重的漏洞代表着更高风险的关键开发。在所有软件中，无论其部署在哪里，都有几种常见的漏洞类型。例如，远程代码执行和跨站脚本漏洞。在嵌入式系统和物联网设备中，大部分漏洞与内存缓冲区溢出、资源泄漏、不当的访问控制、加密问题和代码注入有关。这些是通过静态分析扫描在嵌入式系统中发现的一些最常见的嵌入式安全漏洞。 编码标准对嵌入式系统和工业4.0安全的重要性 正如前面提到的，C和C++在嵌入式系统中占主导地位。多年来，实施工业4.0和物联网的组织已经认识到所有代码中的信息安全性的重要性，特别是对于嵌入式设备中的C和C++，其中损失的成本可能不仅仅是财务方面。建立并不断改进编码标准就是为了帮助提高软件的安全性、可移植性、可靠性和可维护性的水平。静态分析除了在源代码中搜索缺陷和漏洞外，还可以应用于编码标准中规定的规则和建议。这对于需要验证符合行业标准的组织特别有用。嵌入式系统的常见编码标准示例包括MISRA、AUTOSAR和CERT。 行业标准也在解决工业4.0网络安全方面发挥作用：例如，IEC 62443针对自动化和控制系统中技术的开发和运行网络安全要求。该标准定义了一个安全软件开发生命周期，包括设计、实施、认证、验证、缺陷管理以及产品生命周期结束。 安全标准如ISO 27001，是一个信息安全标准，有助于确保制造厂内使用的设备是安全的，通常需要使用编码标准来支持合规性。即使在合规性之外，如上述IEC 62443所要求的，在软件开发期间使用编码指南也被认为是一种良好做法。 为嵌入式系统编码，遵循编码标准并将静态分析作为软件开发生命周期的一部分，将使我们的数字世界更加安全。 如果您想亲身体验为什么成千上万的开发者依赖Perforce静态分析工具，今天就注册免费试用。 ➡️ 注册您的免费试用marketing@polelonk.com

作者： Shawn Prestridge ， IAR 资深现场应用工程师 / 美国 FAE 团队负责人 安全 一直都 是一个非常热门的话题 ， 似乎每 周 都会听到这样的消息：某某公司如何被入侵，数百万用户的数据被泄露。 我们看到这么多的安全问题，部分原因 在于 我们对待安全的方式： 安全 性 通常被认为是事后 考虑 的 问题 ， 是在 开发结束时 才 添加到 设备上的东西。然而，复杂的系统，尤其是嵌入式系统，有一个很大的攻击面，这让攻击者有机可乘，能够在 “ 盔甲 ” 上找到 破绽 。如果你 去 研究大部分黑客试图 入 侵系统的方式，你很快就会发现，在他们的武器库中，他们最喜欢的 手段就 是寻找和利用设备的软件漏洞。 如果软件漏洞是黑客 所利 用的 入口 ，那么我们就需要提高 自己 的代码质量来解决这个问题。但是，这个问题有多 严重 ，我们能做什么来解决它呢？ 代码漏洞容易成为黑客的目标 代码质量糟糕实际上是一个普遍 存在 的问题，而且有相当多的证据支持这样的说法：糟糕的 编码 直接导致了漏洞。虽然许多软件工程专家多年来一直在宣扬这一点，但人们第一次真正意识到这一点也许是在 2001 年，当时红色代码 （ Code Red ） 蠕虫 对 微软的互联网信息服务（ IIS ） 施加了 缓冲区溢出攻击 。 虽然第一个有记载的缓冲区溢出攻击发生在 1988 年，针对的是 Unix 的 finger 指令，但对普通人的影响十分有限，因此没有上头条新闻。 由于红色代码造成了大规模的互联网减速，并在新闻 报道 中铺天盖地 的传播 ，突然间，我们随处都能看到缓冲区溢出攻击的增加 ，看上去 安全研究人员和黑客都在各种系统 （ 包括嵌入式系统 ） 中到处 寻 找这些漏洞。利用缓冲区溢出攻击，黑客可以在受影响的系统上运行他们想要 运行 的任何代码，其目标是使用固定长度的缓冲区来保存文本或数据的一切代码。黑客将缓冲区空间填 充 到最大，然后在合法缓冲区空间的末端写下可执行代码。 然后， 被攻击的系统就会执行缓冲区末端的代码，在许多情况下， 这就可以使 攻击者为所欲为了。 这种类型的攻击之所以 成为紧急事件 ，是因为 当时 检查和执行缓冲区限制的编码并不普遍，但 现在 许多编码标准，如 mitre.org 的 通用缺陷列表 （ Common Weakness Enumeration ， C WE ） ，都建议检查缓冲区 是否存在 这种类型的漏洞。 遗憾 的是，开发 人员 在 编 写代码时普遍都不去 寻 找 这个 问题 ， 通常需要代码分析工具来发现这些问题，这样开发 人员 才会意识到问题的存在并加以修复。像这样一个简单的代码质量改进，就可以消除黑客最常使用的 手段 之一，从而大大提高代码的安全性。因此，检查并执行 代 码中 的 缓冲区长度，这样的编码才是好编码 。 不仅仅是缓冲区溢出 然而，问题不仅仅 在于 缓冲区溢出 ， 这 实际上是一个系统性问题， 草率 的编码 通常会 导致无数的安全漏洞，而黑客可以利用这些漏洞来入侵系统。美国软件工程学会（ SEI ）发表的一篇论文 将这一点 说得非常清楚： “ ...... 质量性能指标为确定高质量产品 、 预测安全 和 保障结果提供了依据。 通用缺陷列表 （ CWE ） 中的许多内容 ，如编程语言结构的不当使用 、 缓冲区溢出 、 验证输入值失败 等 ，都可能与低质量的编码和开发过程有关。提高代码质量是解决一些软件安全问题的必要条件。 ” 该 论文还指出，因为许多安全问题是 由 软件漏洞引起的 ，因此 可以像 处理 更普通的编码漏洞一样 处理安全问题 ，您可以应用传统的质量保证技术来帮助解决至少一 部分 安全问题。 既然正常的软件质量保证过程可以让我们估计系统中剩余的漏洞数量，那么 可以 对安全漏洞 做同 样的 事情 吗？虽然 SEI 没有确认代码质量和安全 性 之间的数学关系，但他们确实指出， 1% 到 5% 的软件漏洞是安全漏洞，并继续指出，他们的证据表明当安全漏洞被追踪时，他们可以准确地估计系统中的代码质量水平。 这最终表明，代码质量是安全的必要条件（但不是充分条件），真正 让“安全 性 可以被视为 开 发结束 时才 添加到 设备 上 的东西” 这一概念不攻自破。相反，安全 性 必须贯穿项目的 DNA ，从设计到编码，一直到生产。 编码标准 可提供 很大的帮助 许多最常见的安全漏洞都在 诸 如 mitre.org 的 通用缺陷列表等 编码标准中得到了解决，并指出了需要关注的其他 方面 ， 如除 零 错误 、数据注入、循环不规则、空指针利 用和 字符串解析错误 。 MISRA C 和 MISRA C++ 还提倡编码的安全性和可靠性，以防止安全漏洞渗入你的代码。虽然这些 编码标准 可以捕捉到许多常 见 的漏洞，但开发人员在编写代码时必须 考虑 得更 长 远：黑客 是 如何利用我刚刚 编 写的代码的？漏洞在哪里？我是否对输入会是什么样子以及输出会如何使用做了假设？一个好的经验法则是，如果你在做假设，那么这些假设应该变成代码，以确保你所期待的东西实际上 就 是你所要得到的。如果你不这样做，那么黑客就会 出手了 。 但是开源软件呢？在设计中使用开源组件的典型论点 依赖 于 “ 已 在使用中被 证明” （ proven in use ） 的论点：这么多人使用它，它一定是好的。 SEI 的 同一 篇论文 对 于这个问题 也有一些阐 述： “ 除了免费之外 ， 开源 所宣扬 的好处之一，就是认为 ‘ 有很多人关注源代码意味着安全问题可以很快被发现，任何人都可以修复漏洞 ， 不需要依赖供应商 ’ 。然而，现实情况是，如果没能有纪律地、一致地把 关注点 放在消除漏洞上，安全漏洞和其他漏洞将出现在代码中。 ” 换句话说， SEI 认为， “ 已 在 使用中被 证明”的论点 毫无意义， 并且在 将质量保证应用 于 开源代码 时 ， 会 让人想起 Anybody 、 Somebody 、 Nobody 和 Everybody 的故事。此外，你的测试并不足以证明代码是令人满意的。 SEI 表示 ，像 CWE 这样的代码质量标准可以发现你代码中的问题，而这些问题 往往 不会在标准测试中被发现，通常只有在黑客利用漏洞时才会被发现。 为了证明这一点， 2020 年 5 月，普 渡大学 的研究人员展示了 在 Linux 、 macOS 、 Windows 和 FreeBSD 中使用的开源 USB 堆栈的 26 个漏洞。 所以， 谈 及 安全 性时 ，代码质量是关键， 并且 所有 代码都很重要。 代码分析工具有助于遵守标准 在解决代码质量问题上，我们可以做些什么来提高 自己 应用程序的安全性呢？简单的答案 就 是使用代码分析工具，这些工具有两种基本类型：静态分析 工具 和运行时（或动态）分析 工具 ，静态分析只查看应用程序的源代码，而运行时分析则是对代码进行检测，寻找空指针和数据注入方法等漏洞。 I AR 可以同时提供这两种工具，包括静态分析工具 I AR C-STAT 和运行时分析工具 I AR C-RUN ，它们 都完全集成在 IAR Embedded Workbench 开发环境中。 高质量的代码分析工具包括对 CWE 、 MISRA 和 CERT C 的检查。 CERT C 是另外一 种 编码标准，旨在促进编码安全。这三个 规则集共同 构成了一个 优质组合， 有助于实现可提升 安全 性 的编码：一些 规则集 与其他规则 集有 重合 之处 ，但也提供了一些独特的功能， 可 以帮助确保你的代码具有高度的安全性。使用这些标准也有助于确保你 拥有最高 的代码质量，甚至可能发现代码中的一些潜在漏洞。 高质量的 代码就是 安全的代码 保证代码质量才能确保代码安全。不要把代码质量的责任推给别人，因为别人的漏洞很可能 给 你 带来 安全 性方面的 噩梦。但希望还是有的，因为代码分析工具可以 帮助 你在漏洞找麻烦之前迅速发现问题。通往安全的道路总是要经过代码质量这一关口。 参考资料 https://www.caida.org/research/security/code-red/ https://malware.wikia.org/wiki/Buffer_overflow https://cwe.mitre.org/data/definitions/121.html https://resources.sei.cmu.edu/asset_files/TechnicalNote/2014_004_001_428597.pdf https://www.techradar.com/news/usb-systems-may-have-some-serious-security-flaws-especially-on-linux

BARR-C是Barr集团的编码标准， 旨在减少嵌入式软件中的错误，并引入风格指南以提高可维护性和可移植性。 在这里，我们解释了什么是 Barr-C ，开发人员如何使用 BARR-C : 1018 检测用 C 编写的固件中的错误，以及如何将其与 MISRA 的指南相结合。 什么是 BARR -C ？ B ARR -C 是由 BarrGroup 开发的 嵌入式C编码标准 ，专注于减少 软件 中的错误数量，同时提高嵌入式软件的可维护性和可移植性。 BARR-C : 2018 指南分为两大类： 1. 处理细分语言的方法，例如避免特定关键字（例如“ register ”或“ continue ”）和使用类似于宏的函数。 2. 关于 编程风格 的内容 （例如，缩进和命名约定）。 第一类中的一些规则被标记为 “ 零 bug ... 周期 ” 。遵循这些规则将有助于首先防止错误。 为什么 BARR -C 很重要？ 开发 嵌入式软件 可能具有挑战性，即使使用正确的工具来识别缺陷和合 规 性问题也是如此。 BARR-C ： 2018 主要旨在最大限度地减少编码错误。因此， BARR-C ： 2018 可以被视为适用于各种项目的 C 语言子集的第一步。 对于未使用编码标准和静态分析的情况，采用 BARR-C:2018 是一项重大改进。 如何实现 BARR -C 合 规 性？ 为了遵守 BARR-C ： 2018 ，必须执行所有准则。 有几种方法可以检测不合 规 的代码 ： 例如，非正式代码审查或自动扫描。每条规则都描述了所建议的执行方法。标准中的许多规则都可以使用静态分析工具（如 HelixQAC） 自动检查。 BARR -C 与 MISRA 有何关系？ 设计安全关键型系统的开发人员知道要严格遵守 MISRAC ： 2012 指南。符合 MISRAC ： 2012 标准可确保嵌入式代码安全可靠。 BARR-C ： 2018 并不是为了与 MISRAC ： 2012 竞争而设计的 ; 它们实际上是兼容和互补的。例如， 使用 MISRA C:2012 的项目可以使用 BARR-C:2018 的编程风格部分来满足 MISRA C 关于采用和实施一致编码风格的建议。 同样，关键项目最初可以努力实现对 B ARR -C 的遵守，然后顺利过渡到 MISRAC 的合 规 性。 为什么使用 Helix QAC 实现 Barr-C 合 规 性 Helix QAC 可轻松遵守编码标准和准则，包括 MISRA 和 BARR -C 。 亲自了解 Helix QAC 如何帮助您遵守 B ARR -C 和其他功能安全标准：欢迎咨询北汇信息。