👨‍👦‍👦 🧗 🤳🏿 ग्लिब्क लाइब्रेरी टेस्ट प्रयोग ♦️ 👉🏾 👩🏻‍💼

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

glibc

glibc - GNU C लाइब्रेरी (GNU लाइब्रेरी)। Glibc एक C लाइब्रेरी है जो सिस्टम कॉल और बेसिक फंक्शन जैसे ओपन, मॉलोक, प्रिंटफ आदि उपलब्ध कराता है। सी लाइब्रेरी का उपयोग सभी गतिशील रूप से जुड़े कार्यक्रमों के लिए किया जाता है। यह GNU ऑपरेटिंग सिस्टम के लिए Free Software Foundation द्वारा लिखा गया है। glibc को GNU LGPL लाइसेंस के तहत जारी किया गया है।

विकिपीडिया से अनुकूलित: glibc ।

बहुत समय पहले ऐसा नहीं था, इंटरनेट पर समाचार दिखाई दिए कि ग्लिबैक लाइब्रेरी का एक नया संस्करण जारी किया गया था। इसने हमें अपने पीवीएस-स्टूडियो विश्लेषक का उपयोग करके इस पुस्तकालय का परीक्षण करने के लिए प्रेरित किया। अर्थात्, glibc-2-19-90 संस्करण की जाँच की गई। दुर्भाग्य से, कुछ हफ़्ते के लिए मैं विचलित हो गया था, इसलिए मुझे अब केवल एक लेख लिखने का समय मिला। मैं कई स्थिर विश्लेषणकर्ताओं की एक बड़ी तुलना के साथ व्यस्त था। यह हमारे लिए बहुत महत्वपूर्ण कार्य है क्योंकि वे यह पूछना बंद नहीं करते हैं कि हम Cppcheck और Visual Studio 2013 में स्थिर विश्लेषक से बेहतर क्या हैं। इसलिए, glibc को थोड़ा इंतजार करना पड़ा।

हमने कुछ भयानक खोजने की उम्मीद नहीं की और वास्तव में नहीं मिला। ग्लिब्स लाइब्रेरी बहुत उच्च गुणवत्ता और कई पार्सर्स द्वारा सत्यापित है। कम से कम, ये हैं:

Coverity;
बजना;
Cppcheck।

इसलिए कम से कम कुछ खोजना पहले से ही एक बड़ी उपलब्धि है।

विश्लेषण की जटिलता क्या है

स्थैतिक विश्लेषण उपकरणों की आंतरिक रसोई से अपरिचित, वे बहुत सरल उपयोगिताओं की तरह लगते हैं। ऐसा नहीं है। ये बहुत जटिल कार्यक्रम हैं।

RATS जैसे उपकरण भ्रामक हो सकते हैं । अगर किसी ने RATS कोड को देखा, तो उन्होंने देखा कि यह फाइलों में विशिष्ट फ़ंक्शन नामों के लिए एक खोज थी। इस टूल को स्टैटिक कोड एनालाइज़र भी कहा जाता है। हालांकि, यह वास्तविक कोड एनालाइजर से बहुत दूर है। स्थैतिक विश्लेषण नियमित अभिव्यक्ति के साथ एक खोज नहीं है [ 1 ]।

हम बार-बार दोहराते हैं कि लिनक्स संस्करण एक पुन: निष्पादित निष्पादन योग्य मॉड्यूल [ 2 ] के समान नहीं है। निष्पादन योग्य मॉड्यूल और सॉफ्टवेयर उत्पाद के बीच एक अंतर है। बाधाओं में से एक विशिष्ट एक्सटेंशन और जैसे के लिए समर्थन है।

यह क्या है, एक तृतीय-पक्ष व्यक्ति पूरी तरह से समझ से बाहर है। यहां से देखता है, strcmp () फ़ंक्शन के प्रोग्राम कॉल में:

cmpres = strcmp (newp->from_string, root->from_string);

