> How much does it help to protect some variables, isn't it needed > to also protect stack, heap and so on? Yes, indeed it is also important to protect stack, heap, text segment, and so on .. > If you do not trust the memory, how can you trust the code > executed from memory? Do you have integrity checks running? Yes! Also, continuous RAM testing is necessary, too .. not just by the hardware (ECC), but by a 'safeguard' process that does this in the background while your main, safety-critical application, is running. > I remember a case where a background flash memory integrity check > caused crashs in rare race conditions due to some resource > conflict... It can definitely occur, and this is one reason why testing, code validation, code coverage, and so on is so valuable and important .. > When not trusting RAM, ECC seems the natural solution for that. > If not trusting CPU etc, variable duplication seems not to fully > solve the issues, I guess. Unless you are, also, continuously testing the CPU as well! > Is variable duplication reasonable safer than simply executing > the complete functional unit/code twice in different memory > places? It is, if done properly in the context of a wider, safety-checking system. > Is something like this used in some projects? http://ercim-news.ercim.eu/content/view/450/664/ > Maybe with optimized and non-optimized code (to have different > memory layout / register usage)? > Yes! > I guess it is impossible to know how many failures were caused > due to memory bit flips and how many caused by programming bugs > (and how severe they were). Test, test, test. And, even when the application is deployed, continue testing in the background .. -- ; Thales Austria GmbH Jay Vaughan, Scheydgasse 41 Software Developer 1210 Vienna AUSTRIA ============================================--------------------
