एंबेडेड डेवलपर्स के अनुरोध पर: अमेज़ॅन फ्रीआरटीओएस में त्रुटियों का पता लगाना

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

संक्षेप में परियोजनाओं के बारे में

शुरू करने के लिए, मैं आपको परीक्षण किए जा रहे प्रोजेक्ट के अग्रदूत के बारे में थोड़ा बताऊंगा - फ्रीआरटीओएस (स्रोत कोड लिंक द्वारा यहां उपलब्ध है)। विकिपीडिया राज्यों के अनुसार, FreeRTOS एम्बेडेड सिस्टम के लिए एक वास्तविक समय मल्टीटास्किंग ऑपरेटिंग सिस्टम है।

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

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

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

परिणामी प्रणाली, Amazon FreeRTOS, "AWS IoT Core या AWS IoT Greengrass जैसे Amazon Web Services को एक सुरक्षित कनेक्शन प्रदान करने के लिए" तैनात है। इस परियोजना का स्रोत कोड जीथब पर उपलब्ध है।

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

चेक का कोर्स

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

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

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

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

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

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

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

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

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

अन्य सभी संदिग्ध स्थान या तो कोडिंग शैली से जुड़े थे या एक टिप्पणी के साथ कर्मचारी थे जो यह समझाते थे कि ऐसा क्यों किया गया था और यह एक गलती क्यों नहीं थी।

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

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

Amazon 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 सरणी सर्वर के अनुसूचित सदस्य के लिए एक आकलन है। और अगर हम _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 देता है, तो रूपांतरण के दौरान इकाई खो जाएगी, और स्थिति निष्पादित हो जाएगी।

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

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

यहाँ एक बड़ा उदाहरण आता है। यह एक संभावित अशक्त सूचक को कवर करता है:

 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

आखिरी अगर ब्लॉक में समस्याग्रस्त डीरेफेरेंस होते हैं। आइए जानें कि यहां क्या हो रहा है।

फ़ंक्शन 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 ​​के बराबर नहीं होगी। अंत में, हम उसी के पास पहुँचेंगे यदि शाखा, और ... बूम! ठीक है, आप इस तरह के एक dereference के परिणामों के बारे में जानते हैं।

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

 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 द्वारा जाँच की जाती है, यह पहले से ही शाब्दिक रूप से एक पंक्ति से ऊपर का होगा। टा-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 अन्य मूल्यों की तुलना में 1 अधिक बार लौट सकता है, लेकिन हो सकता है कि यह केवल 1 ही लौटे। हम यह सुनिश्चित करने के लिए नहीं जान सकते: इस क्रिप्टोग्राफिक फ़ंक्शन का कार्यान्वयन नश्वर प्रोग्रामर की आँखों से छिपा है :)

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

 if (TRUE == GetBOOL()) 

कोड के सुरक्षित संस्करण का उपयोग करें:

 if (FALSE != GetBOOL()) 

अनुकूलन समस्याओं

विश्लेषक की कई चेतावनियाँ धीरे-धीरे संचालन संरचनाओं से संबंधित थीं। उदाहरण के लिए:

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

पीवीएस-स्टूडियो चेतावनी: 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; .... } } 

पीवीएस-स्टूडियो चेतावनी: 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 अंतिम संस्करण को कॉल करना पसंद करूंगा ।" क्या आप सोच सकते हैं कि अगर मेरी खूबसूरत कॉफी मशीन उसके बाद थोड़ी धीमी गति से काम करने लगे तो मेरा आश्चर्य कैसा होगा? उपद्रव!

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

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

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

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

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

इस प्रकार, निम्नलिखित 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 के डेवलपर्स को संबोधित करने दें: PVS-Studio ने 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 अन्य अप्रयुक्त पैरामीटर मिले। उनमें से कई का उपयोग बड़े कार्यों में किया जाता है, और उनका पता लगाना आसान नहीं है।

संदेह से, वे पहले नहीं मिला है। आखिरकार, कंपाइलर ऐसे मामलों का आसानी से पता लगा लेते हैं।

निष्कर्ष

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

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

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