Vdso और vsyscall क्या हैं?

Question 1

मैंने किया sudo cat /proc/1/maps -vv

मैं आउटपुट की समझ बनाने का प्रयास कर रहा हूं। मैं बहुत सारे साझा पुस्तकालयों को उम्मीद के मुताबिक मेमोरी मैपिंग सेगमेंट में मैप कर सकता हूं।

7f3c00137000-7f3c00179000 r-xp 00000000 08:01 21233923                   /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8
7f3c00179000-7f3c00379000 ---p 00042000 08:01 21233923                   /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8
7f3c00379000-7f3c0037a000 r--p 00042000 08:01 21233923                   /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8
7f3c0037a000-7f3c0037b000 rw-p 00043000 08:01 21233923                   /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8
7f3c0037b000-7f3c00383000 r-xp 00000000 08:01 21237216                   /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0
7f3c00383000-7f3c00583000 ---p 00008000 08:01 21237216                   /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0
7f3c00583000-7f3c00584000 r--p 00008000 08:01 21237216                   /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0
7f3c00584000-7f3c00585000 rw-p 00009000 08:01 21237216                   /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0
7f3c00585000-7f3c0059b000 r-xp 00000000 08:01 21237220                   /lib/x86_64-linux-gnu/libnih.so.1.0.0
7f3c0059b000-7f3c0079b000 ---p 00016000 08:01 21237220                   /lib/x86_64-linux-gnu/libnih.so.1.0.0
7f3c0079b000-7f3c0079c000 r--p 00016000 08:01 21237220                   /lib/x86_64-linux-gnu/libnih.so.1.0.0

अंत की ओर कुछ इस तरह है

7f3c0165b000-7f3c0177e000 rw-p 00000000 00:00 0                          [heap]
7fff97863000-7fff97884000 rw-p 00000000 00:00 0                          [stack]
7fff97945000-7fff97946000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

क्या करता है vdsoऔर क्या vsyscallमतलब है? मेमोरी का कर्नेल भाग vsyscall है? यह बहुत अच्छा होगा अगर कोई इस मुद्दे पर कुछ प्रकाश डाल सकता है।

Question 2

Vsyscall और vDSO खंडों दो लिनक्स में कुछ सिस्टम कॉल में तेजी लाने के लिए इस्तेमाल किया तंत्र है। उदाहरण के लिए, gettimeofdayआमतौर पर इस तंत्र के माध्यम से आह्वान किया जाता है। पेश किया गया पहला तंत्र vsyscall था , जिसे विशिष्ट सिस्टम कॉल को निष्पादित करने के तरीके के रूप में जोड़ा गया था जिसे सिस्टम कॉल ओवरहेड को कम करने के लिए चलाने के लिए किसी भी वास्तविक स्तर के विशेषाधिकार की आवश्यकता नहीं है। पिछले उदाहरण के बाद, सभी gettimeofdayको कर्नेल के वर्तमान समय को पढ़ना होगा। ऐसे अनुप्रयोग हैं जो gettimeofdayअक्सर कॉल करते हैं (उदाहरण के लिए टाइमस्टैम्प उत्पन्न करने के लिए), इस बिंदु पर कि वे ओवरहेड के बारे में भी थोड़ा ध्यान रखते हैं। इस चिंता को दूर करने के लिए, कर्नेल उपयोगकर्ता के वर्तमान समय और एक तेज़ वाले पृष्ठ में मैप करता हैgettimeofdayकार्यान्वयन (यानी सिर्फ एक फ़ंक्शन जो vsyscall में सहेजे गए समय को पढ़ता है )। इस आभासी सिस्टम कॉल का उपयोग करना, सी पुस्तकालय एक तेजी से प्रदान कर सकते हैं gettimeofdayजो भूमि के ऊपर गिरी अंतरिक्ष और आम तौर पर क्लासिक सिस्टम कॉल मॉडल के आधार पर शुरू की उपयोगकर्ता अंतरिक्ष के बीच संदर्भ स्विच द्वारा शुरू की जरूरत नहीं है INT 0x80या SYSCALL।

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

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

VDSO अपनी सीमाएं पर काबू पाने, जबकि, vsyscall रूप में एक ही कार्यक्षमता प्रदान करता है। VDSO (वर्चुअल डायनामिकली लिंक्ड शेयर्ड ऑब्जेक्ट्स) यूजर स्पेस में आवंटित एक मेमोरी एरिया है जो यूजर स्पेस में कुछ कर्नेल फंक्शंस को सुरक्षित तरीके से उजागर करता है। यह सुरक्षा खतरों के कारण हल करने के लिए पेश किया गया है vsyscall। VDSO को गतिशील रूप से आवंटित किया गया है जो सुरक्षा चिंताओं को हल करता है और इसमें 4 से अधिक सिस्टम कॉल हो सकते हैं। VDSO लिंक glibc पुस्तकालय के माध्यम से प्रदान की जाती हैं। लिंकर glibc vDSO कार्यक्षमता में लिंक करेगा , बशर्ते कि इस तरह की दिनचर्या के साथ एक vDSO संस्करण हो, जैसे gettimeofday। जब आपका प्रोग्राम निष्पादित होता है, यदि आपके कर्नेल में vDSO नहीं है समर्थन, एक पारंपरिक syscall बनाया जाएगा।

क्रेडिट और उपयोगी लिंक:

Question 3

मैं बस यह जोड़ना चाहता हूं कि अब नई गुठली में, vDSOकेवल "सुरक्षित" syscalls के लिए उपयोग नहीं किया जाता है , बल्कि यह तय करने के लिए उपयोग किया जाता है कि सिस्टम पर syscall को आमंत्रित करने के लिए किस syscall तंत्र को प्राथमिकता दी जाती है।