और उसे यह भी संदेह नहीं है कि यह लाइन प्रीप्रोसेसिंग के बाद किस डरावनी स्थिति को प्रकट कर सकती है और गैर-मानक एक्सटेंशन का उपयोग किया जाएगा। विशेष रूप से, हमारे मामले में, स्ट्रिंग इस में बदल जाती है:

 cmpres = __extension__ ({ size_t __s1_len, __s2_len; (__builtin_constant_p (newp->from_string) && __builtin_constant_p (root->from_string) && (__s1_len = strlen (newp->from_string), __s2_len = strlen (root->from_string), (!((size_t)(const void *)((newp->from_string) + 1) - (size_t)(const void *)(newp->from_string) == 1) || __s1_len >= 4) && (!((size_t)(const void *)((root->from_string) + 1) - (size_t)(const void *)(root->from_string) == 1) || __s2_len >= 4)) ? __builtin_strcmp (newp->from_string, root->from_string) : (__builtin_constant_p (newp->from_string) && ((size_t)(const void *)((newp->from_string) + 1) - (size_t)(const void *)(newp->from_string) == 1) && (__s1_len = strlen (newp->from_string), __s1_len < 4) ? (__builtin_constant_p (root->from_string) && ((size_t)(const void *)((root->from_string) + 1) - (size_t)(const void *)(root->from_string) == 1) ? __builtin_strcmp (newp->from_string, root->from_string) : (__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const char *) (root->from_string); int __result = (((const unsigned char *) (const char *) (newp->from_string))[0] - __s2[0]); if (__s1_len > 0 && __result == 0) { __result = (((const unsigned char *) (const char *) (newp->from_string))[1] - __s2[1]); if (__s1_len > 1 && __result == 0) { __result = (((const unsigned char *) (const char *) (newp->from_string))[2] - __s2[2]); if (__s1_len > 2 && __result == 0) __result = (((const unsigned char *) (const char *) (newp->from_string))[3] - __s2[3]); } } __result; }))) : (__builtin_constant_p (root->from_string) && ((size_t)(const void *)((root->from_string) + 1) - (size_t)(const void *)(root->from_string) == 1) && (__s2_len = strlen (root->from_string), __s2_len < 4) ? (__builtin_constant_p (newp->from_string) && ((size_t)(const void *)((newp->from_string) + 1) - (size_t)(const void *)(newp->from_string) == 1) ? __builtin_strcmp (newp->from_string, root->from_string) : (- (__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const char *) (newp->from_string); int __result = (((const unsigned char *) (const char *) (root->from_string))[0] - __s2[0]); if (__s2_len > 0 && __result == 0) { __result = (((const unsigned char *) (const char *) (root->from_string))[1] - __s2[1]); if (__s2_len > 1 && __result == 0) { __result = (((const unsigned char *) (const char *) (root->from_string))[2] - __s2[2]); if (__s2_len > 2 && __result == 0) __result = (((const unsigned char *) (const char *) (root->from_string))[3] - __s2[3]); } } __result; })))) : __builtin_strcmp (newp->from_string, root->from_string)))); });

विश्लेषक घटनाओं के ऐसे मोड़ के लिए तैयार नहीं है और कभी-कभी इस तरह के निर्माणों पर अर्थहीन झूठे संदेश पैदा करता है।

मैं एक सरल उदाहरण में झूठे संदेशों के बारे में समझाऊंगा। मान लें कि हमारे पास कोड की एक पंक्ति है:

 assert(MAP_FAILED == (void *) -1);

मुखर () मैक्रो निम्नलिखित कोड में फैलता है:

 ((((void *) -1) == (void *) -1) ? (void) (0) : __assert_fail ("((void *) -1) == (void *) -1", "loadmsgcat.c", 840, __PRETTY_FUNCTION__));

PVS-Studio विश्लेषक तुलना ((शून्य *) -1) == (शून्य * -1.1) के संबंध में गलत चेतावनी देता है:

V501 बाईं और '==' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ हैं: ((शून्य *) - 1) == (शून्य *) - 1 loadmsgcat.c 840

हमें इस पर आश्चर्य नहीं है। विजुअल C ++ का उपयोग करके निर्मित कार्यक्रमों के लिए विकसित करते समय हम पहले ही इस सब से गुजर चुके थे। वहाँ भी दिलचस्प और असामान्य के सभी प्रकार की एक बहुत कुछ है। विश्लेषक को यह समझने के लिए बहुत काम करने की ज़रूरत है कि क्या है। आपको उसे यह समझने के लिए सिखाने की ज़रूरत है कि वह "मुखर" मैक्रो के साथ काम कर रहा है जो हानिरहित है और बस जाँचता है कि MAP_FAILED मैक्रो "(शून्य *) -1" है। यह सब विजुअल C ++ के लिए पहले ही किया जा चुका है। लेकिन लिनक्स के लिए, नहीं।

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

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

संदिग्ध कोड के टुकड़े मिले

यद्यपि ग्लिबक परियोजना का परीक्षण कई उपकरणों द्वारा किया जा रहा है, फिर भी कुछ दिलचस्प खोजना संभव था। आइए कोड के इन वर्गों को देखें।

अजीब अभिव्यक्ति

 char *DCIGETTEXT (....) { .... /* Make CATEGORYVALUE point to the next element of the list. */ while (categoryvalue[0] != '\0' && categoryvalue[0] == ':') ++categoryvalue; .... }

