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.


_______________________________________________
bugs mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/bugs

Reply via email to