[RTEMS Project] #4874: Undefined behaviour

[RTEMS trac]

#4874: Undefined behaviour
----------------------------+--------------------
  Reporter:  Daniel Páscoa  |      Owner:  (none)
      Type:  defect         |     Status:  new
  Priority:  normal         |  Milestone:
 Component:  admin          |    Version:
  Severity:  normal         |   Keywords:
Blocked By:                 |   Blocking:
----------------------------+--------------------
 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.

--
Ticket URL: <http://devel.rtems.org/ticket/4874>
RTEMS Project <http://www.rtems.org/>
RTEMS Project