This article is now located here: https://experts.barrgroup.com/articles/firmware-forensics-best-practices-embedded-software-source-code-discovery
Tags: copyright, embedded, firmware, patents, safety, security
Tuesday, September 27th, 2011 by Michael Barr
This article is now located here: https://experts.barrgroup.com/articles/firmware-forensics-best-practices-embedded-software-source-code-discovery
Tags: copyright, embedded, firmware, patents, safety, security
This entry was posted on Tuesday, September 27th, 2011 at 10:32 am and is filed under Firmware Bugs. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.
Michael Barr is an expert on the design of software-powered medical devices and other embedded computer systems. (full bio)
Embedded Gurus - Experts on Embedded Software
website by Accent Interactive
Good article. Coming from an avionics background this stuff sounds like common sense. Maybe the wider software community should consider some of the guidance in e.g. DO-178B? I’d not advocate a slavish adherence to it for non-aerospace code as the costs will kill you, but it offers good food for thought…
>>”NASA failed to find a firmware cause of unintended acceleration—but their review also fails to rule out firmware causes entirely”
Of course!
Tweaking a quote from Edsger W. Dijkstra,
“Code review (Program testing) can be used to show the presence of bugs, but never to show their absence”
Building the source can only prove the source is the correct source. It can not prove that it is not the correct source. We use a compiler which apparently links object together in the order they are found in the directory or something as it has been shown the using the same source and building multiple times does not produce outputs which compare the same, the modules are rearranged. To eliminate this we have had to ensure we do a clean and complete rebuild when we make release versions.
Agreed.