RTEMS | Draft: cpukit/age_verify: Add optional state-mandated age verification API (!1137)

[Wayne Thornton (@wmthornton-dev)]

Wayne Thornton commented on a discussion on cpukit/libage/age_verify.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1137#note_145722

 > +    if (_Age_Locked) return RTEMS_NOT_CONFIGURED;
 > +
 > +    _Age_Data.age_bracket = (uint32_t)bracket;
 > +    _Age_Locked = true;
 > +    return RTEMS_SUCCESSFUL;
 > +}
 > +
 > +uint8_t rtems_age_get_signal(void) {
 > +    // Verify the integrity of the age data before returning it. 
 > +    // If the guard values have been tampered with, this likely 
 > +    // indicates memory corruption or a tampering attempts.
 > +    if (_Age_Data.lower_guard != AGE_GUARD_PATTERN || 
 > +        _Age_Data.upper_guard != AGE_GUARD_PATTERN) {
 > +        
 > +        rtems_fatal(RTEMS_FATAL_SOURCE_STACK_CHECKER, 0xBAD1D);
 > +    }

You are absolutely right.

The reason I coded it as I did here comes down to the specific compliance threat model driving this API. The upcoming state mandates require the age signal to be immutable and tamper-evident to prevent circumvention by third-party applications.

Because a rogue pointer from a third-party app could maliciously (or accidentally) overwrite this stored bracket without the system noticing, it could potentially put the OEM out of compliance. This was my attempt at a lightweight compromise to provide some tamper-evidence without requiring full hardware memory protection.

That being said, if this defensive pattern violates core design principles in a way that is entirely unnacceptable, I am completely happy to strip the canaries and the rtems_fatal check out entirely. We can just leave the standard uint32_t variable in memory and let the downstream OEM assume the risk of memory corruption.

Alternatively, we could wrap the canary check in #if defined(RTEMS_DEBUG) so it is only evaluated during development.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1137#note_145722
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260316/319e4908/attachment-0001.htm>