কোনও সিস্টেমে সমস্ত ফাঁকা জায়গা বরাদ্দ করে অন্য প্রোগ্রাম থেকে মেমরি পড়া সম্ভব?


26

তাত্ত্বিকভাবে, আমি যদি এমন একটি প্রোগ্রাম তৈরি করি যা কোনও সিস্টেমে সমস্ত অব্যবহৃত মেমরির বরাদ্দ করে, এবং অন্যান্য অ্যাপ্লিকেশনগুলির এখন আর মেমরির প্রয়োজন হয় না বলে আরও বেশি মেমরির জন্য অনুরোধ করতে থাকে তবে অন্য অ্যাপ্লিকেশন থেকে সম্প্রতি প্রকাশিত মেমোরিটি পড়া সম্ভব হবে কি? ? অথবা এটি কোনওভাবেই আধুনিক অপারেটিং সিস্টেম দ্বারা সুরক্ষিত?

এর জন্য আমার কোন ব্যবহারিক প্রয়োগ নেই, আমি শুধু কৌতূহলী। আমি বুঝতে পারি বাস্তব জীবনে "সমস্ত উপলভ্য মেমরি" বরাদ্দ করার কিছু সমস্যা রয়েছে।

সম্পাদনা: পরিষ্কার করার জন্য, আমি বিশেষত "মুক্তিপ্রাপ্ত" মেমরির বিষয়ে জিজ্ঞাসা করছি, বর্তমানে অন্য অ্যাপ্লিকেশন দ্বারা বরাদ্দকৃত মেমরির অ্যাক্সেস নেই।

উত্তর:


23

না, কারণ কোনও ভাল কার্নেল আপনার প্রস্তাবিত আক্রমণটির ঠিক ধরণের বিরুদ্ধে রক্ষা করার জন্য কোনও প্রক্রিয়া জারি করার আগে মেমরির বিষয়বস্তু মুছে দেয়।

ইউনিক্সি সিস্টেমে মেমোরিটিকে প্রোগ্রাম ব্রেক হিসাবে পরিচিত করে প্রসেসগুলিতে বরাদ্দ করা হয় , যা কার্যত-ঠিকানাযোগ্য জায়গার সীমা যা কোনও প্রক্রিয়া ব্যবহার করতে পারে। একটি প্রক্রিয়া কার্নেলকে তার ঠিকানাযোগ্য স্থানটি প্রসারিত করতে চায় বলে জানিয়ে দেয় এবং মেমরি উপলভ্য থাকলে বা কল না থাকলে কলটি ব্যর্থ হবে ker ( brk()সিস্টেম কলের নামটি এই ধারণাটি থেকে আসে))

অনুশীলনে, মুক্ত মেমরির বৃহত ব্লকগুলি প্রায়শই প্রোগ্রাম বিরতির বিরুদ্ধে বাধা দেয় না, যা প্রোগ্রামের বিরতি সঙ্কুচিত করে কার্নেলের কাছে মেমরি ফিরিয়ে আনতে প্রক্রিয়াটির প্রয়োজন হয়। এই আপনার সিস্টেমের বাস্তবায়নে সব নির্ভরশীল অবশ্যই, হয়, malloc()এবং free()। আপনার কাছে যদি সোর্স উপলব্ধ থাকে তবে তারা আপনাকে জানিয়ে দেবে মেমোরিটি কখনও ফিরে আসে কি না।

malloc()মেমোরিটি আরম্ভ না করার জন্য কোনও সুরক্ষা জড়িত নেই কারণ এর মাধ্যমে যা কিছু পেয়েছে তা brk()স্ক্র্যাব করে দেওয়া হবে এবং এর আগে যে কোনও কিছু free()একই প্রক্রিয়া দ্বারা লেখা হয়েছিল।


19

হ্যাঁ, তাত্ত্বিকভাবে আরও একটি প্রক্রিয়া পড়া 'মেমরির রিলিজ করা সম্ভব। এটি ছিল দিনে ফিরে বেশ কয়েকটি সুযোগ-সুবিধা বৃদ্ধির আক্রমণ। যার কারণে, অপারেটিং সিস্টেমগুলি আজকাল কার্যকরভাবে মেমরি শূন্য করে যদি এটি অন্য কোনও প্রক্রিয়া দ্বারা বরাদ্দ করা হয়। আপনি সর্বদা শূন্য আউট মেমরিটি না দেখার কারণ হ'ল মেমরিটি যদি একই প্রক্রিয়াটি আগে বরাদ্দ করা হত তবে এটি শূন্য না করাই আরও দক্ষ efficient ওএস মেমরির পৃষ্ঠাগুলি যদি একই পদ্ধতিতে করতে পারে তবে তা ফিরিয়ে দেওয়ার চেষ্টা করে।


