Modify code that reads or writes memory addresses in external messages to use wapper

[skliper]

In the current version, some external interface (command/telemetry) messages contain direct CPU memory addresses.

This can be very bad for several reasons:

• Memory addresses can be a different size on different CPUs
• Since memory addresses are likely to change from run to run (even in the same build) it makes it difficult to script tests
• The receiver has no way to validate it (other than NULL).
• If the address value ever gets corrupted or an invalid value is used, the consequence is usually dire (a crash).

Ultimately the use of direct memory addresses in messages should be avoided.

As a first step to this, this ticket will modify those locations that a memory address is read or written from an external message to use a wrapper function.

This ticket won't change any functionality in itself, but it will provide a path going forward such that the wrapper function can be modified to convert the address to/from a safe, verifiable, architecture independent value rather than using the address directly.

[skliper]

Imported from trac issue 18. Created by jphickey on 2015-01-06T13:04:43, last modified: 2019-03-05T14:57:55

[skliper]

Trac comment by jphickey on 2015-01-15 17:19:40:

Pushed branch "trac-18-mem_address_wrapper" as a first step toward the goal of safe memory addresses.

This change simply replaces the direct get/set of memory addresses in a message with a macro to get/set the value. The initial implementation of the macro is a straight copy so it does not change functionality at all.

The macro provides a hook so that a more complete fix can be done when the rest of the prerequisites are in place. All existing code should be changed to use the macro so it can take advantage of the fix when it becomes available in a future update.

[skliper]

Trac comment by glimes on 2015-02-11 11:54:52:

See [changeset:fdc5514]

[skliper]

Trac comment by jphickey on 2015-04-06 11:37:01:

This is ready for review/merge

[skliper]

Trac comment by sstrege on 2015-04-06 14:27:34:

Concur with changes/merge

[skliper]

Trac comment by jwilmot on 2015-04-07 08:50:51:

Concur.

[skliper]

Trac comment by acudmore on 2015-04-07 09:14:49:

Concur but I'm not sure we will want to migrate away from having the absolute addresses in some of the telemetry messages. ( I can see how we might want to move away from using an address as a memory pool handle )

Our flight ops/maintenance teams are used to micro-managing the memory map for the CPU. In the past they have patched code, data and even manipulated stacks.
The absolute addresses in ES telemetry are used to inform the ground where the applications are loaded in memory. This alone was a big step for them, because they were used to knowing the location of every task from a static memory map.

Having said that.. I think the macro could have some benefit in the future because we never know what the address or memory maps will look like on future systems. I'm pretty sure the addresses that ES reports are meaningless in Linux for example, since the addresses are virtual and not absolute.

[skliper]

Trac comment by glimes on 2015-04-07 12:58:01:

Tested changeset [changeset:fdc55145] as part of the ic-2015-03-10 merge.

Side note: reporting out virtual addresses is correct in the Linux case as long as the commands used to manipulate the memory content also use virtual addresses.

[skliper]

Trac comment by glimes on 2015-04-13 15:31:04:

Part of integration candidate 2015-03-10,
committed to cFS CFE Development branch on 2015-04-10
as part of merge [changeset:7d6f6d0].

[skliper]

Trac comment by glimes on 2016-02-25 10:17:32:

these will be fixed in CFE 6.5

[skliper]

Trac comment by jhageman on 2019-03-05 14:57:55:

Milestone renamed