V590 इस अभिव्यक्ति का निरीक्षण करने पर विचार करें। अभिव्यक्ति अत्यधिक है या एक गलत चित्रण है। dcigettext.c 582

स्थिति को सरल बनाया जा सकता है:

 while (categoryvalue[0] == ':')

शायद यह कोई गलती नहीं है और हालत का पहला भाग (श्रेणीवार [0]! = '\ 0') केवल अतिशयोक्तिपूर्ण है। हालाँकि, इसे अचानक इस तरह लिखा जाना चाहिए:

 while (categoryvalue[0] != '\0' && categoryvalue[0] != ':')

सत्यापन से पहले सूचक का कहना है

जरूरी नहीं कि यह जगह खतरनाक हो। शायद सूचक कभी शून्य नहीं हो सकता। लेकिन फिर भी:

 static enum clnt_stat clntraw_call (h, proc, xargs, argsp, xresults, resultsp, timeout) CLIENT *h; u_long proc; xdrproc_t xargs; caddr_t argsp; xdrproc_t xresults; caddr_t resultsp; struct timeval timeout; { struct clntraw_private_s *clp = clntraw_private; XDR *xdrs = &clp->xdr_stream; .... if (clp == NULL) return RPC_FAILED; .... }

V595 'clp' पॉइंटर को nullptr के खिलाफ सत्यापित होने से पहले उपयोग किया गया था। चेक लाइनें: 145, 150. clnt_raw.c 145

इस फ़ाइल में एक समान दोष अगले देखा जा सकता है: V595 nullrr के खिलाफ सत्यापित होने से पहले 'clp' पॉइंटर का उपयोग किया गया था। चेक लाइनें: 232, 235. clnt_raw.c 232

खतरनाक कोड का एक और उदाहरण:

 int __nss_getent_r (....) { .... if (res && __res_maybe_init (&_res, 0) == -1) { *h_errnop = NETDB_INTERNAL; *result = NULL; return errno; } .... if (status == NSS_STATUS_TRYAGAIN && (h_errnop == NULL || *h_errnop == NETDB_INTERNAL) && errno == ERANGE) }

V595 nullptr के खिलाफ सत्यापित होने से पहले 'h_errnop' पॉइंटर का उपयोग किया गया था। चेक लाइनें: 146, 172. getnssent_r.c 146

यदि स्थिति (res && __res_maybe_init (& _res, 0) == -1) संतुष्ट है, तो फ़ंक्शन त्रुटि के बारे में जानकारी देता है। ऐसा करने पर, यह 'h_errnop' और 'परिणाम' बिंदुओं को संदर्भित करता है। हालाँकि, ये संकेत अच्छी तरह से NULL हो सकते हैं। नीचे दिए गए कोड की जांच करके यह निष्कर्ष निकाला जा सकता है।

खतरनाक अनुकूलन (भेद्यता)

 char * __sha256_crypt_r (key, salt, buffer, buflen) const char *key; const char *salt; char *buffer; int buflen; { .... unsigned char temp_result[32] .... memset (temp_result, '\0', sizeof (temp_result)); .... .... // temp_result    }

V597 संकलक 'मेमसेट' फ़ंक्शन कॉल को हटा सकता है, जिसका उपयोग 'temp_result' बफर को फ्लश करने के लिए किया जाता है। RtlSecureZeroMemory () फ़ंक्शन का उपयोग निजी डेटा को मिटाने के लिए किया जाना चाहिए। sha256-crypt.c 385

रिलीज संस्करण को संकलित करते समय कंपाइलर को मेमसेट () फ़ंक्शन कॉल को हटाने का अधिकार है। अधिक सटीक रूप से, वह न केवल कानून में है, बल्कि अनुकूलन करने के लिए भी ऐसा करने के लिए बाध्य है। बफर 'temp_result' का उपयोग मेमसेट () फ़ंक्शन को कॉल करने के बाद कहीं भी नहीं किया जाता है, इसलिए, फ़ंक्शन कॉल स्वयं भी बहुत उपयोगी है।

हम एक भेद्यता के साथ काम कर रहे हैं क्योंकि निजी डेटा को मंजूरी नहीं दी जाएगी। मेमसेट () फ़ंक्शन को अधिक उपयुक्त एक के साथ बदला जाना चाहिए। विश्लेषक RtlSecureZeroMemory () प्रदान करता है, जो निश्चित रूप से लिनक्स में नहीं है। लेकिन एनालॉग हैं।

इसी तरह की स्थिति: V597 संकलक 'मेमसेट' फ़ंक्शन कॉल को हटा सकता है, जिसका उपयोग 'temp_result' बफर को फ्लश करने के लिए किया जाता है। RtlSecureZeroMemory () फ़ंक्शन का उपयोग निजी डेटा को मिटाने के लिए किया जाना चाहिए। sha512-crypt.c 396

अपरिभाषित व्यवहार

ऐसा लगता है कि ग्लिब्क लाइब्रेरी को यथासंभव पोर्टेबल लिखा जाना चाहिए। हालाँकि, हम इसे कई कतरनी निर्माणों में पाते हैं जिन्हें पोर्टेबिलिटी के दृष्टिकोण से सुरक्षित नहीं कहा जा सकता है।

यहाँ क्या पाली पर सी मानक हमें बताता है:

पूर्णांक प्रोन्नति प्रत्येक ऑपरेंड पर की जाती है। परिणाम का प्रकार पदोन्नत बाएं ऑपरेंड है। यदि सही ऑपरेंड का मान नकारात्मक है या पदोन्नत किए गए बाएं ऑपरेंड की चौड़ाई के बराबर या उससे अधिक है, तो व्यवहार अपरिभाषित है।

E1 << E2 का परिणाम E1 वाम-शिफ्ट किया गया E2 सा स्थान है; खाली बिट्स शून्य से भरे हुए हैं। यदि E1 में एक अहस्ताक्षरित प्रकार है, तो परिणाम का मूल्य E1 * 2 pow E2 है, परिणाम प्रकार में अधिकतम मूल्य प्रतिनिधित्व योग्य से एक से कम modulo। यदि E1 में एक हस्ताक्षरित प्रकार और नॉनगेटिव मूल्य है, और E1 * 2 pow E2 परिणाम प्रकार में प्रतिनिधित्व करने योग्य है, तो यह परिणामी मूल्य है; अन्यथा, व्यवहार अपरिभाषित है।

5 E1 >> E2 का परिणाम E1 सही-स्थानांतरित E2 बिट स्थिति है। यदि E1 में एक अहस्ताक्षरित प्रकार है या यदि E1 में एक हस्ताक्षरित प्रकार और एक नॉनगेटिव मूल्य है, तो परिणाम का मूल्य E1 / 2 pow E2 के भागफल का अभिन्न अंग है। यदि ई 1 में एक हस्ताक्षरित प्रकार और एक नकारात्मक मूल्य है, तो परिणामस्वरूप मूल्य कार्यान्वयन-परिभाषित है।

यह मानक से निम्नानुसार है कि नकारात्मक संख्याओं को स्थानांतरित करना गलत है। हालाँकि, यह glibc लाइब्रेरी में एक बहुत ही सामान्य ऑपरेशन है।

वाम पाली उदाहरण:

 static void init_cacheinfo (void) { .... count_mask = ~(-1 << (count_mask + 1)); .... }

V610 अपरिभाषित व्यवहार। शिफ्ट ऑपरेटर की जाँच करें <<। बायां संचालक '-1' ऋणात्मक है। cacheinfo.c 645

राइट शिफ्ट उदाहरण:

 utf8_encode (char *buf, int val) { .... *buf = (unsigned char) (~0xff >> step); .... }

अभिव्यक्ति "~ 0xff" प्रकार 'int' और is -256 है।

यहाँ उन सभी स्थानों की सूची दी गई है जहाँ आप गलत बदलाव देख सकते हैं:

strxfrm_l.c 68
clock_nanosleep.c 38
ifaddrs.c 786
xdr_intXX_t.c 35
xdr_intXX_t.c 41
निजी.ह 327
निजी.ह 331
zic.c 696
zdump.c 212
zdump.c 216
Tim_create.c 47
टाइमर_क्रिएट। 49
पाश ३३१ 33
लूप। ४३.c
mktime.c 207
mktime.c 208
mktime.c 211
mktime.c 212
mktime.c 230
mktime.c 298
mktime.c 298
ld-collate.c 298

एक uninitialized वैरिएबल का उपयोग करना

 static int send_vc(....) { .... int truncating, connreset, resplen, n; .... #ifdef _STRING_ARCH_unaligned *anssizp2 = orig_anssizp - resplen; *ansp2 = *ansp + resplen; #else .... } V614 Uninitialized variable 'resplen' used. res_send.c 790

गलत स्ट्रिंग स्वरूपण

कुछ स्थानों पर, हस्ताक्षरित चर मुद्रित करने के लिए '% u' का उपयोग किया जाता है। कुछ स्थानों पर, अहस्ताक्षरित चर को मुद्रित करने के लिए '% d' का उपयोग किया जाता है। ये बेशक trifles हैं, लेकिन वे भी ध्यान देने योग्य हैं।

एक उदाहरण:

 typedef unsigned int __uid_t; typedef __uid_t uid_t; int user2netname (...., const uid_t uid, ....) { .... sprintf (netname, "%s.%d@%s", OPSYS, uid, dfltdom); .... }

V576 गलत प्रारूप। 'स्प्रिंटफ' फ़ंक्शन के चौथे वास्तविक तर्क की जाँच करने पर विचार करें। हस्ताक्षर पूर्णांक प्रकार तर्क अपेक्षित है। netname.c 51

अन्य प्रासंगिक पोस्ट:

'प्रिंटफ' फ़ंक्शन के दूसरे वास्तविक तर्क की जाँच करने पर विचार करें। हस्ताक्षर पूर्णांक प्रकार तर्क अपेक्षित है। locarchive.c 1741
'प्रिंटफ' फ़ंक्शन के चौथे वास्तविक तर्क की जाँच करने पर विचार करें। हस्ताक्षर पूर्णांक प्रकार तर्क अपेक्षित है। locarchive.c 1741
'फ़र्प्रिंट' फ़ंक्शन के पांचवें वास्तविक तर्क की जाँच करने पर विचार करें। हस्ताक्षर पूर्णांक प्रकार तर्क अपेक्षित है। res_debug.c 236
'स्प्रिंटफ' फ़ंक्शन के तीसरे वास्तविक तर्क की जाँच करने पर विचार करें। UNSIGNED पूर्णांक प्रकार तर्क अपेक्षित है। inet_net_ntop.c 134
'स्प्रिंटफ' फ़ंक्शन के चौथे वास्तविक तर्क की जाँच करने पर विचार करें। हस्ताक्षर पूर्णांक प्रकार तर्क अपेक्षित है। ns_print.c 500
'स्प्रिंटफ' फ़ंक्शन के पांचवें वास्तविक तर्क की जांच करने पर विचार करें। हस्ताक्षर पूर्णांक प्रकार तर्क अपेक्षित है। ns_print.c 500
'स्प्रिंटफ' फ़ंक्शन के तीसरे वास्तविक तर्क की जाँच करने पर विचार करें। हस्ताक्षर पूर्णांक प्रकार तर्क अपेक्षित है। ns_print.c 572
'स्प्रिंटफ' फ़ंक्शन के चौथे वास्तविक तर्क की जाँच करने पर विचार करें। हस्ताक्षर पूर्णांक प्रकार तर्क अपेक्षित है। ns_print.c 572
'स्प्रिंटफ' फ़ंक्शन के पांचवें वास्तविक तर्क की जांच करने पर विचार करें। हस्ताक्षर पूर्णांक प्रकार तर्क अपेक्षित है। ns_print.c 572
'स्प्रिंटफ' फ़ंक्शन के तीसरे वास्तविक तर्क की जाँच करने पर विचार करें। UNSIGNED पूर्णांक प्रकार तर्क अपेक्षित है। ns_print.c 628
'स्प्रिंटफ' फ़ंक्शन के चौथे वास्तविक तर्क की जाँच करने पर विचार करें। UNSIGNED पूर्णांक प्रकार तर्क अपेक्षित है। ns_print.c 628
'स्प्रिंटफ' फ़ंक्शन के पांचवें वास्तविक तर्क की जांच करने पर विचार करें। UNSIGNED पूर्णांक प्रकार तर्क अपेक्षित है। ns_print.c 628
'स्प्रिंटफ' फ़ंक्शन के तीसरे वास्तविक तर्क की जाँच करने पर विचार करें। हस्ताक्षर पूर्णांक प्रकार तर्क अपेक्षित है। ns_print.c 645
'स्प्रिंटफ' फ़ंक्शन के तीसरे वास्तविक तर्क की जाँच करने पर विचार करें। UNSIGNED पूर्णांक प्रकार तर्क अपेक्षित है। ns_print.c 685
'प्रिंटफ' फ़ंक्शन के दूसरे वास्तविक तर्क की जाँच करने पर विचार करें। हस्ताक्षर पूर्णांक प्रकार तर्क अपेक्षित है। nis_print.c 209
'प्रिंटफ' फ़ंक्शन के दूसरे वास्तविक तर्क की जाँच करने पर विचार करें। हस्ताक्षर पूर्णांक प्रकार तर्क अपेक्षित है। sprof.c 480

निष्कर्ष

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

ग्लिब्क लाइब्रेरी टेस्ट प्रयोग