1
"হ্যাঁ তবে না" হ'ল "না"। @ ব্লারফ্লায় এটি ঠিক আছে।
রস প্যাটারসন

4
@ রোসপ্যাটারসন: তাত্ত্বিক পয়েন্টে কার্ল আসলে আমার চেয়ে অনেক বেশি সঠিক। ব্যবহারিক বাস্তবতা হ'ল মূলধারার ওএসগুলি বছরগুলি আগে সেই গর্তটি বন্ধ করেছিল।
blrfl

@ ব্লারফ্ল "বছর আগে" 1960 এর দশকের শেষভাগে ছিল, যখন পেজিং সিস্টেম এবং ভার্চুয়াল মেমরি প্রথম চালু হয়েছিল। অবশ্যই মাল্টিক্স, ভিএম / 370 এবং ওএস / ভিএস এর সময় দ্বারা। বাগ অনুপস্থিত, বেশিরভাগ অনুশীলনকারী প্রোগ্রামারদের স্মৃতিতে এটি সম্ভব হয়নি hasn't
রস প্যাটারসন

The reason you don't always see zeroed out memory is because it is more efficient not to zero out the memory if it was previously allocated by the same process আমি এখানে কিছু অসঙ্গতি দেখছি। আপনি কি "একই নির্বাহযোগ্য" বলতে চান? শূন্য আউট না করা যায় কিনা তা কীভাবে পরীক্ষা করা হয় - ডিস্কের পথে?
jakub.g

1
আমি মনে করি আমি কিছু মিস করছি। তারপরে, যখন আমি কিছু সি ++ প্রোগ্রামটি সংকলন ও চালিত করি, বলি, অবিচ্ছিন্ন পূর্ণসংখ্যার সাথে, যখন আমি এই পরিবর্তনগুলি পড়ি তখন সেগুলি 0 এর সমান হয় না?
jakub.g

2

এখানে জড়িত বেশ কয়েকটি স্তর রয়েছে যা উত্তরকে প্রভাবিত করে।

যদি আপনি একটি আধুনিক ভার্চুয়াল মেমরি অপারেটিং সিস্টেমটি ধরে নেন তবে আপনি বরাদ্দ করা পৃষ্ঠাগুলিতে অন্য কোনও প্রক্রিয়া ডেটার অবশিষ্টাংশ দেখতে পাবেন না।

যখন কোনও প্রক্রিয়া প্রথমে লোড হয়, পৃষ্ঠার সারণিটি লোড হয় এবং সম্ভাব্যভাবে সত্যিকারের মেমরির ফ্রেমগুলি সেই পৃষ্ঠাগুলিতে বরাদ্দ করা হয়। সর্বনিম্ন, পৃষ্ঠা সারণী বা এর পরিপূরক টেবিলটিতে প্রক্রিয়াটি বরাদ্দ করতে পারে এমন সমস্ত মেমরির মানচিত্র থাকবে। এটিও যেখানে উপরে বর্ণিত প্রাথমিক প্রক্রিয়া বিরতি সেট হয়ে যায়।

Malloc (), যদি প্রক্রিয়াটি অনুমোদিত হয় তবে প্রক্রিয়া বিরতিতে পরিবর্তন আনতে পারে, অনুরোধটি পূরণ করার জন্য একটি প্রসেস পৃষ্ঠাতে (পরিপূরক পৃষ্ঠা) সারণীতে আরও পৃষ্ঠা যুক্ত করা যায়, যেখানে একটি প্রক্রিয়া অন্য প্রক্রিয়া ডেটা পেতে পারে এমন জায়গায় নিম্ন আসল মেমরি স্তর

