ডিভাইসের নিরাপত্তা উন্নত করার জন্য, Android 7.0 একচেটিয়া mediaserver প্রক্রিয়াটিকে একাধিক প্রক্রিয়ায় বিভক্ত করে যার অনুমতি এবং ক্ষমতা শুধুমাত্র প্রতিটি প্রক্রিয়ার জন্য প্রয়োজনীয় সীমাবদ্ধ। এই পরিবর্তনগুলি মিডিয়া কাঠামোর নিরাপত্তা দুর্বলতাগুলিকে প্রশমিত করে:
- AV পাইপলাইন উপাদানগুলিকে অ্যাপ-নির্দিষ্ট স্যান্ডবক্সযুক্ত প্রক্রিয়াগুলিতে বিভক্ত করা।
- আপডেটযোগ্য মিডিয়া উপাদানগুলি সক্ষম করা হচ্ছে (এক্সট্রাক্টর, কোডেক, ইত্যাদি)।
এই পরিবর্তনগুলি বেশিরভাগ মিডিয়া-সম্পর্কিত সুরক্ষা দুর্বলতার তীব্রতা উল্লেখযোগ্যভাবে হ্রাস করে, শেষ ব্যবহারকারীর ডিভাইস এবং ডেটা নিরাপদ রেখে শেষ ব্যবহারকারীদের জন্য নিরাপত্তা উন্নত করে।
নতুন আর্কিটেকচারের সাথে সামঞ্জস্যপূর্ণ করতে OEM এবং SoC বিক্রেতাদের তাদের HAL এবং কাঠামো পরিবর্তনগুলি আপডেট করতে হবে। বিশেষত, যেহেতু বিক্রেতা-প্রদত্ত অ্যান্ড্রয়েড কোড প্রায়শই অনুমান করে যে সবকিছু একই প্রক্রিয়ায় চলে, তাই বিক্রেতাদের অবশ্যই তাদের কোড আপডেট করতে হবে নেটিভ হ্যান্ডেলগুলি ( native_handle ) এর চারপাশে পাস করার জন্য যার অর্থ সমস্ত প্রক্রিয়া জুড়ে। মিডিয়া হার্ডনিং সম্পর্কিত পরিবর্তনের রেফারেন্স বাস্তবায়নের জন্য, frameworks/av এবং frameworks/native পড়ুন।
স্থাপত্য পরিবর্তন
অ্যান্ড্রয়েডের পূর্ববর্তী সংস্করণগুলি প্রচুর অনুমতি সহ একটি একক, একচেটিয়া mediaserver প্রক্রিয়া ব্যবহার করেছিল (ক্যামেরা অ্যাক্সেস, অডিও অ্যাক্সেস, ভিডিও ড্রাইভার অ্যাক্সেস, ফাইল অ্যাক্সেস, নেটওয়ার্ক অ্যাক্সেস, ইত্যাদি)। অ্যান্ড্রয়েড 7.0 mediaserver প্রক্রিয়াটিকে কয়েকটি নতুন প্রক্রিয়ায় বিভক্ত করে যার প্রতিটির জন্য অনেক ছোট অনুমতির প্রয়োজন হয়:
চিত্র 1. মিডিয়া সার্ভার শক্ত করার জন্য আর্কিটেকচার পরিবর্তন
এই নতুন আর্কিটেকচার নিশ্চিত করে যে কোনো প্রক্রিয়ার সাথে আপোস করা হলেও, দূষিত কোডের পূর্বে mediaserver দ্বারা ধারণকৃত সম্পূর্ণ অনুমতিগুলিতে অ্যাক্সেস থাকবে না। প্রক্রিয়াগুলি SElinux এবং seccomp নীতি দ্বারা সীমাবদ্ধ।
দ্রষ্টব্য: বিক্রেতা নির্ভরতার কারণে, কিছু কোডেক এখনও mediaserver চলে এবং ফলস্বরূপ mediaserver প্রয়োজনের চেয়ে বেশি অনুমতি দেয়। বিশেষত, Widevine Classic Android 7.0 এর জন্য mediaserver সার্ভারে চলতে থাকে।
মিডিয়া সার্ভার পরিবর্তন
অ্যান্ড্রয়েড 7.0 এ, প্লেব্যাক এবং রেকর্ডিং চালানোর জন্য mediaserver প্রক্রিয়া বিদ্যমান, যেমন উপাদান এবং প্রক্রিয়াগুলির মধ্যে বাফার পাস করা এবং সিঙ্ক্রোনাইজ করা। প্রসেসগুলি স্ট্যান্ডার্ড বাইন্ডার মেকানিজমের মাধ্যমে যোগাযোগ করে।
একটি সাধারণ স্থানীয় ফাইল প্লেব্যাক সেশনে, অ্যাপটি mediaserver (সাধারণত মিডিয়াপ্লেয়ার জাভা API-এর মাধ্যমে) এবং mediaserver একটি ফাইল বর্ণনাকারী (FD) পাস করে:
- FD কে বাইন্ডার ডেটাসোর্স অবজেক্টে মোড়ানো হয় যা এক্সট্র্যাক্টর প্রসেসে পাস করা হয়, যা বাইন্ডার আইপিসি ব্যবহার করে ফাইল থেকে পড়ার জন্য এটি ব্যবহার করে। (মিডিয়া এক্সট্র্যাক্টর এফডি পায় না বরং ডাটা পাওয়ার জন্য বাইন্ডার
mediaserverসার্ভারে আবার কল করে।) - ফাইলটি পরীক্ষা করে, ফাইলের প্রকারের জন্য উপযুক্ত এক্সট্র্যাক্টর তৈরি করে (যেমন MP3Extractor, or MPEG4Extractor), এবং
mediaserverপ্রক্রিয়ায় এক্সট্রাক্টরের জন্য একটি বাইন্ডার ইন্টারফেস ফেরত দেয়। - ফাইলে ডেটার ধরন নির্ধারণ করতে বাইন্ডার আইপিসি এক্সট্র্যাক্টরকে কল করে (যেমন MP3 বা H.264 ডেটা)।
- প্রয়োজনীয় ধরনের কোডেক তৈরি করতে
mediacodecপ্রক্রিয়ায় কল করে; এই কোডেকগুলির জন্য বাইন্ডার ইন্টারফেস গ্রহণ করে। - এনকোড করা নমুনাগুলি পড়ার জন্য এক্সট্র্যাক্টরকে বারবার বাইন্ডার আইপিসি কল করে, ডিকোডিংয়ের জন্য
mediacodecপ্রক্রিয়াতে এনকোড করা ডেটা পাঠাতে বাইন্ডার আইপিসি ব্যবহার করে এবং ডিকোড করা ডেটা গ্রহণ করে।
কিছু ব্যবহারের ক্ষেত্রে, কোন কোডেক জড়িত থাকে না (যেমন একটি অফলোড করা প্লেব্যাক যেখানে এনকোড করা ডেটা সরাসরি আউটপুট ডিভাইসে পাঠানো হয়), অথবা কোডেক ডিকোড করা ডেটার বাফার (ভিডিও প্লেব্যাক) ফেরত দেওয়ার পরিবর্তে সরাসরি ডিকোড করা ডেটা রেন্ডার করতে পারে।
MediaCodecService পরিবর্তন
কোডেক পরিষেবা যেখানে এনকোডার এবং ডিকোডার বাস করে। বিক্রেতা নির্ভরতার কারণে, সমস্ত কোডেক এখনও কোডেক প্রক্রিয়ায় বাস করে না। অ্যান্ড্রয়েড 7.0 এ:
- অ-সুরক্ষিত ডিকোডার এবং সফ্টওয়্যার এনকোডার কোডেক প্রক্রিয়ার মধ্যে থাকে।
- নিরাপদ ডিকোডার এবং হার্ডওয়্যার এনকোডার
mediaserverথাকে (অপরিবর্তিত)।
একটি অ্যাপ (বা mediaserver ) প্রয়োজনীয় ধরনের কোডেক তৈরি করতে কোডেক প্রক্রিয়াটিকে কল করে, তারপর সেই কোডেকটিকে এনকোড করা ডেটা পাস করতে এবং ডিকোড করা ডেটা পুনরুদ্ধার করতে (ডিকোডিংয়ের জন্য) বা ডিকোড করা ডেটা পাস করতে এবং এনকোড করা ডেটা পুনরুদ্ধার করতে কল করে (এনকোডিংয়ের জন্য) . কোডেক্সে এবং থেকে ডেটা স্থানান্তর ইতিমধ্যেই ভাগ করা মেমরি ব্যবহার করে, তাই সেই প্রক্রিয়াটি অপরিবর্তিত থাকে।
MediaDrmServer পরিবর্তন
DRM-সুরক্ষিত বিষয়বস্তু, যেমন Google Play Movies-এ সিনেমা চালানোর সময় DRM সার্ভার ব্যবহার করা হয়। এটি একটি নিরাপদ উপায়ে এনক্রিপ্ট করা ডেটা ডিক্রিপ্ট করা পরিচালনা করে এবং যেমন সার্টিফিকেট এবং কী স্টোরেজ এবং অন্যান্য সংবেদনশীল উপাদানগুলিতে অ্যাক্সেস রয়েছে। বিক্রেতা নির্ভরতার কারণে, DRM প্রক্রিয়াটি এখনও সব ক্ষেত্রে ব্যবহার করা হয় না।
অডিও সার্ভার পরিবর্তন
অডিও সার্ভার প্রক্রিয়া অডিও সম্পর্কিত উপাদান যেমন অডিও ইনপুট এবং আউটপুট, নীতি ব্যবস্থাপক পরিষেবা যা অডিও রাউটিং নির্ধারণ করে এবং এফএম রেডিও পরিষেবা হোস্ট করে। অডিও পরিবর্তন এবং বাস্তবায়ন নির্দেশিকা সম্পর্কে বিস্তারিত জানার জন্য, অডিও বাস্তবায়ন দেখুন।
ক্যামেরা সার্ভার পরিবর্তন
ক্যামেরা সার্ভার ক্যামেরা নিয়ন্ত্রণ করে এবং ক্যামেরা থেকে ভিডিও ফ্রেম পেতে ভিডিও রেকর্ড করার সময় ব্যবহার করা হয় এবং তারপরে আরও পরিচালনার জন্য mediaserver প্রেরণ করা হয়। CameraServer পরিবর্তনের জন্য পরিবর্তন এবং বাস্তবায়ন নির্দেশিকা সম্পর্কে বিস্তারিত জানার জন্য, ক্যামেরা ফ্রেমওয়ার্ক হার্ডেনিং পড়ুন।
ExtractorService পরিবর্তন
এক্সট্র্যাক্টর পরিষেবা এক্সট্র্যাক্টর হোস্ট করে, উপাদান যা মিডিয়া ফ্রেমওয়ার্ক দ্বারা সমর্থিত বিভিন্ন ফাইল ফরম্যাট পার্স করে। এক্সট্র্যাক্টর পরিষেবাটি সমস্ত পরিষেবার মধ্যে সবচেয়ে কম সুবিধাপ্রাপ্ত—এটি এফডি পড়তে পারে না তাই পরিবর্তে এটি ফাইলগুলি অ্যাক্সেস করার জন্য একটি বাইন্ডার ইন্টারফেসে (প্রতিটি প্লেব্যাক সেশনের mediaserver for দ্বারা সরবরাহ করা হয়) কল করে৷
একটি অ্যাপ (বা mediaserver ) একটি IMediaExtractor পাওয়ার জন্য এক্সট্র্যাক্টর প্রক্রিয়াতে একটি কল করে, ফাইলটিতে থাকা ট্র্যাকের জন্য IMediaSources পেতে যে IMediaExtractor কল করে এবং তারপর তাদের থেকে ডেটা পড়ার জন্য IMediaSources কল করে৷
প্রক্রিয়াগুলির মধ্যে ডেটা স্থানান্তর করতে, অ্যাপ (বা mediaserver ) বাইন্ডার লেনদেনের অংশ হিসাবে উত্তর-পার্সেলে ডেটা অন্তর্ভুক্ত করে বা ভাগ করা মেমরি ব্যবহার করে:
- শেয়ার্ড মেমরি ব্যবহার করার জন্য শেয়ার্ড মেমরি রিলিজ করার জন্য একটি অতিরিক্ত বাইন্ডার কলের প্রয়োজন কিন্তু দ্রুততর এবং বড় বাফারের জন্য কম শক্তি ব্যবহার করে।
- ইন-পার্সেল ব্যবহার করার জন্য অতিরিক্ত অনুলিপি প্রয়োজন কিন্তু দ্রুততর এবং 64KB-এর চেয়ে ছোট বাফারগুলির জন্য কম শক্তি ব্যবহার করে৷
বাস্তবায়ন
নতুন mediadrmserver প্রক্রিয়ায় MediaDrm এবং MediaCrypto উপাদানগুলির স্থানান্তরকে সমর্থন করার জন্য, বিক্রেতাদের অবশ্যই নিরাপদ বাফারগুলির জন্য বরাদ্দ পদ্ধতি পরিবর্তন করতে হবে যাতে বাফারগুলি প্রক্রিয়াগুলির মধ্যে ভাগ করা যায়।
পূর্ববর্তী অ্যান্ড্রয়েড রিলিজে, নিরাপদ বাফারগুলি OMX::allocateBuffer দ্বারা mediaserver বরাদ্দ করা হয় এবং একই প্রক্রিয়াতে ডিক্রিপশনের সময় ব্যবহৃত হয়, যেমনটি নীচে দেখানো হয়েছে:
চিত্র 2. মিডিয়া সার্ভারে অ্যান্ড্রয়েড 6.0 এবং নিম্ন বাফার বরাদ্দ।
অ্যান্ড্রয়েড 7.0-এ, বাফার বরাদ্দ প্রক্রিয়া একটি নতুন পদ্ধতিতে পরিবর্তিত হয়েছে যা বিদ্যমান বাস্তবায়নের উপর প্রভাব কমিয়ে নমনীয়তা প্রদান করে। নতুন mediadrmserver প্রক্রিয়ায় MediaDrm এবং MediaCrypto স্ট্যাকগুলির সাথে, বাফারগুলি আলাদাভাবে বরাদ্দ করা হয় এবং বিক্রেতাদের অবশ্যই সুরক্ষিত বাফার হ্যান্ডেলগুলি আপডেট করতে হবে যাতে MediaCodec MediaCrypto এ একটি ডিক্রিপ্ট অপারেশন শুরু করার সময় সেগুলিকে বাইন্ডারের মধ্যে পরিবহন করা যায়৷
চিত্র 3. মিডিয়া সার্ভারে Android 7.0 এবং উচ্চতর বাফার বরাদ্দ।
দেশীয় হ্যান্ডলগুলি ব্যবহার করুন
OMX::allocateBuffer অবশ্যই একটি native_handle স্ট্রাকটে একটি পয়েন্টার ফেরত দেবে, যেখানে ফাইল বর্ণনাকারী (FD) এবং অতিরিক্ত পূর্ণসংখ্যা ডেটা রয়েছে। একটি native_handle এফডি ব্যবহার করার সমস্ত সুবিধা রয়েছে, যার মধ্যে রয়েছে সিরিয়ালাইজেশন/ডিসারিয়ালাইজেশনের জন্য বিদ্যমান বাইন্ডার সমর্থন, যেখানে বর্তমানে এফডি ব্যবহার করেন না এমন বিক্রেতাদের জন্য আরও নমনীয়তার অনুমতি দেয়।
নেটিভ হ্যান্ডেল বরাদ্দ করতে native_handle_create() ব্যবহার করুন। ফ্রেমওয়ার্ক কোড বরাদ্দকৃত native_handle কাঠামোর মালিকানা নেয় এবং যেখানে native_handle মূলত বরাদ্দ করা হয় এবং যেখানে এটি ডিসিরিয়ালাইজ করা হয় উভয় প্রক্রিয়ায় সংস্থান প্রকাশের জন্য দায়ী। ফ্রেমওয়ার্ক নেটিভ হ্যান্ডেলগুলিকে native_handle_close() এর পরে native_handle_delete() দিয়ে প্রকাশ করে এবং Parcel::writeNativeHandle()/readNativeHandle() ব্যবহার করে native_handle সিরিয়ালাইজ/ডিসারিয়ালাইজ করে।
নিরাপদ বাফারের প্রতিনিধিত্ব করার জন্য যে সমস্ত SoC বিক্রেতারা FD ব্যবহার করেন তারা তাদের FD-এর সাথে native_handle FD জমা করতে পারেন। যেসব বিক্রেতারা FD ব্যবহার করেন না তারা native_buffer অতিরিক্ত ক্ষেত্র ব্যবহার করে সুরক্ষিত বাফারের প্রতিনিধিত্ব করতে পারেন।
ডিক্রিপশন অবস্থান সেট করুন
বিক্রেতাদের অবশ্যই OEMCrypto ডিক্রিপ্ট পদ্ধতিটি আপডেট করতে হবে যা native_handle নতুন প্রসেস স্পেসে ব্যবহারযোগ্য করার জন্য প্রয়োজনীয় native_handle -নির্দিষ্ট ক্রিয়াকলাপ সম্পাদন করতে (পরিবর্তনগুলি সাধারণত OEMCrypto লাইব্রেরিতে আপডেট অন্তর্ভুক্ত করে)।
যেহেতু allocateBuffer হল একটি আদর্শ OMX অপারেশন, Android 7.0-এ একটি নতুন OMX এক্সটেনশন রয়েছে ( OMX.google.android.index.allocateNativeHandle ) এই সমর্থনের জন্য অনুসন্ধান করার জন্য এবং একটি OMX_SetParameter কল যা OMX বাস্তবায়নের জন্য এটিকে নেটিভ হ্যান্ডেলগুলি ব্যবহার করা উচিত বলে বিজ্ঞপ্তি দেয়৷