Undefined behaviour

[Daniel Páscoa]

If one searches within SRSs or ICDs for 'undefined behaviour' one will find specifications/functions on which descriptions mention conditions that will lead to 'undefined behaviour', e.g.:

...

spec:/rtems/clock/if/get-boot-time

...

boot_time is the pointer to a struct timespec object. The time elapsed since the Unix epoch at some time point during system initialization call will be stored in this object. Calling the directive with a pointer equal to NULL is undefined behaviour.".

One created specific tests to further access the eventual impacts, for instance in the clock-related functions below:

spec:/rtems/clock/if/get-boot-time

spec:/rtems/clock/if/get-boot-time-bintime

spec:/rtems/clock/if/get-boot-time-timeval

spec:/rtems/clock/if/get-monotonic

spec:/rtems/clock/if/get-monotonic-bintime

spec:/rtems/clock/if/get-monotonic-coarse

spec:/rtems/clock/if/get-monotonic-coarse-bintime

spec:/rtems/clock/if/get-monotonic-coarse-timeval

spec:/rtems/clock/if/get-monotonic-timeval

spec:/rtems/clock/if/get-realtime

spec:/rtems/clock/if/get-realtime-bintime

spec:/rtems/clock/if/get-realtime-coarse

spec:/rtems/clock/if/get-realtime-coarse-bintime

spec:/rtems/clock/if/get-realtime-coarse-timeval

spec:/rtems/clock/if/get-realtime-timeval

The outcome was:

There is no internal check for a NULL pointer in these functions, so when called with a null pointer argument there is unwanted behaviour for both the GR712rc and GR740; an attempt to access memory location 0.

For the GR712rc board this memory position is not mapped and causes a trap to be raised (this trap handler leads to unpredictable results, the workflow of the program is not recoverable). For the GR740 board the actual memory position is either read or written (the previous value being overridden with unpredictable results).

So, even if somehow this shall also be a user responsibility, shouldn’t one adopt a safe approach to this and add input checking for these functions?

Additional Notes:

This ticket was raised as an outcome of the Independent SW Verification and Validation (ISVV) for ESA-promoted RTEMS SMP Qualification Data Packs (​https://rtems-qual.io.esa.int). The original ISVV reference for this issue is RTEMS-SMP-REQ-VER-008 and RTEMS-SMP-VAL-005.

[Sebastian Huber]

This was discussed on the RTEMS mailing list some time ago:

​https://lists.rtems.org/pipermail/devel/2021-November/069991.html

Quite frankly, someone passing a NULL pointer to functions like void rtems_clock_get_monotonic_bintime(struct bintime *time_point) will also use the NULL pointer later. The next release of the pre-qualified RTEMS will probably contain the clock_get() function which performs these NULL pointer checks.