এই উভয় পরিস্থিতিতেই একটি আধুনিক অপারেটিং সিস্টেম যা ডিমান্ড পেজিং বা অলস বরাদ্দ ব্যবহার করে এখনও শারীরিক স্মৃতি (ফ্রেম) বরাদ্দ করে না। অপারেটিং সিস্টেমটি কেবল "নোট তৈরি করা" যা সম্পর্কে সেই প্রক্রিয়াটির জন্য ভার্চুয়াল মেমরিটি বৈধ হিসাবে বিবেচিত হয়। প্রকৃত মেমরি কেবল প্রয়োজনের সাথে নিযুক্ত করা হয়।

ভার্চুয়াল পৃষ্ঠাটি অনুধাবন করা হয় এবং একটি প্রক্রিয়া পৃষ্ঠা সারণিতে ম্যাপ করা হয় তখন শারীরিক মেমরি বা ফ্রেমগুলি কোনও প্রক্রিয়াতে বরাদ্দ পায় এটি এখানে ডেটা এক্সপোজারের সম্ভাবনা বিদ্যমান। এটি একটি পৃষ্ঠার ত্রুটির সময় ঘটে। এক্সপোজারটি হ'ল কারণ পূর্ববর্তী প্রক্রিয়াটি একই ফ্রেমটি ব্যবহার করে এবং বর্তমান দৈহিক মেমরির অনুরোধের জন্য জায়গা তৈরি করতে এর ডেটাগুলি ত্যাগ করা বা অদলবদল করা হয়েছিল। প্রক্রিয়াটি পুনরায় শুরু করার আগে অনুরোধ প্রক্রিয়াগুলির ডেটা সঠিকভাবে অদলবদল করা হয়েছে বা ফ্রেম সাফ করা হয়েছে (শূন্য হয়েছে) তা নিশ্চিত করতে অপারেটিং সিস্টেমকে অবশ্যই সতর্ক থাকতে হবে। এটি উপরে "পুরানো তবে সমাধান" সমস্যা হিসাবেও উল্লেখ করা হয়েছে।

অন্যান্য প্রক্রিয়া মেমরিটি "প্রকাশিত" হয়েছিল কিনা তা এটিকে কিছুটা অপ্রাসঙ্গিক করে তোলে। "প্রকাশিত" মেমরির অন্য প্রক্রিয়াগুলি এখনও সেই প্রক্রিয়াটিতে নির্ধারিত পৃষ্ঠাগুলিতে থাকে এবং প্রক্রিয়াটি শেষ না হওয়া পর্যন্ত সাধারণত আনম্যাপ করা হয় না কারণ স্মৃতিশক্তি কম হয়ে যায় বা এগুলি অন্যথায় উচ্ছেদ করা হলে তারা কেবল অদলবদল হয়ে যায়। malloc () এবং বিনামূল্যে () প্রক্রিয়াটিতে নির্ধারিত ভার্চুয়াল মেমরিটি (ব্যবহারকারী) পর্যায়ে পরিচালনা করে।

আপনার প্রশ্নে, আপনার প্রক্রিয়া, তাত্ত্বিকভাবে, সমস্ত অন্যান্য প্রক্রিয়াগুলিকে স্মৃতি থেকে দূরে সরিয়ে অধিকতর মেমরির জন্য অনুরোধ করে চলেছে। বাস্তবে, ফ্রেম বরাদ্দ কৌশলগুলি রয়েছে - বৈশ্বিক এবং স্থানীয় - যা উত্তরের উপরও প্রভাব ফেলতে পারে। এটি সম্ভবত অপারেটিং সিস্টেম এবং অন্যান্য সমস্ত প্রক্রিয়া ওভাররন করার অনুমতি দেওয়ার আগে প্রক্রিয়াটি তার নিজস্ব পৃষ্ঠাগুলিকে মেমরি থেকে সরিয়ে দেয়। যদিও এটি আপনার প্রাথমিক প্রশ্নের অতিক্রম করে।

এমএস-ডস-এর মতো সিস্টেমে এটি সমস্ত কিছুই। এমএস-ডস (এবং অন্যান্য, সহজ সিস্টেমগুলি) ভার্চুয়াল মেমরি ব্যবহার করে না (নিজেরাই) এবং আপনি সহজেই অন্য কোনও "প্রক্রিয়া" ডেটাতে ঝাঁকুনি এবং উন্নত করতে পারেন।

