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
"...I was just "donating" a question for Silly Sausage to ask..."
Wot???
A trap just for li'le ol' me, Per? How thoughtful :)
Actually, I'm still reading through some of the information on that page (when my day job allows).
I stumbled across a very interesting data sheet that I first saw printed in (I think) ETI about 25 years ago. It's for a brilliantly advanced memory device:
www.ganssle.com/.../wom2.pdf
Don't forget page one too. Yes, it would probably have quite good figures for bit errors when used in rough environments. But you may not make use of all bits, to have some margin depending on temperature. Just a tip: Solder the chip instead of using a socket :)
"about 25 years ago" - I wonder what the average age is for the regulars on this forum.
Per; I have no idea about average ages but I'll bet that Erik and myself severely skew the curve age wise. Still I enjoy the info on this forum. Al Bradford
"Don't forget page one too."
Silly me!
Can be found at:
www.ganssle.com/.../wom1.pdf
<snip>
Much of this stuff is covered in a SQEM (Software Quality Engineering Manual) that your company had developed... typically as a result of Mil/Aero/FDA standards.
Does it cover anything that's *not* blindingly obvious?
"Does it cover anything that's *not* blindingly obvious?"
The text I wrote? Or the post from Cpt. Vince? Or something from Jack Ganssle's page? Or something else?
What is blindingly obvious tends to vary quite a lot between people, which should be quite obvious if you look at the varying posts to this forum.
Some thing it is obvious to start with a requirements specification.
Some think it is obvious to read up on a development too before buying it.
Some think it is obvious to read datasheets before selecting components.
...
But despite everything obvious, people still manages to run off the road. Isn't the reason for checklists to help people remember all the obvious steps, so they don't try to land their plane without landing gears?
What is obvious is a function of earlier training and past mistakes.
But being obvious doesn't stop us from forgetting.
The text I quoted. That is the usual procedure - quote text, post reply. Here's the text again:
If you are having any difficulty finding that text and the lengthy ramble that precedes it please follow the author's advice and scroll up.
I would have hoped that anyone working on a project to "Mil/Aero/FDA stadards" would find the text preceding the part I quoted blindingly obvious.
But then, I would have hoped that anyone working to those standards would be able to express a couple of simple points clearly and concisely.
Always so positive.
And would you care to come with an estimate what percentage of developers who frequents this forum that does "Mil/Aero/FDA stadars [sic!]"?
Are you sure that the rest of the visitors have no interest in, or need for, making their firmwares more robust?
A big problem for a lot of developers is that there are large numbers of smaller companies that does not even have any Software Quality Engineering Manuals because the management do not know anything at all about software development, and sometimes doesn't even know if their employed developers are top-notch or just about able to flash a diode.
It can take a lot of work for one or a few developers to help themselves to some form of formalized development model, and also manage to get it established in the company. As captain Vince notes, a large part of the development is not the actual coding. How do you get management to realize that a project budget should include significant time for work spent before code start, and significant amount of time after you have a release candidate? And to allocate time/cost for development of test models suitable for the developed product?
I like situations where I can release one new firmware version every 12-24 months, because a customer requests the addition of a function. But the joke I did post earlier about the development process is quite close to the real world, or we wouldn't laugh at it. Too many companies forgets about the cost to maintain a product if it isn't properly designed, not to mention the goodwill loss from the customers having to constantly wait for the next maintainance release just to get an _almost_ working application.
It is so easy to just say that something is obvious. But that is just a great way of being ignorant.
In some situations what is obvious can be expressed very clearly and concisely. That is what you do in a checklist. But if you widen your view and realize that everything may not be obvious to every visitor on this forum, then you would note something else. Sometimes you also have to do a bit of sell in of a concept. Motivating things with examples. Here is a shocker: Most of the things written on this forum are not aimed specifically for your eyes. When you do see errors expressed, you do the forum a service by pointing them out. When you spend your time focusing on how the presentation affects you, people will quickly think: "Oh no, not again", and directly scroll to the next post.
That's an easy one: none.
This, along with the rest of your post, misses the point. Try re-reading my original post.
I'll take ignorance!
Please enlighten us, Mr. Sprat: How do you know that? Do you indeed carry the gift of telepathy (as Erik once suggested...) or did you use you amazing deduction skills to infer the above?
The latter, Mr. Michael, the latter.
I'm afraid that telepathy does not exist.
Hi Per,
May I be allowed to translate a very little parts of your "Some concepts for hardening embedded software" into Chinese, and to post the translated parts with a very short Chinese introduction to a BBS forum in Taiwan? (with a link to the original source and the name of you)? This is to introduce your documentation to my region.
LOL - the first actual comment about the page will be in a language I can't read :)
Yes, you may translate the text. Name + link to the english text will be fine.
I should update the page with some form of usage/license information to make it easier to make use of the text.
A Traditional Chinese Introduction to Per Westermark's "Some concepts for hardening embedded software"
www.ptt.cc/.../M.1239466995.A.F65.html
Per,
Thanks for an interesting article.
John,
Thanks for the translation. I hope to persuade my (Chinese) wife to read it. Then, maybe, she'll start to understand what my job is about.
But at the moment, it's throwing up a 404 error :(