做嵌入式C開發(fā)這些年我見過太多系統(tǒng)跑著跑著突然復(fù)位現(xiàn)場(chǎng)工程師一臉無辜最后定位到是一行看似人畜無害的memcpy或者一個(gè)沒加檢查的數(shù)組下標(biāo)。嵌入式C安全編碼聽起來像是個(gè)考概念的東西其實(shí)它就是一套讓你少去現(xiàn)場(chǎng)救火、少挨領(lǐng)導(dǎo)罵的方法論。這篇文章我想從一個(gè)一線開發(fā)者的角度聊聊在資源受限、沒有完整操作系統(tǒng)兜底的環(huán)境里怎么寫C才算安全哪些規(guī)范值得落地哪些工具能幫你把隱患扼殺在編譯期和測(cè)試期。如果你剛從C轉(zhuǎn)C或者正在做嵌入式Linux帶QT的應(yīng)用層開發(fā)又或者每天都在跟裸機(jī)中斷打交道這篇文章應(yīng)該都能給你一點(diǎn)參考。1. 嵌入式C安全編碼到底在防什么1.1 嵌入式環(huán)境的威脅模型跟服務(wù)器完全不一樣嵌入式系統(tǒng)通常資源受限CPU主頻低、RAM可能只有幾十KB到幾MB、Flash有限很多跑裸機(jī)的芯片連MMU都沒有。但它卻要連續(xù)運(yùn)行幾個(gè)月甚至幾年不能輕易重啟還得實(shí)時(shí)響應(yīng)外部中斷控制電機(jī)、傳感器、通信總線。這些約束決定了嵌入式安全編碼和通用軟件安全側(cè)重點(diǎn)完全不同。通用軟件的安全策略大多在防黑客、防數(shù)據(jù)泄露代碼寫得飄逸一點(diǎn)問題不大頂多上線后擴(kuò)容。嵌入式系統(tǒng)更怕的是“自己人”——開發(fā)者自己寫出未定義行為比如數(shù)組越界把棧踩了或者中斷里動(dòng)了不該動(dòng)的變量最后系統(tǒng)隨機(jī)死機(jī)、數(shù)據(jù)錯(cuò)亂。在工業(yè)、汽車等領(lǐng)域還得面對(duì)功能安全標(biāo)準(zhǔn)比如ISO 26262、IEC 61508這些標(biāo)準(zhǔn)把底層那一大堆編碼規(guī)范指向同一個(gè)目標(biāo)讓代碼行為可預(yù)測(cè)、可驗(yàn)證、可維護(hù)。所以我會(huì)把嵌入式C安全編碼理解成一套“風(fēng)險(xiǎn)控制清單”核心不是告訴你這個(gè)特性能不能用而是在這個(gè)環(huán)境里用的時(shí)候會(huì)不會(huì)引入不可控行為。一個(gè)int類型在桌面上溢出可能只是計(jì)算結(jié)果不對(duì)在嵌入式里可能直接導(dǎo)致電機(jī)堵轉(zhuǎn)、閥門誤動(dòng)作。1.2 C在嵌入式里的雙刃劍特性C在嵌入式領(lǐng)域越來越普及原因很簡(jiǎn)單它的抽象能力比C強(qiáng)但依然能貼著硬件編程。RAII讓資源的獲取和釋放在構(gòu)造/析構(gòu)里成對(duì)出現(xiàn)模板和constexpr可以把很多工作在編譯期就做完這比C語言里靠goto fail風(fēng)格手工清理要可靠得多。但C也是把雙刃劍。異常機(jī)制在嵌入式里經(jīng)常被禁用因?yàn)楫惓?huì)讓代碼體積明顯膨脹棧展開行為在裸機(jī)環(huán)境下也不可控如果不用異常你寫的new、容器操作一旦分配失敗默認(rèn)行為可能是直接終止或者陷入死循環(huán)。所以實(shí)際項(xiàng)目里通常要重寫全局operator new或者在啟動(dòng)時(shí)就預(yù)分配好內(nèi)存池把動(dòng)態(tài)內(nèi)存限制在固定大小段塊里。另外虛函數(shù)和RTTI都好用但會(huì)增加Flash占用部分安全標(biāo)準(zhǔn)還會(huì)限制使用。安全編碼不是讓你禁掉C而是讓你明確哪些特性可以用、怎么用、用在哪里為止。我見過有人把桌面端那套std::unordered_map、std::string直接搬進(jìn)MCU結(jié)果堆碎片化嚴(yán)重系統(tǒng)運(yùn)行幾天后掛掉。這種問題不是C的鍋是你不了解嵌入式環(huán)境的資源邊界。2. 從代碼層面堵住高危漏洞核心實(shí)操2.1 緩沖區(qū)與邊界別再用裸數(shù)組下標(biāo)了先聊最常見的高危區(qū)緩沖區(qū)越界。C語言時(shí)代的經(jīng)典寫法是定義一個(gè)全局?jǐn)?shù)組然后用下標(biāo)訪問。換成C很多人還是習(xí)慣數(shù)組甚至把裸數(shù)組當(dāng)參數(shù)傳來傳去信號(hào)一來就memcpy長(zhǎng)度全靠調(diào)用方自覺。這種代碼在嵌入式里簡(jiǎn)直是定時(shí)炸彈。我一直推薦盡量用std::array和std::spanC20代替裸數(shù)組。std::array是定長(zhǎng)數(shù)組有at()可以做邊界拋異常就算不用異常也至少能用size()隨時(shí)拿到長(zhǎng)度。std::span是C20的連續(xù)內(nèi)存視圖適配數(shù)組、std::array、vector它本身不擁有內(nèi)存非常適合嵌入式里做函數(shù)參數(shù)傳遞。// 不推薦裸數(shù)組 裸指針參數(shù) void parse_frame(const uint8_t* data, size_t len) { uint8_t tmp[64]; memcpy(tmp, data, len); // len 大于64就爆棧 } // 推薦span 明確邊界 #include span void parse_frame(std::spanconst uint8_t data) { uint8_t tmp[64]; if (data.size() sizeof(tmp)) { // 錯(cuò)誤處理 return; } memcpy(tmp, data.data(), data.size()); }你可能覺得std::span在C20才引入很多嵌入式編譯器還停留在C17。沒關(guān)系GSLGuidelines Support Library里有個(gè)gsl::span或者你自己寫一個(gè)簡(jiǎn)單的span包裝類也行關(guān)鍵是讓“指針長(zhǎng)度”這種游離信息捆綁在一起從接口上杜絕越界。另外一個(gè)實(shí)用技巧是棧上數(shù)組建議配上編譯期檢查的宏或者模板函數(shù)類似std::size()讓數(shù)組越界在編譯期就能被發(fā)現(xiàn)的盡量提前。之前我優(yōu)化一個(gè)通信協(xié)議解析模塊把所有裸數(shù)組下標(biāo)訪問換成std::array和span之后光Code Review階段就堵住了三處長(zhǎng)度不匹配的問題這在以前只能靠實(shí)機(jī)抓崩潰。2.2 整數(shù)溢出嵌入式C里最陰的坑整數(shù)溢出在嵌入式里非常常見而且隱蔽。因?yàn)橛布拇嫫?、協(xié)議字段很多都是uint8_t、uint16_t、uint32_t處理數(shù)據(jù)時(shí)一不留神就回繞了。比如用ADC采樣算平均值最直接的做法是累積然后除以次數(shù)可如果采樣值是16位采樣幾千次后累加就可能超過32位范圍。更隱蔽的是有符號(hào)整數(shù)溢出這在C標(biāo)準(zhǔn)里屬于未定義行為。編譯器會(huì)假設(shè)這種情況不會(huì)發(fā)生然后做各種激進(jìn)的優(yōu)化最后代碼行為完全不可預(yù)測(cè)?？纯催@個(gè)例子int16_t sensor_raw; // 來自硬件寄存器 int32_t temp sensor_raw * 10; // sensor_raw 0x4FFF 還不會(huì)溢出但如果后面加個(gè)偏移 int16_t result temp 50; // 如果結(jié)果超過int16_t轉(zhuǎn)換是實(shí)現(xiàn)定義但通常是你不想看到的結(jié)果安全編碼里我習(xí)慣遵循幾條硬性規(guī)則第一涉及到運(yùn)算先用更大類型第二類型轉(zhuǎn)換時(shí)顯式判斷范圍第三處理協(xié)議字段或外部輸入時(shí)任何長(zhǎng)度字段都要先驗(yàn)邊界再使用。有個(gè)半官方Collections了C標(biāo)準(zhǔn)里提供了一些數(shù)學(xué)內(nèi)建函數(shù)比如GCC的__builtin_add_overflow可以在編譯期檢測(cè)溢出并生成高效代碼。#include cstdint #include limits // 檢查無符號(hào)加法是否回繞 bool checked_add(uint32_t lhs, uint32_t rhs, uint32_t result) { if (lhs std::numeric_limitsuint32_t::max() - rhs) { return false; } result lhs rhs; return true; } // 或者更直接使用編譯器內(nèi)建 bool checked_add_builtin(uint32_t a, uint32_t b, uint32_t out) { return !__builtin_add_overflow(a, b, out); }我自己在處理Modbus協(xié)議、CAN報(bào)文解析時(shí)凡是涉及“長(zhǎng)度字節(jié)0 字節(jié)1 * 256”這類組合運(yùn)算都會(huì)強(qiáng)制套一層邊界檢查。因?yàn)橥獠吭O(shè)備給的數(shù)據(jù)是不可信的你永遠(yuǎn)不知道對(duì)方會(huì)傳什么值過來。嵌入式里出故障不可怕可怕的是出故障時(shí)你找不到明確原因而整數(shù)溢出正是這類“定時(shí)炸彈”的頭號(hào)種子。2.3 指針、生命周期和內(nèi)存管理裸指針是C里最容易翻車的點(diǎn)也是嵌入式老代碼里最常見的亮點(diǎn)。常見問題包括懸垂指針、雙重釋放、數(shù)組指針類型衰減、用reinterpret_cast做可疑的類型強(qiáng)轉(zhuǎn)。嵌入式項(xiàng)目里喜歡用裸指針也情有可原因?yàn)樾阅芎偷讓釉L問確實(shí)方便。但安全編碼不要求你完全消滅裸指針而是要求你明確所有權(quán)。如果你有動(dòng)態(tài)對(duì)象優(yōu)先使用std::unique_ptr它有明確的所有權(quán)語義析構(gòu)時(shí)自動(dòng)釋放體積和裸指針一樣性能開銷幾乎為零。std::shared_ptr要謹(jǐn)慎用因?yàn)榭刂茐K是動(dòng)態(tài)分配多一個(gè)計(jì)數(shù)器、多一次原子操作在中斷上下文里簡(jiǎn)直災(zāi)難。如果確實(shí)需要引用計(jì)數(shù)我更喜歡侵入式引用計(jì)數(shù)或者在內(nèi)存池里實(shí)現(xiàn)專用計(jì)數(shù)塊。生命周期管理里最容易翻車的是“先釋放后使用”。舉個(gè)典型場(chǎng)景你用std::unique_ptr管理一個(gè)外設(shè)驅(qū)動(dòng)對(duì)象注冊(cè)到某個(gè)消息隊(duì)列時(shí)把裸指針傳進(jìn)去了消息隊(duì)列延遲處理另一個(gè)線程先把對(duì)象銷毀了等隊(duì)列處理到這條消息時(shí)你的裸指針已經(jīng)懸垂。解決辦法是在消息隊(duì)列里直接傳shared_ptr如果不介意開銷或者在銷毀對(duì)象前先確保從所有潛在引用點(diǎn)摘除。// 裸指針版本危險(xiǎn) Driver* driver create_driver(); event_queue.post(driver); remove_driver(driver); // 可能讓隊(duì)列里的 driver 懸垂 delete driver; // 安全版本使用 shared_ptr 穿透隊(duì)列 std::shared_ptrDriver driver create_driver(); event_queue.post(driver); // 隊(duì)列持有引用 remove_driver(driver); // 只是從注冊(cè)表移除對(duì)象在隊(duì)列完成后被釋放至于reinterpret_cast它確實(shí)在寄存器訪問、內(nèi)存映射里有用但絕不建議用來做反序列化。我曾經(jīng)見過有人直接把網(wǎng)絡(luò)字節(jié)序的buffer reinterpret_cast成結(jié)構(gòu)體指針結(jié)果因?yàn)閷?duì)齊問題在ARM上觸發(fā)硬錯(cuò)誤。正確做法仍然是先拷貝到對(duì)齊的本地結(jié)構(gòu)體變量里再按字段解析。2.4 格式化輸出與日志的安全寫法嵌入式開發(fā)離不開日志串口打印、flash log到處是printf。但很多人把桌面端的習(xí)慣帶進(jìn)來sprintf(buffer, frame, var)一把梭完全不檢查目標(biāo)緩沖區(qū)長(zhǎng)。這個(gè)坑我已經(jīng)踩出經(jīng)驗(yàn)了代碼上線前用-Wformat-overflow掃一遍還能掃出一堆可能截?cái)嗟膕printf。原則很簡(jiǎn)單盡量不用sprintf用snprintf或者std::formatC20。如果編譯器沒支持std::format那就老老實(shí)實(shí)snprintf并檢查返回值。特別要注意格式化串里絕不能出現(xiàn)用戶可控的%n很多攻擊都會(huì)利用這個(gè)占位符往指定地址寫數(shù)據(jù)。嵌入式里即使沒有黑客一個(gè)異常值也足以讓日志系統(tǒng)崩掉。char logbuf[128]; uint32_t adc_value read_adc(); // 危險(xiǎn)可能越界且 format 內(nèi)容如果來自外部還可能被注入 sprintf(logbuf, ADC value: %s, input_string); // 安全顯式限制長(zhǎng)度 std::spanchar buf_span(logbuf); int ret snprintf(logbuf, sizeof(logbuf), ADC value: %u, adc_value); if (ret 0 || static_castsize_t(ret) sizeof(logbuf)) { // 處理截?cái)嗷蝈e(cuò)誤 }另外一個(gè)安全日志習(xí)慣是在嵌入式系統(tǒng)里寧可日志少輸出也不能因?yàn)槿罩咀枞髁鞒獭Ｎ乙话惆讶罩揪彌_區(qū)和串口發(fā)送做成異步環(huán)形緩沖遇到格式化耗時(shí)高的問題時(shí)可以利用snprintf只做純內(nèi)存操作然后由低優(yōu)先級(jí)任務(wù)或DMA發(fā)送。這樣即便某個(gè)日志模板算錯(cuò)了長(zhǎng)度也就是一條日志被截?cái)嗖粫?huì)把主邏輯搞掛。3. 嵌入式C項(xiàng)目的安全編碼規(guī)范落地3.1 MISRA C 和 AUTOSAR C14 怎么選聊嵌入式C安全編碼繞不開MISRA C和AUTOSAR C14。很多公司做汽車電子、功能安全相關(guān)產(chǎn)品時(shí)客戶會(huì)明確要求遵守這些編碼規(guī)范。MISRA C 2008比較老了主要針對(duì)C03強(qiáng)調(diào)靜態(tài)分析、避免未定義行為。AUTOSAR C14是后來推出的成熟規(guī)范基于C14對(duì)現(xiàn)代C特性做了更精細(xì)的約束。但這套規(guī)范不能直接照搬因?yàn)楹芏嘁?guī)則在有特定目標(biāo)環(huán)境時(shí)過于嚴(yán)格全部遵守意味著開發(fā)效率低到?jīng)]法干活。我建議把它當(dāng)“基線”而不是“法律”。在實(shí)際項(xiàng)目中我一般會(huì)從里面挑出幾類必須遵守的規(guī)則禁止使用動(dòng)態(tài)內(nèi)存分配作為默認(rèn)機(jī)制new/delete盡量集中在啟動(dòng)階段或特定內(nèi)存池禁止未經(jīng)顯式聲明就進(jìn)行隱式類型轉(zhuǎn)換禁止在不同整數(shù)寬度間隱式轉(zhuǎn)換限定goto、setjmp/longjmp、遞歸的使用對(duì)指針使用前必須判空必要時(shí)使用斷言約束。選擇規(guī)則時(shí)最關(guān)鍵的還是看團(tuán)隊(duì)能力。如果你團(tuán)隊(duì)里都是寫過幾年嵌入式的老人可以放寬一部分規(guī)則如果是新人比較多還是嚴(yán)格一點(diǎn)好畢竟安全編碼規(guī)范其實(shí)就是“行業(yè)里踩過坑之后總結(jié)出來的一條條紅線”。3.2 編譯器選項(xiàng)、sanitizer 和靜態(tài)分析規(guī)范寫出來是給機(jī)器和人共同執(zhí)行的。編譯器是我們最先能用起來的“安全編碼工具”。我每次在CMake里都會(huì)打開這些選項(xiàng)# 編譯選項(xiàng)示例 target_compile_options(app PRIVATE -Wall -Wextra -Wshadow -Wconversion -Wsign-conversion -Wformat2 -Wundef -Werrorreturn-type -fno-exceptions -fno-rtti -fstack-protector-all )-Wconversion和-Wsign-conversion對(duì)嵌入式特別有用它會(huì)把有符號(hào)和無符號(hào)整數(shù)之前的隱式轉(zhuǎn)換報(bào)出來很多安全缺陷其實(shí)都是這類轉(zhuǎn)換埋的雷。-fno-exceptions是為了配合沒有異常的環(huán)境-fno-rtti會(huì)強(qiáng)制你少用dynamic_cast和typeid這符合很多MCU的實(shí)際情況。-fstack-protector-all會(huì)在棧上插金絲雀值棧被寫壞時(shí)能及時(shí)觸發(fā)崩潰而不是讓你排查三個(gè)月。開發(fā)階段我強(qiáng)烈建議在宿主機(jī)的仿真環(huán)境里跑單元測(cè)試并開啟AddressSanitizer。比如你用STL容器寫了塊邏輯先在x86 Linux上編譯一個(gè)小測(cè)試開-fsanitizeaddress,undefined把數(shù)組越界、整數(shù)溢出、內(nèi)存泄漏問題一次性抓出來。再交叉編譯到目標(biāo)板主要跑實(shí)時(shí)行為。這套組合拳比只做實(shí)機(jī)測(cè)試省時(shí)間得多。靜態(tài)分析方面我在嵌入式C項(xiàng)目里常用cppcheck和clang-tidy。cppcheck輕量、跨平臺(tái)找數(shù)組越界、空指針比較強(qiáng)clang-tidy能執(zhí)行大量C core guidelines檢查還能按你的規(guī)則定制。商業(yè)工具里PVS-Studio也不錯(cuò)識(shí)別誤報(bào)少但對(duì)小團(tuán)隊(duì)可能貴了點(diǎn)。把靜態(tài)分析接入CI每次提交代碼都自動(dòng)跑一遍效果遠(yuǎn)好于上線前大檢查。3.3 代碼評(píng)審清單六類必查問題代碼評(píng)審不能只聊邏輯對(duì)不對(duì)更得盯住安全屬性。我給自己定了一張檢查清單每次評(píng)審嵌入式C代碼時(shí)都照著過一遍數(shù)組和緩沖區(qū)訪問所有索引是否來自外部長(zhǎng)度是否在邊界內(nèi)有沒有用memcpy拷貝超長(zhǎng)數(shù)據(jù)整數(shù)運(yùn)算有沒有帶符號(hào)/無符號(hào)混用有沒有可能回繞的累加、位移和乘法資源生命周期誰創(chuàng)建誰釋放有沒有裸指針逃逸對(duì)象析構(gòu)時(shí)有沒有并發(fā)訪問類型轉(zhuǎn)換隱式轉(zhuǎn)換多不多reinterpret_cast用在哪里有沒有字節(jié)序和結(jié)構(gòu)體對(duì)齊問題并發(fā)與中斷共享變量是否用volatile或atomic中斷里能不能調(diào)用非可重入函數(shù)鎖的持有時(shí)間會(huì)不會(huì)太長(zhǎng)錯(cuò)誤處理是否所有邊界都會(huì)走到錯(cuò)誤分支錯(cuò)誤日志是否完整會(huì)不會(huì)吞掉錯(cuò)誤后繼續(xù)跑這套清單不復(fù)雜但執(zhí)行到位能堵掉大部分“看起來沒問題運(yùn)行起來就炸”的缺陷。評(píng)審時(shí)我還會(huì)額外關(guān)注一個(gè)點(diǎn)讓人疑惑的代碼不管對(duì)不對(duì)都要求加注釋或重寫。因?yàn)樵谇度胧江h(huán)境下你的代碼很可能要被維護(hù)十年十年后接手的工程師未必知道當(dāng)年的意圖規(guī)范清晰的代碼才是真正安全代碼。4. 實(shí)操過程從一個(gè)通信解析模塊看安全改造4.1 原始代碼的問題現(xiàn)場(chǎng)拿一個(gè)實(shí)際例子來講。之前維護(hù)過一個(gè)串口通信模塊接收一幀Modbus RTU報(bào)文解析后把寄存器值存入系統(tǒng)變量。原始代碼大概是這樣的// 原始代碼問題極其典型的現(xiàn)場(chǎng)版本 #define FRAME_BUFFER_SIZE 128 uint8_t frame_buffer[FRAME_BUFFER_SIZE]; uint8_t frame_len 0; // 假設(shè)從串口中斷里接收已經(jīng)填滿了 frame_buffer 和 frame_len uint8_t received_frame[FRAME_BUFFER_SIZE]; void parse_modbus_frame() { uint16_t data_len (frame_buffer[2] 8) | frame_buffer[3]; if (data_len FRAME_BUFFER_SIZE) { // 這里打算處理錯(cuò)誤但被注釋了實(shí)際什么都沒干 return; } memcpy(received_frame, frame_buffer, data_len); // 直接把 buffer 強(qiáng)轉(zhuǎn)成協(xié)議結(jié)構(gòu)體 ModbusFrame* frame reinterpret_castModbusFrame*(received_frame); // 然后直接用 frame-field1 做業(yè)務(wù)邏輯 uint16_t reg_value frame-reg_values[5]; set_register(0x0005, reg_value); }這個(gè)模塊在測(cè)試機(jī)上跑了兩周才暴露出問題只要外部設(shè)備發(fā)來一個(gè)異常幀frame_len雖然充滿128字節(jié)但真正的協(xié)議長(zhǎng)度字段可能寫得非常大這里雖然做了data_len FRAME_BUFFER_SIZE判斷可它只檢查了上限沒檢查下限。如果data_len是0或者1后面的字段讀取就會(huì)越界直接把系統(tǒng)棧污染。還有個(gè)更致命的是reinterpret_cast直接把裸數(shù)組轉(zhuǎn)成結(jié)構(gòu)體結(jié)構(gòu)體對(duì)齊要求是2字節(jié)如果buffer地址不對(duì)齊ARM內(nèi)核會(huì)直接進(jìn)HardFault。4.2 對(duì)照改造后的安全版本我重構(gòu)這個(gè)模塊時(shí)按上面的安全編碼思路來做。首先引入std::array和std::span作為接口然后把協(xié)議解析拆成“幀校驗(yàn)”和“字段提取”兩步。長(zhǎng)度先校驗(yàn)字段再逐個(gè)提取用memcpy拷貝到本地變量而不是強(qiáng)轉(zhuǎn)結(jié)構(gòu)體。// 改造后的代碼安全版本 #include array #include span #include cstring constexpr size_t FRAME_BUFFER_SIZE 128; using FrameBuffer std::arrayuint8_t, FRAME_BUFFER_SIZE; // 接收緩沖一次性初始化 static FrameBuffer frame_buffer{}; static size_t frame_len 0; bool ModbusParseFrame(std::spanconst uint8_t frame) { constexpr size_t header_len 4; // 1. 長(zhǎng)度下限校驗(yàn) if (frame.size() header_len) return false; uint16_t data_len static_castuint16_t(frame[2]) 8 | static_castuint16_t(frame[3]); // 2. 長(zhǎng)度字段 頭長(zhǎng)度不能越界 if (data_len frame.size() - header_len) return false; // 3. 偏移到底層字段 size_t reg_index 5; if (reg_index frame.size()) return false; // 4. 從緩沖區(qū)拷貝到本地對(duì)齊變量 uint16_t reg_value 0; std::memcpy(reg_value, frame.data() reg_index, sizeof(reg_value)); // 5. 期間注意字節(jié)序轉(zhuǎn)換最終寫系統(tǒng)寄存器 reg_value (reg_value 8) | (reg_value 8); // 示例大端轉(zhuǎn)小端 SetSystemRegister(0x0005, reg_value); return true; }改造之后數(shù)據(jù)流向變得很清晰std::span里帶長(zhǎng)度信息所有訪問通過frame.size()約束memcpy拷貝到本地變量避免對(duì)齊問題最終再做大端轉(zhuǎn)小端。你可能覺得變長(zhǎng)了但每條判斷背后都能對(duì)應(yīng)一個(gè)曾經(jīng)出現(xiàn)過的故障場(chǎng)景。這就是安全編碼的代價(jià)和回報(bào)多一點(diǎn)代碼少一次現(xiàn)場(chǎng)排查事故。4.3 關(guān)鍵參數(shù)與驗(yàn)證方法重構(gòu)完不是完事了得驗(yàn)證。我在這個(gè)模塊上做了三層驗(yàn)證用單元測(cè)試覆蓋所有邊界幀包括長(zhǎng)度過小、長(zhǎng)度過大、中間字段越界、異常字節(jié)序在開發(fā)板上用隨機(jī)幀模糊測(cè)試連續(xù)跑100萬幀期間調(diào)用系統(tǒng)復(fù)位計(jì)數(shù)對(duì)比改造前后的崩潰率開啟-fsanitizeaddress版本在x86 Linux上執(zhí)行同樣的單元測(cè)試確保內(nèi)存錯(cuò)誤一塊都不剩。參數(shù)選擇上我故意把緩沖區(qū)從裸數(shù)組換成std::array雖然編譯產(chǎn)物沒有變化但size()讓長(zhǎng)度信息不再靠人記。關(guān)鍵性能參數(shù)也測(cè)過解析單幀耗時(shí)比原來增加了不到2微秒在115200波特率的串口鏈路里遠(yuǎn)遠(yuǎn)夠用。安全編碼不是無條件犧牲性能而是在風(fēng)險(xiǎn)最大處多花一點(diǎn)“保險(xiǎn)費(fèi)”。5. 常見問題與排查技巧實(shí)錄5.1 棧被寫壞復(fù)位地址飄忽不定嵌入式最常見的事故現(xiàn)象是“系統(tǒng)跑到某個(gè)時(shí)間點(diǎn)突然重啟”而且每次復(fù)位地址都不同。這種問題十有八九是棧溢出或者數(shù)組越界。排查時(shí)我最常用的招數(shù)是開啟編譯器的棧保護(hù)# GCC 編譯時(shí)加上棧保護(hù)并用 map 文件定位棧大小 arm-none-eabi-g -fstack-protector-all -Wl,--print-map ...如果花了-fstack-protector-all還是不好定位我會(huì)在HardFault處理函數(shù)里加?；厮荽蛴“袻R、PC、SP關(guān)鍵寄存器打印出來再結(jié)合map文件里的函數(shù)地址定位到具體調(diào)用棧。我的經(jīng)驗(yàn)是先把可復(fù)現(xiàn)的模糊測(cè)試跑起來一旦觸發(fā)棧保護(hù)立即抓現(xiàn)場(chǎng)逐步縮小到具體函數(shù)。5.2 系統(tǒng)運(yùn)行幾天后隨機(jī)死機(jī)隨機(jī)死機(jī)最常見原因是堆碎片和動(dòng)態(tài)內(nèi)存泄漏。裸機(jī)下如果用malloc、new頻繁分配小塊一段時(shí)間后堆里全是縫隙一個(gè)大對(duì)象分配失敗系統(tǒng)就掛。排查時(shí)可以在啟動(dòng)階段統(tǒng)計(jì)堆剩余空間周期性打印出來看是不是線性下降。我遇到過一個(gè)小項(xiàng)目每秒創(chuàng)建一個(gè)std::string來拼日志結(jié)果堆空間從3MB降到200KB系統(tǒng)一周內(nèi)崩潰。解決辦法是把日志改成固定長(zhǎng)度char數(shù)組或者用內(nèi)存池固定大小塊。如果你已經(jīng)用了內(nèi)存池那就要查“任務(wù)棧”。在RTOS里每個(gè)任務(wù)棧太小同樣會(huì)出現(xiàn)隨機(jī)死機(jī)。我習(xí)慣把任務(wù)棧使用量最大的發(fā)現(xiàn)通過一個(gè)周期任務(wù)打印出來上線前再留30%余量。5.3 中斷里用C容器直接卡死很多新手在中斷里放著心跳計(jì)時(shí)器結(jié)果就在中斷里push_back一個(gè)std::vector然后進(jìn)入臨界區(qū)后調(diào)用動(dòng)態(tài)分配函數(shù)線程被卡死。中斷上下文里絕對(duì)不能做三件事動(dòng)態(tài)內(nèi)存分配、調(diào)用不可重入的標(biāo)準(zhǔn)庫函數(shù)、使用非無鎖的數(shù)據(jù)結(jié)構(gòu)。正確的做法是中斷只負(fù)責(zé)把數(shù)據(jù)放到一個(gè)固定大小的環(huán)形緩沖或無鎖隊(duì)列里由低優(yōu)先級(jí)任務(wù)負(fù)責(zé)消費(fèi)。如果非要和業(yè)務(wù)共享數(shù)據(jù)請(qǐng)使用std::atomic并且保證在中斷里只無鎖寫入主邏輯里用臨界區(qū)讀。無論是裸機(jī)還是RTOS這條規(guī)則都很硬。5.4 面試聊安全編碼最好別只背八股搜“嵌入式面試題”的人很多安全編碼也是必問方向。但面試官真正想聽的不是“我知道MISRA C有規(guī)則5.0.1”而是你是否在真實(shí)項(xiàng)目里踩過坑。比如問“volatile和atomic什么區(qū)別”如果你能舉例“中斷里改了一個(gè)標(biāo)志位主循環(huán)不加volatile一直讀優(yōu)化開關(guān)一開就出問題后來換成std::atomic才穩(wěn)定”這比背定義強(qiáng)太多。我在招聘時(shí)也喜歡問一個(gè)具體場(chǎng)景給你一個(gè)外部傳入的緩沖區(qū)指針你怎么安全地解析出前4個(gè)字節(jié)這題能考察對(duì)邊界、對(duì)齊、字節(jié)序的敏銳程度。安全編碼不是一個(gè)獨(dú)立的知識(shí)點(diǎn)它整體滲透在你的調(diào)試經(jīng)驗(yàn)、編譯選項(xiàng)理解、代碼review習(xí)慣里所以平時(shí)多積累多復(fù)盤面試自然有話可說。最后說點(diǎn)個(gè)人體會(huì)。我在實(shí)際項(xiàng)目里有個(gè)小技巧給所有跨模塊接口的入口處加斷言和邊界檢查不管內(nèi)部邏輯是否可信。上線版本里如果要把這些斷言關(guān)掉也會(huì)留著邊界檢查只把斷言換成日志。這樣既保證了性能又不至于讓一個(gè)不該發(fā)生的越界悄悄溜過去。嵌入式C安全編碼確實(shí)沒有魔法它靠的是一條條邊界檢查、一組組編譯警告、一次次代碼評(píng)審堆出來的。但正是這些“笨功夫”能讓你在深夜被電話叫醒的機(jī)會(huì)少一點(diǎn)。