কিছু ভাল রেফারেন্স, লিনাক্স উত্স কোডের চেয়ে এটি বুঝতে সহজ হতে পারে একটি ভাল অপারেটিং সিস্টেমের পাঠ্য পুস্তক, সিলবারস্ক্যাটজ, গ্যাভিন এবং গ্যাংয়ের অপারেটিং সিস্টেম ধারণা বা অ্যান্ড্রু টেনেনবাউমের অপারেটিং সিস্টেম ডিজাইন would এছাড়াও বার্কলে থেকে নাচোস বা স্ট্যানফোর্ডের পিন্টোসের মতো কিছু হ'ল শেখার জন্য নির্মিত ছোট অপারেটিং সিস্টেম এবং সেগুলির মধ্যে এই একই ধারণা রয়েছে।


0

আমি 16.04 মাস আগে উবুন্টুতে এটি চেষ্টা করেছি। 0xACE ঠিক যেমনটি বলেছিল, আধুনিক ওএস আপনাকে একবার ম্যালোক () বলে ডাকলে একটি সমস্ত-শূন্য, ভার্চুয়াল পৃষ্ঠা বরাদ্দ করে। তবে, আপনি যদি বরাদ্দ করা বাফারে কিছু না লিখে থাকেন তবে এটি শারীরিক স্মৃতিতে ম্যাপ করা হবে না (এটি অনুলিপি-রচনা নীতি), সুতরাং আপনি সর্বদা একটি "অবিচ্ছিন্ন" ব্লক থেকে শূন্যগুলি পড়বেন। আরও ভাল পারফরম্যান্সের জন্য "CONFIG_MMAP_ALLOW_UNITIALIZED" বিকল্পের সাথে সংকলিত কিছু এম্বেড থাকা ওএস থাকতে পারে, এক্ষেত্রে আপনি যা অর্জন করেছেন তার চেয়ে বেশি পেতে পারেন।


-1

না, এটি অন্য প্রোগ্রামকে অন্যের স্মৃতি পড়ার মঞ্জুরি দেয় না পেজিংয়ের যাদুটির জন্য ধন্যবাদ । এইভাবে, মোট স্মৃতি ব্যবহার হার্ডড্রাইভে এর অংশগুলি অফলোড করে শারীরিক র‌্যামকে অতিক্রম করতে পারে।

এছাড়াও, কোনও প্রক্রিয়া সর্বাধিক মেমোরি বরাদ্দ করতে পারে তা ওএস দ্বারা নির্বিচারে সীমাবদ্ধ হয় (32 বিট আর্কিটেকচারের জন্য 4 গিগ অবধি) যার পরের allocকলটি মেমরি ত্রুটির বাইরে চলে আসবে।


প্ল্যাটফর্মের নির্দিষ্ট এপিআই নেই যা এটির অবতারণা করতে পারে? আমি সত্যই জানি না, তবে আমি অবাক হব না (উদাহরণস্বরূপ, লিনাক্স ওএসকে কোনও পৃষ্ঠা ভৌত স্মৃতি থেকে সরিয়ে রাখতে বাধা দেয়, এর মাধ্যমে mlock)।

যদি 4 গিগাবাইট র‌্যাম থাকে এবং পেজিংটি 8 গিগাবাইটের মধ্যে সীমাবদ্ধ থাকে তবে যদি অ্যাপ্লিকেশনটি 12 জিবি (একটি এক্স 64 এ) অনুরোধ করে?
আর্সেনী মরজেনকো

তারপরে খুব কম ফ্রি মেমোরি থেকে যাওয়ার পরে সিস্টেম কলগুলির ত্রুটি ফিরে পাওয়া উচিত, যখন বা কোনও বাকী নেই তখন কম্পিউটারটি কেবল থামবে
ra

4
তিনি অন্যের স্মৃতি পড়ার বিষয়ে জিজ্ঞাসা করছেন না, বরং তাদের রিলিজড স্মৃতিটি পড়ছেন। ভেড়ার সেই অংশটি বর্তমানে নিখরচায়, এবং .... আমি মনে করি না ... যে পেজিংটি মুক্ত হওয়ার পরে মেমরিটি শূন্য করে। সুতরাং প্রোগ্রামটি মেমরির একটি ব্লক বরাদ্দ করবে এবং ইতিমধ্যে উপস্থিত অবিচ্ছিন্ন তথ্য বিশ্লেষণ করবে।
ফিলিপ

ফিলিপ সঠিক, আমি প্রকাশিত স্মৃতি সম্পর্কে বিশেষত জিজ্ঞাসা করছি
কন্ডিশন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.