Notice: We have migrated to GitLab launching 2024-05-01 see here: https://gitlab.rtems.org/

#4874 closed defect (wontfix)

Undefined behaviour

Reported by: Daniel Páscoa Owned by:
Priority: normal Milestone: 6.1
Component: rtems Version: 6
Severity: normal Keywords: qualification
Cc: Blocked By:
Blocking:

Description

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.

Change History (2)

comment:1 Changed on 03/09/23 at 12:54:46 by Sebastian Huber

Resolution: wontfix
Status: newclosed

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.

comment:2 Changed on 03/09/23 at 12:55:23 by Sebastian Huber

Component: adminrtems
Keywords: qualification added
Milestone: 6.1
Version: 6
Note: See TracTickets for help on using tickets.