We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Here is a link to a number of suggestions I have compiled for hardening of firmware.
I'm pretty sure that a lot can be said about the list, so please post coding tips or links to pages with good information of software hardening.
iapetus.neab.net/.../hardening.html
that is possible, but will require extra circuitry and logic which equals extra cost. these are usually checks that are better done in software, which is also easier to change in face of changing requirements.
It isn't uncommon with ECC to protect internal memory. Most flash memory has ECC, and some RAM has it. But think about all the processors with external memory interfaces without ECC. Small microcontrollers normally has all memory internally and no MMU. Most processors with MMU requires external memory expansions, and most of them do not have a ECC-protected memory interface.
Life can be fun if you happen to get your equipment installed close to a contactor handling hundreds of ampere. With limited distances to other unknown installations, do don't need a war to have industrial equipment suffer very rough EMI abuse. Think what would happen if your equipment is controlling that big contactor, and the contactor has a failed spark suppressor.
Some certifications may require the equipment to be fully operating when hit by ESD or strong electrical or magnetical fields. Some certifications accepts a controlled reboot. Some certifications requires the rebooted unit to return to the previous state.
To assume (ass-u-me) that the hardware can handle all cases can be a bit premature. If you fail the certification or a pre-compliance test, you will have to redesign the hardware and/or firmware. But a redesign takes a lot of time, and a new sets of tests before a new certification run.
The important thing to remember is that defensive programming does not take extra time. On the contrary. It normally speeds up the debugging process by catching problems early, and sometimes even pinpointing the root cause.
yes yes yes yes and once more - yes.
Doesn't the realiability of systems is highly depending on the defensive codes had been written everywhere? Will systems be failed if some programmers forgot to put these code somewhere?
At least, compiler team should guarantee that the stack is put into ECC memory. Then programmers can only take care about static local variables and global variables. Otherwise, programmers should test any variables one by one everywhere. Eventually, you will not able to find people who want to maintain the source code.