May 02, 2019
07:38 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 02, 2019
07:38 AM
Hello Guys,
i am working as SW-Engineer at an OEM since long time,
Inside MCAL Layer I detected a robustness issue, the Fls_lMainRead() inside Fls_17_Dmu.c uses a do {...} while(count>0) loop to copy data from NV to RAM buffer.
if the size (presented in a global struct) is Zero, the copy will overwrite the whole RAM until stopped by exception. Reading 'Zero' Bytes may be wrong, but at the end the value is set to zero,
so a second (unintended) call of the function also leads to this behaviour.
Changing the loop into a while(count>0) { ...} would solve this issue.
If it's my code i would do such immediate, but I received it from my tTier1 Ecu supplier, he received it from his Autosar Stack supplier, that company finally received the code from Infineon.
Teh code has a 'do not modify' attribute, so lawyers and business staff say. do not modify, you will loose the Guarantees. The only allowed to do is Infineon.
I want to have this 'bug' changed before my car is going into production. For that i ask here how to contact MCAL developers/responsibles to supply them the details here.
Going the full chain backwards i am quite shure will be slower or even blocked.
Target CPU is TC39x, using AUTOSAR 4.2 and up.
If ALL is implemented correct, this will not occur, but for ASIL relevant SW i expect also a good kind of ROBUSTNESS against (maybe seldom) parameter faults.
Here the reduced code:
uint32 cnt; // shall be set by other function to a value > 0
uint8 *src, *dst;
void CopyBuffer(void)
{
do
{
*dst++ = *src++;
cnt--;
} while (cnt>0);
}
i could use sint32 cnt to reduce overwriting to ONE byte,
or move the while() up to not copy any byte at all.
i am working as SW-Engineer at an OEM since long time,
Inside MCAL Layer I detected a robustness issue, the Fls_lMainRead() inside Fls_17_Dmu.c uses a do {...} while(count>0) loop to copy data from NV to RAM buffer.
if the size (presented in a global struct) is Zero, the copy will overwrite the whole RAM until stopped by exception. Reading 'Zero' Bytes may be wrong, but at the end the value is set to zero,
so a second (unintended) call of the function also leads to this behaviour.
Changing the loop into a while(count>0) { ...} would solve this issue.
If it's my code i would do such immediate, but I received it from my tTier1 Ecu supplier, he received it from his Autosar Stack supplier, that company finally received the code from Infineon.
Teh code has a 'do not modify' attribute, so lawyers and business staff say. do not modify, you will loose the Guarantees. The only allowed to do is Infineon.
I want to have this 'bug' changed before my car is going into production. For that i ask here how to contact MCAL developers/responsibles to supply them the details here.
Going the full chain backwards i am quite shure will be slower or even blocked.
Target CPU is TC39x, using AUTOSAR 4.2 and up.
If ALL is implemented correct, this will not occur, but for ASIL relevant SW i expect also a good kind of ROBUSTNESS against (maybe seldom) parameter faults.
Here the reduced code:
uint32 cnt; // shall be set by other function to a value > 0
uint8 *src, *dst;
void CopyBuffer(void)
{
do
{
*dst++ = *src++;
cnt--;
} while (cnt>0);
}
i could use sint32 cnt to reduce overwriting to ONE byte,
or move the while() up to not copy any byte at all.
- Tags:
- IFX
- mcal
- robustness
1 Reply
May 09, 2019
01:29 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 09, 2019
01:29 AM
I forwarded your hint to the responsible department for check and improvement.