dynamic-allocation - 安全关键项目中动态分配的替代方法(C)

Question

安全关键项目不建议任何动态分配或释放分配的内存。仅在程序执行的详细说明/初始化阶段，才允许这样做。

我知道你们中的大多数人都将争执起来以仅应执行所有静态分配或在代码中说明动态分配不会损害整个程序的理由来实现SW，等等，但是，这个问题是否有其他选择？有什么方法或示例可以在程序初始化/精化期间分配一些(堆)内存，并从那里分配/取消分配内存？如果我们真的想要在(安全关键)项目中进行动态分配，或者对这个问题有任何解决方案/替代方案？

Answer 1

此类问题最经常由开发人员提出，他们希望能够在与安全相关的系统中使用动态内存分配而没有“过分”的限制-这似乎常常意味着，他们并不能阻止他们按照自己选择的数量动态分配内存，当他们选择时，以及(可能)在选择时释放该内存。

我将首先解决该问题(动态内存分配是否可以不受限制地用于关键系统中？)。然后，我将回到涉及接受如何使用(何时或是否)动态内存分配的一些限制的选项。

在“安全关键项目”中，这种事情通常是不可能的。与安全相关的系统通常具有与缓解或消除特定危害有关的强制性要求。未能充分减轻或消除特定危害(即满足要求)会导致伤害-例如人员死亡或伤害。在这样的系统中，通常有必要在某种程度的严格性上确定适当并可靠地减轻或消除了危险。其结果通常是与确定性相关的一组要求-通过适当的分析确定系统以指定方式完成操作的能力-其中严格规定了行为和时间等属性。

如果不加限制地使用动态内存分配，则很难确定系统的各个部分是否按要求运行。问题类型包括；

未分配内存的碎片。 即使提供了N个内存字节，也无法确保分配N个连续字节的内存请求成功。如果以前有任意顺序的多个分配和释放，则尤其如此-即使有N个字节的内存可用，它们也可能不在连续的数据包中。

足够。 通常很难保证必须成功的关键内存分配确实可以成功。

适当的发行版。 很难阻止在仍然需要的内存被释放(导致访问已释放的内存)或确保实际上不再需要的内存被释放(例如，防止内存泄漏)。

及时性。 尝试减轻上述问题意味着分配或解除分配的时间是可变的，不可预测的，并且可能没有上限。处理这些问题的方法的示例包括碎片整理(处理碎片问题)或垃圾回收(处理充足性和/或适当释放的问题)。这些过程需要时间和其他系统资源。如果尝试分配时完成了分配，分配内存的时间将变得不可预测。如果完成释放内存操作，释放内存的时间将变得无法预测。如果它们在其他时间执行，则其他(可能很关键)代码的行为可能变得不可预测(例如，对于应用程序来说，世界实际上冻结了)。

所有这些因素，甚至更多，意味着在确定系统时序或资源使用率的要求内，不受限制的动态内存分配不能很好地工作。从本质上讲，系统要求需要施加一些限制，并且要根据系统来实现。

如果可以接受对动态内存分配的限制，则可以选择。通常，这些技术在策略约束和技术解决方案方面都需要支持，以鼓励(最好是在高关键性系统中执行)这些策略。政策执行可能是技术性的(例如自动和手动设计和代码审查，量身定制的开发环境，合规性测试等)或组织性的(例如解雇愿意围绕关键政策工作的开发人员)。

技术示例包括；

完全没有动态分配。 ，即仅静态分配。

仅在系统初始化期间使用动态内存分配。 这需要预先确定需要分配的最大内存量。如果内存分配失败，则将其视为任何POST(开机自检)失败。

分配内存，但永远不要释放它。 这倾向于避免出现碎片问题，但可能使确定系统需要多少内存的上限更加困难。

自定义分配。该系统(或应用程序)显式地管理动态存储器分配，而不是使用通用库函数(例如，与所选择的编程语言相关联的那些库函数)。这通常意味着引入自定义分配器，并禁止(或禁用)通用库函数用于动态内存管理。必须根据特定系统的需求对定制分配器进行显式设计。

内存管理中的装箱。 这是一种特殊类型的自定义分配，其中应用程序分配一个内存池，函数从池中请求固定量(或固定量的倍数)。由于该池是由应用程序固定的，因此该应用程序可以监视池中正在使用的内存量，并在内存耗尽时采取措施释放内存。池中的分配和取消分配也可以预测地执行(因为正在管理与动态内存分配有关的一些更一般的问题)。关键系统可能具有多个池，每个池仅供特定功能集专用。

分区。 显式阻止非关键功能访问已建立供关键功能使用的内存池。这可以确保关键功能可以访问所需的内存，还可以帮助确保低关键功能的故障不会触发高关键功能的故障。分区可以在应用程序中执行，也可以在(经过适当认证的)主机操作系统中执行，也可以在两者之间执行……。取决于系统的需求。

这些方法中的一些可用于相互支持。