On Thu, Sep 17, 2020 at 1:07 PM Gedare Bloom <ged...@rtems.org> wrote: > > On Wed, Sep 16, 2020 at 7:15 PM Chris Johns <chr...@rtems.org> wrote: > > > > On 17/9/20 9:50 am, Joel Sherrill wrote: > > > On Wed, Sep 16, 2020, 6:43 PM Chris Johns <chr...@rtems.org > > > <mailto:chr...@rtems.org>> wrote: > > > > > > On 16/9/20 11:42 pm, Joel Sherrill wrote: > > > > snprintf() is a safe method and I strongly disagree with the blanket > > > replacement > > > > of many safe methods with memcpy(). > > > > > > > > Based on what POSIX profiles snprintf() is included in and the > > > safety and > > > > security requirements those profiles are designed to meet, > > > snprintf() is > > > > supported by RTOSes that can meet DO-178 Level A. > > > > > > > > If the POSIX method being reviewed is in the FACE Safety Base or > > > Safety > > > Extended > > > > profile, then it is OK to use and has been used in flight qualified > > > > applications. And that is a general statement meaning running on > > > any of a > > > > variety of RTOSes. If the usage is incorrect, let's fix it but > > > blanket > > > changing > > > > them is wrong. > > > > > > This is really good information, thank you. > > > > > > No problem. That doesn't mean you can't do something stupid with it but > > > sprintf() would be discouraged and isn't in those profiles as I recall. > > > > > > I see EPICS is reporting similar issues at the moment and looking to > > > work around > > > them. > > > > > > And no one is questioning why? What's the risk? > > > > > > Is there a history of why this has been added to compilers as a > > > warning? > > > > > > I have no idea..snprintf has a length and avoids overwrites. > > > > > > I would suggest that we find a safety or security coding standard that > > > warns > > > about whatever methods this catches. > > > > > > Personally replacing snprintf and strong operations with memmove is > > > semantically > > > wrong. > > > > I found this.... > > > > https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/ > > > > The "Handling Truncation When It Occurs" section in the blog post is > > something > > worth considering. It seems the return value of call should be checked. That > > seems reasonable. > > > > Nice. *printf also suffer from other security-relevant vulnerabilities > such as the format-string attack: > https://owasp.org/www-community/attacks/Format_string_attack > > This means replacing their use with alternatives can be generally more secure. >
Also, if the format string is unnecessary, then using *printf is adding a lot of overhead vs a mem*() call. > > Chris > > _______________________________________________ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel