繁体   English   中英

CPU 上 IEC 61508 软件元素的独立性,不带存储器保护单元

[英]Independence of software elements for IEC 61508 on CPU without memory protection unit

是否有可能通过 IEC 61508 第 3 部分附录 F 来证明软件元素的独立性,以便安全相关组件的评级为 SIL 2,而非安全组件(例如 UI、通信)可以不评级,以及仍然有一个被评为 SIL 2 的整体结果?

当安全和非安全元素都在单个处理器上运行,并且处理器没有实现任何形式的硬件内存保护时,我特别感兴趣的是对此的看法。 可以做各种各样的事情来确保软件元素不受干扰,例如确保数据完整性,数据传递受到严格控制和验证,任务调度是确定性的(非安全任务保证终止),以及很快。

严格应用这些技术就足够了吗?

这是一个没有明确答案的问题。 答案仅仅是基于意见或取决于特定条件。

如果您有一家公司/组织将进行评估或认证,您应该询问他们(编辑以澄清:)您的方法是否可行。 据我了解安全关键设备的开发标准,您必须记录您考虑了所有可能的风险以及您如何检测或防止可能的故障。

在要认证符合类似标准的项目中,我们将所有与安全相关的数据和代码放入特定的内存部分,并通过在离开安全相关功能后计算 CRC 并检查 CRC 来“锁定”安全相关数据部分在再次进入之前。

此外,我们仅通过检查返回地址来检查“锁定”数据的函数是否是从安全相关代码部分调用的。 安全相关数据的任何意外修改都将被检测到,设备将进入安全状态。

在我们的案例中,这种方法足以说服负责检查我们软件开发的人员。

编辑(回答评论)

当然,我们确信该解决方案足以在受影响的设备中实现所描述的目的。

这种机制只是设备安全概念的一部分。

此处描述的CRC机制用于保护 RAM中的安全相关数据免受非安全功能的不必要修改,以确保安全相关功能与非安全功能的独立性 (这与保护闪存中的二进制程序不被修改无关。当然,我们也使用 ECC 闪存和 CRC 来做到这一点。)

另一个编辑:我们还定期检查与安全相关的外设寄存器没有被意外修改。

我们在硬件和软件方面还有很多其他安全措施,但这些与如何证明没有 MPU 的软件部分的独立性的问题无关。

使用此处描述的技术的设备符合不同的标准,安全级别约为 SIL 1 和 SIL 2 之间。

当然,每个用户都必须检查此解决方案对于特定设备是否足够。

如果 MCU 中存在任何与安全相关的固件,则其所有软件都与安全相关。 时期。

常识表明,代码中任何地方的任何错误都可能导致代码失控、堆栈溢出、越界访问、虚假中断等。 更不用说与安全和非安全相关部件之间的接口相关的错误。

要在一个系统中争论独立性,您会将软件的某些部分视为不那么重要,您需要像多个内核在不同的内存区域中执行代码之类的东西,而不会以任何方式相互影响。 这反过来又会是一个奇怪且不必要的复杂设计。

通常的方法是为代码的每个部分设置相同的质量标准。 这意味着如果您需要在某个未经验证的堆栈或第 3 方库中运行一些非关键代码,您可能应该考虑将其移至单独的物理芯片。 保持与安全相关的部件尽可能小而简单。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM