एंबेडेड डेवलपर्स के आदेश से: अमेज़ॅन फ्रीआरटीओएस में बग की तलाश है

हर कोई जो माइक्रोकंट्रोलर प्रोग्राम करता है, वह शायद फ्रीआरटीओएस के बारे में जानता है, या कम से कम इस ऑपरेटिंग सिस्टम के बारे में सुना है। अमेज़ॅन लोगों ने एडब्ल्यूएस इंटरनेट ऑफ़ थिंग्स सेवाओं के साथ काम करने के लिए इस ऑपरेटिंग सिस्टम की क्षमताओं का विस्तार करने का फैसला किया - यह है कि अमेज़ॅन फ्रीआरटीओएस कैसे दिखाई दिया। हम, पीवीएस-स्टूडियो कोड विश्लेषक के डेवलपर्स को मेल में और लेखों के नीचे टिप्पणियों में इन परियोजनाओं की जांच करने के लिए कहा गया था। खैर, आपने पूछा - हमने किया। यह क्या आया - पर पढ़ें

परियोजनाओं के बारे में थोड़ा सा

शुरू करने के लिए, मैं आपको जाँच की गई परियोजना के "डैड" के बारे में थोड़ा बताऊंगा - फ्रीआरटीओएस (आप यहाँ स्रोत पा सकते हैं)। जैसा कि विकिपीडिया कहता है, FreeRTOS एम्बेडेड सिस्टम के लिए एक मल्टी-टास्किंग रियल-टाइम ऑपरेटिंग सिस्टम है।

यह अच्छी पुरानी सी में लिखा गया था, जो आश्चर्य की बात नहीं है - इस ऑपरेटिंग सिस्टम को माइक्रोकंट्रोलर्स की विशिष्ट परिस्थितियों में काम करना चाहिए: कम कंप्यूटिंग पावर, थोड़ी मात्रा में रैम, और इसी तरह। सी भाषा आपको निम्न स्तर पर संसाधनों के साथ काम करने की अनुमति देती है और इसमें उच्च प्रदर्शन होता है, इसलिए यह ऐसे ओएस के विकास के लिए सबसे उपयुक्त है।

अब अमेज़ॅन पर वापस, जो अभी भी नहीं बैठता है और विभिन्न आशाजनक क्षेत्रों में विकसित होता है। उदाहरण के लिए, अमेज़ॅन अमेज़ॅन लम्बरबार्ड गेम एएए इंजन विकसित कर रहा है, जिसका हमने परीक्षण भी किया ।

ऐसा ही एक क्षेत्र इंटरनेट ऑफ थिंग्स (इंटरनेट ऑफ थिंग्स, IoT) है। इस क्षेत्र में विकसित करने के लिए, अमेज़ॅन ने अपने स्वयं के ऑपरेटिंग सिस्टम को लिखने का फैसला किया - और उन्होंने आधार के रूप में फ्रीआरटीओएस कर्नेल लिया।

परिणामी प्रणाली - Amazon FreeRTOS - को "AWS IoT Core या AWS IoT Greengrass" जैसे Amazon Web Services से सुरक्षित रूप से जुड़ने की क्षमता प्रदान करने के रूप में तैनात किया गया है। इस परियोजना का स्रोत कोड गितुब पर संग्रहीत है।

इस लेख में, हम यह जांच करेंगे कि क्या फ्रीआरटीओएस में त्रुटियां हैं, साथ ही साथ अमेज़ॅन से ऑपरेटिंग सिस्टम स्थिर कोड विश्लेषण के मामले में कितना सुरक्षित है।

कैसा था चेक

एक स्वचालित त्रुटि खोज उपकरण का उपयोग करके कोड की जांच की गई थी: पीवीएस-स्टूडियो स्टैटिक कोड विश्लेषक। यह C, C ++, C # और Java में लिखे कार्यक्रमों में त्रुटियों का पता लगाने में सक्षम है।

विश्लेषण शुरू करने से पहले, परियोजना को इकट्ठा करना आवश्यक है - इसलिए मुझे यकीन होगा कि मेरे पास सभी आवश्यक निर्भरताएं हैं और परियोजना के साथ सब कुछ क्रम में है। एक परियोजना को सत्यापित करने के कई तरीके हैं - उदाहरण के लिए, संकलन निगरानी प्रणाली का उपयोग करना। मैंने दृश्य स्टूडियो के लिए प्लग-इन का उपयोग करके विश्लेषण किया - यह अच्छा है कि दोनों परियोजनाओं के रिपॉजिटरी में प्रोजेक्ट फाइलों का एक सेट है जो विंडोज के तहत निर्माण करना आसान बनाता है।

मेरे लिए जो कुछ भी आवश्यक था, वह यह सुनिश्चित करने के लिए परियोजनाओं को इकट्ठा करना था कि सत्यापन के लिए आवश्यक सब कुछ था। अगला, मैंने विश्लेषण और वॉइला लॉन्च किया! - मेरे सामने एक रेडीमेड एनालाइजर रिपोर्ट है।

इन परियोजनाओं में शामिल तृतीय-पक्ष लाइब्रेरी में त्रुटियां भी हो सकती हैं, और वे निश्चित रूप से, कार्यक्रम के संचालन को भी प्रभावित कर सकते हैं। हालांकि, मैंने उन्हें कथन की शुद्धता के लिए विश्लेषण से बाहर रखा।

इसलिए, परियोजनाओं का विश्लेषण किया जाता है, रिपोर्ट प्राप्त की जाती हैं, दिलचस्प त्रुटियां लिखी जाती हैं। यह उनके विश्लेषण पर आगे बढ़ने का समय है!

FreeRTOS को क्या छुपाता है

प्रारंभ में, मुझे दो अलग-अलग लेख लिखने की उम्मीद थी: प्रत्येक ऑपरेटिंग सिस्टम के लिए। मैंने पहले ही अपने हाथों को रगड़ दिया, फ्रीआरटीओएस के बारे में एक अच्छा लेख लिखने की तैयारी की। यहां तक ​​कि रसदार त्रुटियों (जैसे सीडब्ल्यूई -457 ) के एक जोड़े का पता लगाने के लिए, मैंने उत्सुकता से कुछ चेतावनियों को देखा, और ... और कुछ भी नहीं। मुझे कोई दिलचस्प त्रुटि नहीं मिली।

कई चेतावनियाँ जो कि जारी किए गए विश्लेषक FreeRTOS के लिए प्रासंगिक नहीं थीं। उदाहरण के लिए, इस तरह की चेतावनियों में 64-बिट कमियां थीं जैसे कि size_t को uint32_t में डालना । यह इस तथ्य के कारण है कि फ्रीआरटीओएस को 32 बिट्स से अधिक के पॉइंटर आकार वाले उपकरणों पर काम करने के लिए डिज़ाइन किया गया है।

मैंने सभी वी 1027 चेतावनियों को असंबंधित संरचनाओं के संकेतकर्ताओं के बीच जातियों से संबंधित चेकों की जाँच की। यदि Reducible संरचनाओं में एक ही संरेखण होता है, तो ऐसी कास्ट त्रुटि नहीं है। और मुझे एक भी खतरनाक कलाकार नहीं मिला!

अन्य सभी संदिग्ध स्थान या तो कोडिंग शैली से संबंधित थे, या यह बताते हुए एक टिप्पणी से लैस थे कि यह यहाँ क्यों किया गया है और यह एक गलती क्यों नहीं है।

सामान्य तौर पर, मैं FreeRTOS के डेवलपर्स से संपर्क करना चाहता हूं। तुम लोग सचमुच महान हो! हम लगभग स्वच्छ और उच्च गुणवत्ता वाली परियोजनाओं के रूप में कभी नहीं मिले। और मैं साफ, सुव्यवस्थित और अच्छी तरह से प्रलेखित कोड पढ़कर बहुत खुश हुआ। आपको सलाम।

हालांकि मुझे उस दिन कोई दिलचस्प गलती नहीं मिली, मैं समझ गया कि मैं वहां नहीं रुकूंगा। मैं दृढ़ विश्वास के साथ घर जा रहा था कि अमेज़ॅन से 100% संस्करण में कुछ दिलचस्प मिलेगा, और कल मैं निश्चित रूप से लेख के लिए पर्याप्त त्रुटियां एकत्र करूंगा। जैसा कि आपने शायद अनुमान लगाया था, मैं सही था।

Amazon FreeRTOS को क्या छुपाता है

अमेज़ॅन सिस्टम का संस्करण निकला ... इसे हल्के ढंग से, थोड़ा खराब करने के लिए। FreeRTOS की विरासत सिर्फ साफ बनी हुई है, लेकिन नए संशोधन काफी दिलचस्प निकले।

कुछ जगहों पर, कार्यक्रम के तर्क का उल्लंघन किया गया, कहीं न कहीं गलत तरीके से पॉइंटर्स के साथ काम किया गया। कुछ स्थानों पर, कोड अपरिभाषित व्यवहार का कारण बन सकता है, लेकिन कहीं न कहीं प्रोग्रामर को बस उस त्रुटि पैटर्न के बारे में पता नहीं था जो उसने बनाया था। मुझे कुछ गंभीर संभावित कमजोरियां भी मिलीं।

कुछ मैंने परिचय के साथ देर कर दी। चलो कीड़े को पार्स करना शुरू करते हैं!

कार्यक्रम तर्क का उल्लंघन

आइए समस्या क्षेत्रों के साथ शुरू करें, जो स्पष्ट रूप से इंगित करते हैं कि प्रोग्राम ठीक से नहीं चलता है जैसा कि प्रोग्रामर को उम्मीद है। पहली ऐसी जगह एक सरणी के साथ संदिग्ध काम होगी:

/** * @brief Pool of request and associated response buffers, * handles, and configurations. */ static _requestPool_t _requestPool = { 0 }; .... static int _scheduleAsyncRequest(int reqIndex, uint32_t currentRange) { .... /* Set the user private data to use in the asynchronous callback context. */ _requestPool.pRequestDatas[reqIndex].pConnHandle = &_connHandle; _requestPool.pRequestDatas[reqIndex].pConnConfig = &_connConfig; _requestPool.pRequestDatas[reqIndex].reqNum = reqIndex; _requestPool.pRequestDatas[reqIndex].currRange = currentRange; _requestPool.pRequestDatas[reqIndex].currDownloaded = 0; _requestPool.pRequestDatas[reqIndex].numReqBytes = numReqBytes; .... _requestPool.pRequestDatas->scheduled = true; .... } 

PVS-Studio ने इस कोड के लिए दो चेतावनी जारी की:

• V619 सरणी '_requestPool.pRequestDatas' को एकल ऑब्जेक्ट के लिए सूचक के रूप में उपयोग किया जा रहा है। iot_demo_https_s3_download_async.c 973
• V574 '_requestPool.pRequestDatas' पॉइंटर एक सरणी के रूप में और एकल ऑब्जेक्ट के लिए पॉइंटर के रूप में एक साथ उपयोग किया जाता है। चेक लाइनें: 931, 973। iot_demo_https_s3_download_async.c 973

बस मामले में, मुझे आपको याद दिलाना है: सरणी का नाम इसके पहले तत्व के लिए एक संकेतक है। यही है, अगर _requestPool.pRequestDatas संरचनाओं की एक सरणी है, तो _requestPool.pRequestDatas [i] .scheduled सरणी के i- th संरचना के निर्धारित सदस्य तक पहुंच है। और यदि आप _requestPool.pRequestDatas-> शेड्यूल लिखते हैं, तो इसका अर्थ होगा, सरणी की पहली संरचना के निर्धारित सदस्य तक पहुंच।

कोड स्निपेट में ऐसा ही होता है। अंतिम पंक्ति हमेशा सरणी की पहली संरचना के सदस्य के लिए केवल मान को बदलती है। अपने आप से, यह कॉल पहले से ही संदिग्ध है, लेकिन यहां स्थिति और भी स्पष्ट है: फ़ंक्शन के पूरे शरीर में, _requestPool.pRequestDatas सरणी को इंडेक्स द्वारा एक्सेस किया जाता है, और केवल अंत में इंडेक्सिंग ऑपरेशन को लागू करना भूल गया था।

जैसा कि मैंने इसे समझा, अंतिम पंक्ति इस तरह दिखनी चाहिए:

 _requestPool.pRequestDatas[reqIndex].scheduled = true; 

निम्न त्रुटि एक छोटे से फ़ंक्शन में है, इसलिए मैं इसे इसकी संपूर्णता में दूंगा:

 /* Return true if the string " pcString" is found * inside the token pxTok in JSON file pcJson. */ static BaseType_t prvGGDJsoneq( const char * pcJson, const jsmntok_t * const pxTok, const char * pcString ) { uint32_t ulStringSize = ( uint32_t ) pxTok->end - ( uint32_t ) pxTok->start; BaseType_t xStatus = pdFALSE; if( pxTok->type == JSMN_STRING ) { if( ( uint32_t ) strlen( pcString ) == ulStringSize ) { if( ( int16_t ) strncmp( &pcJson[ pxTok->start ], // <= pcString, ulStringSize ) == 0 ) { xStatus = pdTRUE; } } } return xStatus; } 

PVS-Studio चेतावनी: V642 [CWE-197] 'strncmp' फंक्शन रिजल्ट को 'शॉर्ट' टाइप वेरिएबल के अंदर सेव करना अनुचित है। महत्वपूर्ण बिट्स प्रोग्राम के तर्क को तोड़ सकते हैं। aws_greengrass_discovery.c 637

आइए strncmp फ़ंक्शन परिभाषा पर एक नज़र डालें:

 int strncmp( const char *lhs, const char *rhs, size_t count ); 

उदाहरण में, प्रकार int का परिणाम, जिसका आकार 32 बिट है, को int16_t प्रकार के एक चर में परिवर्तित किया जाता है। इस तरह के "संकीर्ण" रूपांतरण के साथ, वापसी मूल्य के सबसे महत्वपूर्ण बिट खो जाएंगे। उदाहरण के लिए, यदि strncmp फ़ंक्शन 0x00010000 देता है, तो रूपांतरण के दौरान एक खो जाएगा, और स्थिति संतुष्ट हो जाएगी।

वास्तव में, इस तरह के कलाकारों को एक हालत में देखना अजीब है। अगर आप शून्य के साथ सामान्य int की तुलना कर सकते हैं तो भी ऐसा क्यों करें? दूसरी ओर, यदि प्रोग्रामर सचेत रूप से फ़ंक्शन को कभी-कभी सच करना चाहता है , भले ही यह नहीं होना चाहिए, तो इस ट्रिकी व्यवहार को टिप्पणी द्वारा वर्णित क्यों नहीं किया जाता है? लेकिन फिर यह पहले से ही एक बुकमार्क है। सामान्य तौर पर, मुझे विश्वास है कि यह एक गलती है। आपको क्या लगता है?

अपरिभाषित व्यवहार और संकेत

अब एक बड़ा उदाहरण होगा। यह एक अशक्त पॉइंटर की संभावित डेरेफेरिंग को छुपाता है:

 static void _networkReceiveCallback(....) { IotHttpsReturnCode_t status = IOT_HTTPS_OK; _httpsResponse_t* pCurrentHttpsResponse = NULL; IotLink_t* pQItem = NULL; .... /* Get the response from the response queue. */ IotMutex_Lock(&(pHttpsConnection->connectionMutex)); pQItem = IotDeQueue_PeekHead(&(pHttpsConnection->respQ)); IotMutex_Unlock(&(pHttpsConnection->connectionMutex)); /* If the receive callback is invoked * and there is no response expected, * then this a violation of the HTTP/1.1 protocol. */ if (pQItem == NULL) { IotLogError(....); fatalDisconnect = true; status = IOT_HTTPS_NETWORK_ERROR; goto iotCleanup; } .... iotCleanup : /* Report errors back to the application. */ if (status != IOT_HTTPS_OK) { if ( pCurrentHttpsResponse->isAsync && pCurrentHttpsResponse->pCallbacks->errorCallback) { pCurrentHttpsResponse->pCallbacks->errorCallback(....); } pCurrentHttpsResponse->syncStatus = status; } .... } 

PVS-Studio चेतावनी: V522 [CWE-690] एक संभावित नल पॉइंटर 'pCurrentHttpsResponse' की डीफ्रेंसिंग हो सकती है। iot_https_client.c 1184

समस्या dereferences बहुत नीचे हैं अगर । देखते हैं कि यहां क्या होता है।

फ़ंक्शन की शुरुआत में, pCurrentHttpsResponse और pQItem वैरिएबल NULL के लिए आरंभीकृत होते हैं , और स्टेटस वैरिएबल IOT_HTTPS_OK ​​के लिए इनिशियलाइज़ किया जाता है , जिसका अर्थ है कि सब कुछ आसानी से हो जाता है।

इसके बाद, pQItem को IotDeQueue_PeekHead फ़ंक्शन से लौटाया गया मान दिया जाता है, जो एक पॉइंटर को दोगुनी कनेक्टेड कतार की शुरुआत में लौटाता है।

यदि कतार खाली है तो क्या होगा? इस स्थिति में, IotDeQueue_PeekHead फ़ंक्शन NULL लौटेगा:

 static inline IotLink_t* IotDeQueue_PeekHead (const IotDeQueue_t* const pQueue) { return IotListDouble_PeekHead(pQueue); } .... static inline IotLink_t* IotListDouble_PeekHead (const IotListDouble_t* const pList) /* @[declare_linear_containers_list_double_peekhead] */ { IotLink_t* pHead = NULL; if (pList != NULL) { if (IotListDouble_IsEmpty(pList) == false) { pHead = pList->pNext; } } return pHead; } 

इसके बाद, स्थिति pQItem == NULL संतुष्ट है, और नियंत्रण प्रवाह गोटो के माध्यम से फ़ंक्शन बॉडी के निचले हिस्से में पहुंचता है। इस समय तक, pCurrentHttpsResponse सूचक शून्य रहेगा, और स्थिति IOT_HTTPS_OK ​​के बराबर नहीं होगी । नतीजतन, हम उस बहुत ही शाखा में गिर जाएंगे अगर , और ... व्यापक! इस डेरेफ्रेंसिंग के परिणाम आप स्वयं जानते हैं।

ठीक है। यह थोड़ा अलंकृत उदाहरण था। अब मैं आपके ध्यान में एक बहुत ही सरल और समझ में आने वाली क्षमता को लाने के लिए आया हूँ:

 int PKI_mbedTLSSignatureToPkcs11Signature (uint8_t * pxSignaturePKCS, uint8_t * pxMbedSignature ) { int xReturn = 0; uint8_t * pxNextLength; /* The 4th byte contains the length of the R component */ uint8_t ucSigComponentLength = pxMbedSignature[ 3 ]; // <= if( ( pxSignaturePKCS == NULL ) || ( pxMbedSignature == NULL ) ) { xReturn = FAILURE; } .... } 

PVS-Studio चेतावनी: V595 [CWE-476] 'pxMbedSignature' पॉइंटर का उपयोग करने से पहले इसे nullptr के खिलाफ सत्यापित किया गया था। चेक लाइनें: 52, 54. iot_pki_utils.c 52

इस फ़ंक्शन को uint8_t पर दो पॉइंटर्स मिलते हैं। दोनों बिंदुओं को NULL के लिए जांचा जाता है , जो अच्छा अभ्यास है - ऐसी स्थितियों पर तुरंत काम किया जाना चाहिए।

लेकिन यहाँ बुरा भाग्य है: समय pxMbedSignature द्वारा जाँच की है, यह पहले से ही शाब्दिक रूप से ऊपर एक पंक्ति dereferenced जाएगा। टा-DAA!

सट्टा कोड का एक और उदाहरण:

 CK_RV vAppendSHA256AlgorithmIdentifierSequence ( uint8_t * x32ByteHashedMessage, uint8_t * x51ByteHashOidBuffer ) { CK_RV xResult = CKR_OK; uint8_t xOidSequence[] = pkcs11STUFF_APPENDED_TO_RSA_SIG; if( ( x32ByteHashedMessage == NULL ) || ( x51ByteHashOidBuffer == NULL ) ) { xResult = CKR_ARGUMENTS_BAD; } memcpy( x51ByteHashOidBuffer, xOidSequence, sizeof( xOidSequence ) ); memcpy( &x51ByteHashOidBuffer[ sizeof( xOidSequence ) ], x32ByteHashedMessage, 32 ); return xResult; } 

पीवीएस-स्टूडियो चेतावनी:

• V1004 [CWE-628] 'x51ByteHashOidBuffer' पॉइंटर का उपयोग अशक्त रूप से उपयोग किए जाने के बाद किया गया था क्योंकि इसे nullptr के खिलाफ सत्यापित किया गया था। जाँच लाइनें: 275, 280. iot_pkcs11.c 280
• V1004 [CWE-628] nullptr के खिलाफ सत्यापित होने के बाद 'x32ByteHashedMessage' पॉइंटर का उपयोग अनिश्चित रूप से किया गया था। चेक लाइनें: 275, 281. iot_pkcs11.c 281

विश्लेषक चेतावनी देता है कि फ़ंक्शन पैरामीटर जो पॉइंटर्स हैं, उन्हें NULL के लिए परीक्षण किए जाने के बाद असुरक्षित रूप से उपयोग किया जाता है । दरअसल, तर्कों की जाँच की जाती है, लेकिन यदि उनमें से कोई भी NULL हो जाता है , तो कोई कार्रवाई नहीं की जाती है, सिवाय xResult के लिखने के। कोड का यह टुकड़ा लगता है: "हाँ, इसका मतलब है कि तर्क खराब हो गए हैं। जब आप जारी रखते हैं, तो हम इसे लिखते रहेंगे।

निचला रेखा: NULL को मेमसीपी में पास किया जाएगा। इससे क्या आ सकता है? मूल्यों की नकल कहां की जाएगी और कौन सी वास्तव में, इसके बारे में अनुमान लगाना इसके लायक नहीं है, क्योंकि मानक स्पष्ट रूप से बताता है कि इस तरह की कॉल से अपरिभाषित व्यवहार होता है (पैराग्राफ 1 देखें)।

विश्लेषक रिपोर्ट में अभी भी पॉइंटर्स के साथ गलत संचालन के उदाहरण शामिल हैं जो मुझे अमेज़ॅन फ्रीआरटीओएस में मिले थे, लेकिन मुझे लगता है कि उपरोक्त त्रुटियां आपको ऐसी त्रुटियों का पता लगाने में पीवीएस-स्टूडियो की क्षमताओं को दिखाने के लिए पर्याप्त हैं। कुछ नया करने पर विचार करें।

सत्य! = १

मुझे मिली कई त्रुटियां एक पैटर्न से संबंधित थीं, जो दुर्भाग्य से, अक्सर भूल जाती हैं।

तथ्य यह है कि बूल प्रकार (C ++ से) BOOL प्रकार (आमतौर पर C में प्रयुक्त) से अलग है। पहला केवल सही या गलत हो सकता है । दूसरा कुछ पूर्णांक प्रकार ( int , long , इत्यादि) का एक प्रकार है। उसके लिए, "असत्य" मान 0 है , और "सत्य" शून्य के अलावा कोई भी मूल्य है।

चूंकि सी में कोई अंतर्निहित बूलियन प्रकार नहीं है, इसलिए इन स्थिरांक को सुविधा के लिए परिभाषित किया गया है:

 #define FALSE 0 #define TRUE 1 

अब एक उदाहरण पर विचार करें:

 int mbedtls_hardware_poll(void* data, unsigned char* output, size_t len, size_t* olen) { int lStatus = MBEDTLS_ERR_ENTROPY_SOURCE_FAILED; HCRYPTPROV hProv = 0; /* Unferenced parameter. */ (void)data; /* * This is port-specific for the Windows simulator, * so just use Crypto API. */ if (TRUE == CryptAcquireContextA( &hProv, NULL, NULL, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT)) { if (TRUE == CryptGenRandom(hProv, len, output)) { lStatus = 0; *olen = len; } CryptReleaseContext(hProv, 0); } return lStatus; } 

पीवीएस-स्टूडियो चेतावनी:

• V676 [CWE-253] TRUE के साथ BOOL प्रकार के चर की तुलना करना गलत है। aws_entropy_hardware_poll.c 48
• V676 [CWE-253] TRUE के साथ BOOL प्रकार के चर की तुलना करना गलत है। सही अभिव्यक्ति है: 'FALSE! = CryptGenRandom (hProv, len, output)'। aws_entropy_hardware_poll.c 51

एक गलती मिली? और यह है :) कार्य CryptAcquireContextA और CryptGenRandom wincrypt.h हैडर से मानक कार्य हैं। यदि सफल होते हैं, तो वे एक गैर-मान लौटाते हैं। मैं जोर देता हूं - गैर - शून्य । तो, सैद्धांतिक रूप से, यह शून्य के अलावा कोई भी मूल्य हो सकता है: 1 , 314 , 42 , 420 ।

जाहिर है, उदाहरण से फ़ंक्शन लिखने वाले प्रोग्रामर ने इसके बारे में नहीं सोचा था, और परिणामस्वरूप, प्राप्त मूल्यों की एकता के साथ तुलना की जाती है।

किस संभावना के साथ स्थिति TRUE == CryptGenRandom (....) पूरी नहीं हुई है? कहना मुश्किल है। हो सकता है कि CryptGenRandom अन्य मूल्यों की तुलना में अधिक बार एक इकाई लौटाता है, और शायद यह हमेशा केवल एक रिटर्न देता है। हम निश्चित रूप से नहीं जान सकते हैं: इस क्रिप्टोग्राफिक फ़ंक्शन का कार्यान्वयन नश्वर प्रोग्रामर की आंखों से छिपा हुआ है :)

यह याद रखना महत्वपूर्ण है कि ऐसी तुलना संभावित रूप से खतरनाक है। और इसके बजाय:

 if (TRUE == GetBOOL()) 

एक सुरक्षित विकल्प का उपयोग करें:

 if (FALSE != GetBOOL()) 

अनुकूलन के मुद्दे

धीमी गति से चलने वाले निर्माणों के साथ कई विश्लेषक चेतावनियाँ जुड़ी हैं। उदाहरण के लिए:

 int _IotHttpsDemo_GetS3ObjectFileSize(....) { .... pFileSizeStr = strstr(contentRangeValStr, "/"); .... } 

PVS-Studio चेतावनी: V817 यह एक स्ट्रिंग के बजाय '/' वर्ण प्राप्त करने के लिए अधिक कुशल है। iot_demo_https_common.c 205

संक्षेप में और स्पष्ट रूप से, यह नहीं है? यहां स्ट्रैस्ट फंक्शन का इस्तेमाल सिर्फ एक कैरेक्टर को खोजने के लिए किया जाता है, जो एक स्ट्रिंग के रूप में पैरामीटर को दिया जाता है (यह दोहरे कोट्स में संलग्न है)।

इस जगह को स्ट्रैच के साथ स्ट्रैस को बदलकर संभावित रूप से अनुकूलित किया जा सकता है:

 int _IotHttpsDemo_GetS3ObjectFileSize(....) { .... pFileSizeStr = strchr(contentRangeValStr, '/'); .... } 

फिर खोज थोड़ी तेजी से काम करेगी। एक तिपहिया, लेकिन अच्छा है।

इस तरह के अनुकूलन, निश्चित रूप से, अच्छे हैं, और विश्लेषक ने एक और स्थान पाया है जिसे बहुत अधिक ध्यान से अनुकूलित किया जा सकता है:

 void vRunOTAUpdateDemo(void) { .... for (; ; ) { .... xConnectInfo.cleanSession = true; xConnectInfo.clientIdentifierLength = (uint16_t)strlen(clientcredentialIOT_THING_NAME); xConnectInfo.pClientIdentifier = clientcredentialIOT_THING_NAME; .... } } 

चेतावनी PVS-Studio: V814 प्रदर्शन में कमी। लूप के शरीर के अंदर 'स्ट्रैलेन' फ़ंक्शन को कई बार कहा जाता था। aws_iot_ota_update_demo.c 235

हम्मम ... लूप के अंदर, प्रत्येक पुनरावृत्ति पर, स्ट्रलेन को कहा जाता है, जो प्रत्येक बार एक ही पंक्ति की लंबाई की गणना करता है। सबसे कुशल ऑपरेशन नहीं :)

चलिए एक नज़र डालते हैं clientcredentialIOT_THING_NAME की परिभाषा पर:

 /* * @brief Host name. * * @todo Set this to the unique name of your IoT Thing. */ #define clientcredentialIOT_THING_NAME "" 

उपयोगकर्ता को यहां अपने डिवाइस का नाम दर्ज करने के लिए कहा जाता है। डिफ़ॉल्ट रूप से, यह खाली है, और इस मामले में, सब कुछ ठीक है। लेकिन क्या होगा अगर उपयोगकर्ता वहां कुछ लंबा और सुंदर नाम दर्ज करना चाहता है? उदाहरण के लिए, मैं अपने दिमाग की उपज " द पैशनेट और परिष्कृत कॉफी मशीन BarBarista-N061E अंतिम संस्करण " को कॉल करना पसंद करूंगा । क्या आप सोच सकते हैं कि अगर मेरी सुंदर कॉफी मशीन थोड़ा धीमा काम करने लगे तो मेरा आश्चर्य क्या होगा? विकार!

त्रुटि को ठीक करने के लिए, स्ट्रॉपल को लूप बॉडी से बाहर निकाला जाना चाहिए। आखिरकार, प्रोग्राम चलने के दौरान डिवाइस का नाम नहीं बदलता है। Ehhh, यहाँ C ++ से constexpr होगा ...

ठीक है, ठीक है, मैं मानता हूं: यहां मैं थोड़ा मोटा हो गया था। जैसा कि मेरे सहयोगी आंद्रेई कारपोव ने उल्लेख किया है, आधुनिक संकलक जानते हैं कि स्ट्रलेन क्या है और उन्होंने व्यक्तिगत रूप से देखा कि कैसे वे बाइनरी कोड में एक स्थिरांक का उपयोग करते हैं यदि वे समझते हैं कि एक स्ट्रिंग की लंबाई नहीं बदल सकती है। इसलिए एक उच्च संभावना है कि रिलीज़ संस्करण के बिल्ड मोड में, स्ट्रिंग लंबाई की वास्तविक गणना के बजाय, पहले से गणना की गई मान का उपयोग किया जाएगा। हालांकि, यह हमेशा काम नहीं करता है, इसलिए इस तरह के कोड लिखना एक अच्छा अभ्यास नहीं है।

MISRA के बारे में कुछ शब्द

PVS-Studio विश्लेषक के पास नियमों का एक बड़ा समूह है जो आपको MISRA C और MISRA C ++ मानकों के अनुपालन के लिए अपने कोड की जांच करने की अनुमति देता है। ये मानक क्या हैं?

MISRA अत्यधिक उत्तरदायी एम्बेडेड सिस्टम के लिए कोडिंग मानक है। इसमें कोड लिखने और विकास प्रक्रिया स्थापित करने के लिए सख्त नियमों और दिशानिर्देशों का एक सेट शामिल है। इनमें से काफी कुछ नियम हैं, और उनका उद्देश्य न केवल गंभीर त्रुटियों को खत्म करना है, बल्कि विभिन्न "कोड गंध" के साथ-साथ सबसे अधिक समझने योग्य और पठनीय कोड लिखना भी है।

इस प्रकार, MISRA मानक का पालन करने से न केवल त्रुटियों और कमजोरियों से बचने में मदद मिलती है, बल्कि महत्वपूर्ण रूप से - काफी! - एक मौजूदा कोड में उनकी घटना की संभावना को कम।

MISRA का उपयोग एयरोस्पेस, चिकित्सा, मोटर वाहन और सैन्य उद्योगों में किया जाता है - जहां मानव जीवन एम्बेडेड सॉफ्टवेयर की गुणवत्ता पर निर्भर करता है।

जाहिर है, अमेज़न फ्रीआरटीओएस डेवलपर्स इस मानक के बारे में जानते हैं, और अधिकांश भाग के लिए इसका पालन करते हैं। यह सही है: यदि आप एम्बेडेड सिस्टम के लिए एक व्यापक-आधारित ओएस लिख रहे हैं, तो आपको सुरक्षा के बारे में सोचना चाहिए।

हालाँकि, मुझे MISRA मानक के कुछ उल्लंघन दिखाई दिए। मैं यहां नियमों का उदाहरण नहीं दूंगा जैसे कि "संघ का उपयोग न करें" या "एक समारोह में शरीर के अंत में केवल एक रिटर्न होना चाहिए" - दुर्भाग्य से, वे शानदार नहीं हैं, जैसे कि अधिकांश मीसा नियम। मैं आपको उन उल्लंघनों का बेहतर उदाहरण देता हूं जो संभावित रूप से गंभीर परिणामों का कारण बन सकते हैं।

मैक्रों के साथ शुरू करते हैं:

 #define FreeRTOS_ms_to_tick(ms) ( ( ms * configTICK_RATE_HZ + 500 ) / 1000 ) 

 #define SOCKETS_htonl( ulIn ) ( ( uint32_t ) \ ( ( ( ulIn & 0xFF ) << 24 ) | ( ( ulIn & 0xFF00 ) << 8 ) \ | ( ( ulIn & 0xFF0000 ) >> 8 ) | ( ( ulIn & 0xFF000000 ) >> 24 ) ) ) 

 #define LEFT_ROTATE( x, c ) ( ( x << c ) | ( x >> ( 32 - c ) ) ) 

पीवीएस-स्टूडियो चेतावनी:

• V2546 [MISRA C 20.7] मैक्रो और उसके मापदंडों को कोष्ठक में संलग्न किया जाना चाहिए। 'FreeRTOS_ms_to_tick' मैक्रो के 'ms' पैरामीटर का निरीक्षण करने पर विचार करें। FreeRTOS_IP.h 201
• V2546 [MISRA C 20.7] मैक्रो और उसके मापदंडों को कोष्ठक में संलग्न किया जाना चाहिए। 'SOCKETS_htonl' मैक्रो के 'ulIn' पैरामीटर का निरीक्षण करने पर विचार करें। iot_secure_sockets.h 512
• V2546 [MISRA C 20.7] मैक्रो और उसके मापदंडों को कोष्ठक में संलग्न किया जाना चाहिए। 'LEFT_ROTATE' मैक्रो के निरीक्षण पैरामीटर 'x', 'c' पर विचार करें। iot_device_metrics.c 90

हां, यह वही है जो आपने सोचा था। इन मैक्रोज़ के पैरामीटर कोष्ठक में नहीं लिपटे हैं। अगर कोई गलती से कुछ ऐसा लिख ​​देता है

 val = LEFT_ROTATE(A[i] | 1, B); 

तब ऐसा "कॉल" मैक्रो खुलेगा:

 val = ( ( A[i] | 1 << B ) | ( A[i] | 1 >> ( 32 - B ) ) ); 

संचालन की प्राथमिकताएं याद रखें? सबसे पहले, एक बिटवाइज़ शिफ्ट किया जाता है, और उसके बाद ही बिटवाइज़ "या" होता है। इसलिए, कार्यक्रम के तर्क का उल्लंघन किया जाएगा। एक सरल उदाहरण: क्या होता है अगर एक्सप्रेशन " x + y " को FreeRTOS_ms_to_tick मैक्रो को पास किया जाता है? MISRA का एक मुख्य लक्ष्य ऐसी स्थितियों की घटना को रोकना है।

किसी को आपत्ति हो सकती है: "यदि आपके पास ऐसे प्रोग्रामर हैं जो इस बारे में नहीं जानते हैं, तो कोई भी मानक आपको नहीं बचाएगा!" और मैं इसके लिए सहमत नहीं होगा। प्रोग्रामर भी लोग हैं, और कोई फर्क नहीं पड़ता कि कोई व्यक्ति कितना अनुभवी है, वह भी थक सकता है और कार्य दिवस के अंत में गलती कर सकता है। यह एक कारण है कि MISRA दृढ़ता से मानक के अनुपालन के लिए एक परियोजना को मान्य करने के लिए स्वचालित विश्लेषण उपकरणों के उपयोग की सिफारिश करता है।

मैं Amazon FreeRTOS के डेवलपर्स की ओर मुड़ता हूं: पीवीएस-स्टूडियो ने 12 और असुरक्षित मैक्रोज़ पाए, इसलिए आप इसके साथ अधिक सावधान रहते हैं :)

एक और दिलचस्प MISRA उल्लंघन:

 /** * @brief Callback for an asynchronous request to notify * that the response is complete. * * @param[in] 0pPrivData - User private data configured * with the HTTPS Client library request configuration. * @param[in] respHandle - Identifier for the current response finished. * @param[in] rc - Return code from the HTTPS Client Library * signaling a possible error. * @param[in] status - The HTTP response status. */ static void _responseCompleteCallback(void* pPrivData, IotHttpsResponseHandle_t respHandle, IotHttpsReturnCode_t rc, uint16_t status) { bool* pUploadSuccess = (bool*)pPrivData; /* When the remote server response with 200 OK, the file was successfully uploaded. */ if (status == IOT_HTTPS_STATUS_OK) { *pUploadSuccess = true; } else { *pUploadSuccess = false; } /* Post to the semaphore that the upload is finished. */ IotSemaphore_Post(&(_uploadFinishedSem)); } 

क्या आप स्वयं त्रुटि पा सकते हैं?

PVS-Studio चेतावनी: V2537 [MISRA C 2.7] कार्यों का अप्रयुक्त पैरामीटर नहीं होना चाहिए। पैरामीटर का निरीक्षण करने पर विचार करें: 'आरसी'। iot_demo_https_s3_upload_async.c 234

एक करीब देखो: फ़ंक्शन बॉडी में कहीं भी आरसी पैरामीटर का उपयोग नहीं किया जाता है। इसके अलावा, फ़ंक्शन पर टिप्पणी में यह स्पष्ट रूप से लिखा गया है कि यह पैरामीटर किसी अन्य फ़ंक्शन का रिटर्न कोड है, और यह एक त्रुटि का संकेत दे सकता है। फिर इस पैरामीटर को किसी भी तरह से संसाधित क्यों नहीं किया जाता है? यहाँ स्पष्ट रूप से कुछ गड़बड़ है।

हालांकि, ऐसी टिप्पणियों के बिना भी, अप्रयुक्त पैरामीटर अक्सर टूटे हुए प्रोग्राम लॉजिक का संकेत देते हैं। अन्यथा, फ़ंक्शन हस्ताक्षर में उनकी आवश्यकता क्यों है?

यहां मैंने एक छोटा सा फ़ंक्शन दिया है जो लेख में एक उदाहरण के लिए अच्छी तरह से अनुकूल है। उसके अलावा, मुझे 10 और अप्रयुक्त पैरामीटर मिले। उनमें से कई का उपयोग बड़े कार्यों में किया जाता है, और उन्हें ढूंढना सबसे आसान काम नहीं है।

यह संदिग्ध है कि वे पहले नहीं पाए गए थे। दरअसल, कंपाइलर ऐसे मामलों का आसानी से पता लगा सकते हैं।

निष्कर्ष

ये सभी विश्लेषक द्वारा पाए जाने वाले समस्या क्षेत्र नहीं थे, लेकिन लेख पहले से ही काफी बड़ा था। मुझे उम्मीद है कि इसके लिए धन्यवाद, अमेज़न फ्रीआरटीओएस डेवलपर्स कुछ कमियों को ठीक करने में सक्षम होंगे, और शायद पीवीएस-स्टूडियो को भी अपने दम पर आज़माना चाहते हैं। इस तरह, चेतावनी को अधिक अच्छी तरह से अध्ययन करना संभव होगा, और वास्तव में, एक सुविधाजनक इंटरफ़ेस के साथ काम करना टेक्स्ट रिपोर्ट को देखने की तुलना में बहुत आसान है।

हमारे लेख पढ़ने के लिए धन्यवाद! अगले अंक में मिलते हैं: D

PS यह सिर्फ इतना हुआ कि यह लेख 31 अक्टूबर को प्रकाशित किया गया था। इसलिए, मैं हर किसी को एक खुश हेलोवीन चाहता हूं!

यदि आप इस लेख को अंग्रेजी बोलने वाले दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद के लिंक का उपयोग करें: जॉर्ज ग्रिबकोव। एंबेडेड डेवलपर्स के अनुरोध पर: अमेज़ॅन फ्रीआरटीओएस में त्रुटियों का पता लगाना ।