Memory Management for Safety-Critical Systems

Purpose

Ensure deterministic and safe memory usage: static allocation, pools, stack sizing, MPU usage, and corruption detection for medical device firmware.

When to Apply

• •Any code handling buffers, dynamic data, ISR/RTOS stacks.
• •Introducing third-party libs with allocations; configuring MPU/MMU.

Requirements (testable)

1. •Static Allocation Preference: Use static or stack allocation for safety-critical paths; avoid heap unless bounded and justified. Rationale: determinism.
2. •Memory Pools: If dynamic behavior needed, use fixed-size pools with bounded allocation time and failure handling. Rationale: predictability.
3. •Stack Analysis: Analyze stack usage per task/ISR with margin; enable overflow detection/guards. Rationale: prevent corruption.
4. •MPU/MMU Protections: Configure MPU/MMU to protect code, read-only data, and segregate critical data regions; no-exec where possible. Rationale: containment.
5. •Bounds Checking: Enforce bounds on all buffer operations; avoid unsafe functions; use length-checked variants. Rationale: prevent overflows.
6. •Initialization: Zero-init all memory before use; avoid reading uninitialized data. Rationale: determinism and safety.
7. •Corruption Detection: Use canaries/guards for critical buffers; CRC on critical stored data. Rationale: detect latent faults.

Recommended Practices

• •Centralize alloc/free wrappers; forbid raw malloc/free in safety modules.
• •Use linker scripts to place critical data separately and guard with MPU.
• •Periodically scrub/clear sensitive data (keys, credentials) per security needs.
• •Add lightweight heap diagnostics if heap is permitted outside safety path.

Patterns

Fixed pool allocator:

// REQ-MEM-POOL-01; TEST-MEM-03
typedef struct { bool used; uint8_t buf[64]; } blk_t;
static blk_t pool[8];

void *pool_alloc(void) {
    for (size_t i = 0; i < 8; i++) {
        if (!pool[i].used) { pool[i].used = true; return pool[i].buf; }
    }
    return NULL; // handle failure
}

Bounds-checked copy:

// REQ-MEM-BOUND-02; TEST-MEM-05
bool copy_payload(uint8_t *dst, size_t dst_len, const uint8_t *src, size_t src_len) {
    if (src_len > dst_len) return false;
    memcpy(dst, src, src_len);
    return true;
}

Stack guard (RTOS example):

// REQ-MEM-STACK-04; TEST-MEM-07
configCHECK_FOR_STACK_OVERFLOW == 2

Anti-Patterns (risks)

• •Unbounded malloc/free in control loop -> risk: fragmentation, failure.
• •Ignoring stack sizing -> risk: silent stack overflow corrupting state.
• •Shared buffers without length checks -> risk: overflow and data corruption.
• •Disabling MPU or running everything RWX -> risk: corruption/execution of data.

Verification Checklist

• • Safety paths use static or pooled allocation; no raw heap in safety code.
• • Pools bounded; allocation failure handled deterministically.
• • Stack sizes analyzed/measured; overflow detection enabled.
• • MPU/MMU protections configured; code RO, data segregated, NX where available.
• • All buffer ops bounds-checked; unsafe libc calls avoided.
• • Memory zero-initialized; no uninitialized reads.
• • Corruption detection (canaries/CRC) in place for critical data/buffers.

Traceability

• •Use REQ-MEM-###; link to tests and to MPU/linker configuration artifacts.

References

• •MISRA C/C++ rules on dynamic memory.
• •IEC 62304 implementation discipline for Class B/C determinism.
• •CWE-119/120/787 (informative) for buffer overflows.

Changelog

• •1.0.0 (2026-01-04): Initial memory management skill with pools, MPU, and bounds checking.

Audit History

• •2026-01-04: Audit performed. Verified:
  • •MISRA C/C++ dynamic memory rules correctly referenced
  • •CWE references (CWE-119/120/787) accurate for buffer overflow classifications
  • •Memory pool patterns technically sound