CFE_ES_SEND_MEM_POOL_STATS_CC Issues

[dmknutsen]

Describe the bug
There are multiple issues with the CFE_ES_SEND_MEM_POOL_STATS_CC command:

1. The command/function(s) used are fundamentally flawed in that a user can send a seemingly benign command that can result in a segmentation fault if one of the command parameters is incorrect. For example, if the PoolHandle parameter is set to zero a segmentation fault will result (pretty much any value below xFFFFFE28 faults on my machine). This occurs when handle is validated via the CFE_ES_ValidateHandle function. Should consider modifying the CFE_ES_ValidateHandle function + updating the unit test to test command on boundary/extreme conditions.
2. On a 64-bit machine if the PoolHandle parameter is set to a valid value the function will fail. This is because CFE_PSP_MemValidateRange – which is called via the CFE_ES_ValidateHandle function as part of the validation process, limits the max memory range of the handle to xFFFFFFFE.
3. On a 64-bit machine - compiler added padding will be applied to the command. The order of variable declaration should ideally be descending in size to avoid future conflicts.

Expected behavior
Command works nominally and is vetted via combination of unit/functional tests.

System observed on:
Oracle VM VirtualBox
OS: ubuntu-19.10
Versions: cFE 6.7.13.0, OSAL 5.0.12.0, PSP 1.4.9.0

Reporter Info
Dan Knutsen
NASA/Goddard

[skliper]

@jphickey want to take this one?

[jphickey]

Sure, sounds good to me. My proposal (if others agree) would be to apply the same paradigm I'm using for CFE_ES_AppID -- define a type (NOT an address) which abstractly identifies a memory pool, e.g. CFE_ES_PoolID_t ... then this gets put into CMD/TLM packets to identify the memory pool. The CFE_ES then looks up this value to get the REAL memory address of the pool.

[jphickey]

Actually, since we already have a CFE_ES_MemHandle_t type -- then no new type is needed -- can just use this, but make it an abstract ID rather than a memory address.

[skliper]

Perfect. Hopefully we don't have any other memory addresses in commands...