作者) 看板: [心得(系統: Sun Apr 12 00:23:14 2009

我在(系統.希望能夠把這篇文章介紹給大家。
KEIL官方論壇的討論串在此：

Per Westermark所發起，
KEIL官方論壇的主要貢獻者)之一。
Per Westermark才會公開發表以下這篇文章。

Copyright (c) Per Westermark, 2009
http://iapetus.neab.net/download/8dc2ac48-635ac1a9/hardening.html

Per Westermark表示，關於系統開發的流程、方法論、規範標準等等，
大家都可以找到各式各樣的豐富資料，
但是，在實際進行軟體開發的時候，應該注意哪些關鍵，卻很少有人提及；
所以，21項建議，
而這些建議，所著眼的，並不是如何寫出洗練的程式碼，也並不是如何減少Per Westermark的建議，是實在地告訴我們，
當一個系統出錯的時候，軟體應該如何處理；
至少，對於鄙陋如我而言，

uint16_t buf[BUF_SIZE];

...
do_something();
buf[idx] = new_data;
}

在一個0開始，直到小於if (idx >= BUF_SIZE) then do_something()的代碼，看來似乎是相當地外行？

其實不然。

unsigned idx;
for (idx = 0; idx < BUF_SIZE; idx ) {
if (idx >= BUF_SIZE) {
// action.
} else {
}


在以下這串雜七雜八的閒聊裡，提到了一些例子：

)
Bit Error/位元錯誤，
也就是說，原本為Bit突然變成了1的0；

也或許，因為這個嵌入式系統用在電子作戰，
它必須干擾敵方的系統，並且不被敵方干擾；
也或許，因為這個嵌入式系統用在吃角子老虎，
剛好有人想要作弊，剛好有人想要破台。
Bit Error發生的時候，軟體應該怎麼做？


/糾錯」的能力。
3. Recomputed variables
系統閒置時，重新計算「重要的變數」。
4. Refreshing of I/O configuration and state
系統閒置時，重新寫入重要的「設定值」。
5. Cross-correlation of time from multiple sources
系統應該具備偵測能力，以評估「時間

/下限」，應該明確的定義並且加以偵測，
以確保資料區域不被損毀。
8. Stack highwater marks
Pattern，讓系統能夠對Stack不被損毀。
9. Corruption fingerprinting
資料儲存區應該填入
0表示0表示0x00與Bit。
11. Trend analysis of repairs/resends/…
系統應該具備「故障傾向」的偵測能力，比如說：
電壓逐步下降，


15. Hardware watchdog
17. Avoiding infinite loops
19. Duplicated firmwares
21. Static allocation

KEIL官方論壇的相關討論串留言：
http://www.keil.com/forum/docs/thread14537.asp

原文出處
iapetus.neab.net/download/8dc2ac48-635ac1a9/hardening.html

尚未深入的去看裡面的文章，不過就您所貼出來的部份，我對於那樣的做法有不同的看法:

簡言之那些做法僅是以「軟」護「硬」而已。雖然經常有這樣的需要，但那多數都是硬體的人員太偷懶或是太高傲!

如果說為了那些極小的可能性，且原則上可經硬體保護的情形下的error，不該做那麼多餘的if 保護。if的保護很重要，但以上面的那情形而言，實有"杞人憂天"之"太過"。一來那樣的程式碼讓效能變差(如果處處都有危機的話)，二來開發的時間變長!

軟與硬原本就是各有所專。許多那些系統錯誤都是硬體可解的，但硬體的人都不去解…此非正道! 比如雷擊，什麼被干擾… 硬的該做好硬的最佳化，最完善化。而軟體則也要做最佳化，最完善化，但軟的最完善應該是防止user輸入不該輸入的(人為)，造成buffer overrun等，避免野指標等等的…但應該不含那種超級"過度"的防護。

此外，若程式因此而寫的極為複雜，那麼bug也相對的機率會更高，而維護的人員時間與金錢也要付出更大! 這樣的代價會不會反而更大?

以上我是個人對那篇文的想法。

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

編輯記錄

 再補充一下:
在通訊中，網路的中、低層架構裡，有著error detection與error correction等保護。但這類的與那 system bit error，是不可相提並論!

如果說，連bit error都無法去用硬體來防，那麼用軟體一定會有效嗎? 以原例來說:

if (idx >= BUF_SIZE) {
do_something();

如果你的do_something的過程裡，再次的發生bit error的話，那你會有解嗎? (這是有很有可能的，因為硬體出錯的時候，往往會有至少幾個instructions都出問題，很難剛好僅一個memory裡的一個bit出事…

簡單講 ，若隨時都可能bit error，那麼不僅是在loop中要避，我看在非常多的地方都要避免了… 這種情形下，硬體的不可靠性根本也是軟體無法解的，或者說用很大的力氣僅可能解到極小的一部份!

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

我覺得不用那麼否定這篇文章的想法
它的標題也是標明如何強化
當然沒有一個軟體有100%測試無誤，絕不可能出錯
個人覺得應該要看什麼環境，什麼人用這一個產品
小朋友的玩具、手機、飛機、太空
什麼場合就做到什麼防護機制

電子雞，不用了吧
太空儀器，開玩笑，當然要做到最好

===================引 用 aftcast 文 章===================
尚未深入的去看裡面的文章，不過就您所貼出來的部份，我對於那樣的做法有不同的看法:

簡言之那些做法僅是以「軟」護「硬」而已。雖然經常有這樣的需要，但那多數都是硬體的人員太偷懶或是太高傲!

如果說為了那些極小的可能性，且原則上可經硬體保護的情形下的error，不該做那麼多餘的if 保護。if的保護很重要，但以上面的那情形而言，實有"杞人憂天"之"太過"。一來那樣的程式碼讓效能變差(如果處處都有危機的話)，二來開發的時間變長!

軟與硬原本就是各有所專。許多那些系統錯誤都是硬體可解的，但硬體的人都不去解…此非正道! 比如雷擊，什麼被干擾… 硬的該做好硬的最佳化，最完善化。而軟體則也要做最佳化，最完善化，但軟的最完善應該是防止user輸入不該輸入的(人為)，造成buffer overrun等，避免野指標等等的…但應該不含那種超級"過度"的防護。

此外，若程式因此而寫的極為複雜，那麼bug也相對的機率會更高，而維護的人員時間與金錢也要付出更大! 這樣的代價會不會反而更大?

以上我是個人對那篇文的想法。

這一篇 第一次看到是在ptt 好像還不少人參加討論~
我自己是認為 程式行為模式都跟發展背景有關
用大俠舉的通訊例子 以TCP/IP來說 IP是不穩定的 但TCP卻要求穩定
在一個不穩定的基礎 要去追求可靠 方法就只能靠不斷的糾錯 偵錯
所以有時候網路出包 網路還是會通 但是就是慢慢慢 慢到讓人起肖

這篇文章的某些論點 都是假設 身處在非常不穩定的環境
處處留下狀態副本 處處偵防 但是我不認為等意外發生時
這些副本派上用場 機器的運轉效果還會像正常情況一樣
應該是勉勉強強達到目的 就跟劉翔跛腳走到終點一樣
如果這也算是程式的預期目地
那就不枉程式師的一番努力吧 顆顆~~

這篇文章最後提到的Static allocation，小弟有一些實作經驗，野人獻曝一下:

godspeedlee.myweb.hinet.net/network_prog/0/

恭喜你在stackoverflow 破500 
恭喜 恭喜 ~~~



===================引 用 happosai 文 章===================
這篇文章最後提到的Static allocation，小弟有一些實作經驗，野人獻曝一下:

godspeedlee.myweb.hinet.net/network_prog/0/