به زیر کاپوت سیستم عامل کروم نگاه می کنیم
این که برنامه های دسکتاپ و خود دسکتاپ دیر یا زود به وب منتقل می شوند، تقریباً پس از تولد جاوا اسکریپت مشخص شد، بنابراین ظاهر سیستم عامل کروم تا حد زیادی قابل پیش بینی است. و اینکه این گوگل بود که سیستم عامل ابری را منتشر کرد نیز کاملا طبیعی است. اما بیایید سعی کنیم از بحث بی پایان در مورد آینده دسکتاپ که توسط بخش محافظه کار افراد IT برانگیخته شده است فاصله بگیریم و از نقطه نظر پیاده سازی فنی به سیستم عامل کروم نگاه کنیم.
جاده ای به سمت ابرها
گوگل سیستم عامل کروم را در تابستان 2009 معرفی کرد و قبلاً در نوامبر آن را به عموم مردم نشان داد و کد منبع را تحت نام سیستم عامل Chromium در دسترس عموم قرار داد. در آن زمان، سیستم عامل بسیار ساده بود و یک مرورگر کروم تمام صفحه بود که بر روی یک توزیع بسیار ضعیف اوبونتو اجرا می شد. همه مکانیسم های مشابه را برای جداسازی برگه ها و پلاگین های مرورگر، همان مدل چند فرآیندی مرورگر اجرا کرد، اما به طور کلی، سیستم عامل در هیچ چیز خاصی تفاوتی نداشت.
در طول پنج سال آینده، گوگل به طور مداوم، اما واقعاً کار خود را تبلیغ نکرد، سیستم عامل کروم را توسعه داد. در طول مسیر، کرومبوکها و کرومباکسهایی را منتشر کرد که در میان یونیکسوئیدها محبوب شدند و بلافاصله پس از خرید، سیستمعامل کروم را تخریب کردند. به تدریج، گوگل اوبونتو را به نفع جنتو رها کرد (ظاهراً برای اینکه بتواند بسته هایی را بدون وابستگی «بی فایده» برای آن و bun های نسخه Hardened کیت توزیع بسازد) و حالت تک پنجره ای را با حالت چندگانه استاندارد جایگزین کرد. حالت پنجره برای دسکتاپ با نوار وظیفه استاندارد در زیر. گوگل عمداً آن را در اولین نسخههای سیستمعامل کروم کنار گذاشت، زیرا این سیستمعامل به سمت نتبوکها با صفحهنمایشهای کوچکشان طراحی شده بود، اما ظاهراً کاربران قدردان این موضوع نبودند.
همچنین برنامه های وب آفلاین (در کروم معمولی نیز موجود است) و در نهایت، از تعدادی برنامه اندروید پشتیبانی می شود. رویداد اخیر پس از آن بود که رهبری توسعه هر دو سیستم عامل به دست ساندار پیچای، که همیشه مسئول توسعه کروم، سیستم عامل کروم و برنامه های وب گوگل بوده است، رسید.
سیستم عامل کروم همراه با خود مرورگر تکامل می یابد، بنابراین نسخه های آنها یکسان است. در زمان نگارش این مقاله، این نسخه 41 بود، اما برخلاف مرورگر، سیستم عامل Chrome به استثنای کرومبوکها و کرومباکسهایی که به طور رسمی پشتیبانی میشوند، بیلدهای آماده نصب ندارد. با این حال، یافتن ساختهای غیررسمی مبتنی بر منابع سیستم عامل Chromium در وب کاملاً ممکن است. برای مثال، همیشه میتوانید بیلدهای روزانه x86، x64 و ARM را دانلود کنید. کافی است یکی از آنها را روی فلش USB بنویسید و از آن بوت کنید. با این حال، باید آماده بود که همه اجزای دستگاه شروع به کار نکنند (در مورد من، صفحه لمسی افتاد). علاوه بر این، سیستم عامل Chromium از Flash، DRM و Netflix پشتیبانی نمی کند، اما به کنسول با حقوق ریشه دسترسی دارد.
مفاهیم اساسی
ایده کلیدی پشت سیستم عامل کروم این است که، به طور کلی، سیستم عاملی با کلاینت نازک است که در آن همه چیز به جز رابط کاربری گرافیکی و مرورگر در وب است. در واقع، بدون اتصال به اینترنت و حساب گوگل، سیستم عامل حتی به کاربر اجازه ورود نمی دهد (حداقل برای اولین بار). Google پیشنهاد میکند فایلها را در Google Drive شما ذخیره کند (این شرکت به خریداران Chromebook 100 گیگابایت میدهد)، تنظیمات، برنامههای افزودنی و برنامههای نصب شده به روش استاندارد برای مرورگر کروم همگامسازی میشوند. برای چاپ، پیشنهاد می شود از Google Cloud Print استفاده کنید.
در واقعیت های روسیه، این رویکرد چیزی را به ارمغان نمی آورد و مشکلات زیادی را ایجاد می کند، و در سایر نقاط جهان نیز. اما سیستم عامل کروم آینده گوگل است و این مدل کار به برنامه نویسان اجازه می دهد تا تعدادی از تصمیمات جالب معماری و رویکردهای امنیتی را پیاده سازی کنند. که در ادامه مقاله در مورد آن صحبت خواهیم کرد.
همه چیز از بایوس شروع می شود
در حالی که سیستم عامل Chromium می تواند بر روی رایانه هایی با بایوس موجود اجرا شود، کروم بوک ها مبتنی بر CoreBoot هستند. و این فقط یکی از ویژگی های فنی آنها نیست، بلکه یک بهینه سازی عمدی است. CoreBoot یک "BIOS" کاملاً 32 بیتی است که از بسیاری از کدهای اولیه سخت افزاری که این روزها بی استفاده هستند، خالی شده است. همراه با بهینهسازیهای گوگل، میتواند یک شروع سرد از فشار دادن دکمه پاور تا بارگذاری هسته را تنها در یک ثانیه انجام دهد.
سپس، CoreBoot پارتیشن بوت GPT را پیدا میکند و یک باینری حاوی بوتلودر u-boot (معمولاً در الکترونیک جاسازیشده استفاده میشود) و هسته لینوکس را در حافظه بارگذاری میکند، پس از آن کنترل u-boot و رویه بوت تقریبا استاندارد را میدهد. برای توزیع های لینوکس شروع می شود، از جمله خودتان که پارتیشن ریشه را نصب می کنید، دیمون ها را شروع می کنید، سیستم گرافیکی و در نهایت رابط.
نکته جالب در کل این رویه این است که بوت لودر با هسته و root FS دارای "کپی های پشتیبان" در بخش های جداگانه است و از این ویژگی برای به روز رسانی سیستم عامل و در صورت خرابی برگشت استفاده می شود. در طول یک بهروزرسانی خودکار، سیستمعامل Chrome اصلاً نصب فعلی را لمس نمیکند، اما در عوض نسخه جدیدی از سیستمعامل را روی همان «پارتیشنهای پشتیبان» که پس از راهاندازی مجدد «جاری» میشوند، مینویسد. در صورت خرابی هنگام بارگیری نسخه جدید سیستم عامل، یک تعویض معکوس رخ می دهد و کاربر می تواند به یک سیستم کاری شناخته شده دسترسی پیدا کند (خود سیستم می تواند بفهمد که با موفقیت راه اندازی شده است و پرچم مناسب را قرار می دهد. در پارتیشن های GPT فعلی).
علاوه بر این، در هر مرحله از انتقال کنترل از یک مؤلفه به مؤلفه دیگر (به عنوان مثال، از CoreBoot به u-boot)، امضای دیجیتال تأیید می شود (در مورد root FS، تأیید جمع کنترلی در جریان است)، اگر مطابقت ندارد، سیستم نیز به نسخه قبلی برمی گردد. این کار به این دلیل کار می کند که پارتیشن های دارای نسخه فعلی سیستم فقط خواندنی هستند و کاربر حتی نمی تواند به طور تصادفی آنها را تغییر دهد.
اطلاعات
EEPROM Chromebook نه تنها حاوی دو نسخه از میانافزار (که یکی از آنها نسخه پشتیبان است)، بلکه یک سیستم عامل بازیابی غیرقابل بازنویسی است که به شما امکان میدهد سیستم را از درایو فلش USB یا کارت حافظه بوت کنید و سیستم را بررسی و بازیابی کنید.
علاوه بر CoreBoot، EEPROM هر Chromebook شامل SeaBIOS است، یک پیادهسازی بایوس باز که به شما امکان میدهد بدون هیچ زحمتی ویندوز یا لینوکس را روی دستگاه خود نصب کنید.
لینوکس همه جا حاضر
نسخههای کنونی سیستمعامل کروم مبتنی بر لینوکس جنتو هستند، با این استثنا که از Upstart اوبونتو بهجای سیستم اولیه OpenRC استاندارد توزیع استفاده میشود. در مقایسه با یک توزیع معمولی لینوکس، سیستم به شدت محدود شده است، بنابراین هیچ چیز خاصی برای دانلود در اینجا وجود ندارد و تنها در یک ثانیه شروع می شود. ترمینال معمولی وجود ندارد، اما یک کرش پوسته محلی از طریق آن موجود است.
با اجرای دستور shell در آن، به bash استاندارد با حقوق ریشه (البته در Chromium OS) دسترسی پیدا می کنیم و می توانیم سیستم را کاوش کنیم. دیمون های rsyslogd وجود دارد که همه ما می شناسیم، dbus-daemon (D-Bus در سیستم عامل کروم برای تبادل داده بین مرورگر و بقیه سیستم استفاده می شود)، wpa_supplicant (احراز هویت در شبکه های Wi-Fi)، dhcpcd، x، ModemManager ( کار با مودمهای 3G)، udev، ConnMan (مدیریت اتصالات شبکه) بهعلاوه بیش از دوجین دیون مخصوص سیستم عامل کروم که مسئول، از جمله موارد دیگر، بهروزرسانی سیستم (update_engine)، کار با ماژول TPM (chapsd)، رمزگذاری خانه هستند. دایرکتوری (cryptohomed)، اشکال زدایی (debugd) و سایر وظایف.
جایگاه ویژه ای در اینجا توسط دیمون session_manager اشغال شده است که وظیفه مقداردهی اولیه بخش سطح بالای سیستم عامل را بر عهده دارد. وظایف آن عبارتند از:
- سرور X را راه اندازی کنید.
- متغیرهای محیطی را برای مرورگر کروم راه اندازی کنید.
- دایرکتوری ها، فایل ها و قوانین cgroup های لازم را برای Chrome ایجاد کنید.
- Chrome را راه اندازی کنید.
- رویداد login-prompt-visible Upstart را فعال کنید، که باعث می شود پنجره ورود به سیستم روی صفحه ظاهر شود.
در طول این فرآیند، هیچ یک از اجزای مسئول تشکیل "دسکتاپ" (به استثنای پنجره ورود) راه اندازی نمی شود. توسط خود مرورگر، با تکیه بر چارچوب Aura، که شامل گرافیک های سطح پایین و عملکردهای پنجره (با شتاب سخت از طریق DRI) و محیط دسکتاپ Ash است که نوار وظیفه، تزئینات پنجره، Google Now و موارد دیگر را رندر می کند، ارائه می شود. عناصر رابط استاندارد. اگرچه آنها بخشی از مرورگر کروم هستند، اما با این وجود در چندین فرآیند مستقل اجرا می شوند.
اطلاعات
در صورت خرابی بوت سیستم، که اگر فرآیند مرورگر در عرض 30 ثانیه شروع نشود، ثبت میشود، سیستم عامل Chromium به طور خودکار سرور SSH را راهاندازی میکند و با استفاده از دستور udevtrigger، نظرسنجی هسته را برای سختافزار مجدداً شروع میکند.
به لطف ادغام Aura و Ash در خود کروم، میتوانید با راهاندازی مرورگر با پرچم --open-ash دسکتاپ Chrome OS را در هر سیستمعاملی دریافت کنید.
ایمنی
علاوه بر روشهایی که قبلاً برای اطمینان از امنیت و یکپارچگی دادهها مورد بحث قرار گرفتهاند، مانند راهاندازی ایمن سیستم، یک فهرست خانه رمزگذاریشده با دادههای ذخیرهشده (رمزگذاری به طور جداگانه برای هر کاربر انجام میشود)، و همچنین روشهای استاندارد Chrome برای جداسازی فرآیندها، افزونهها. و Native Client از سیستم (در اینجا، مکانیسم seccomp-bpf، که به شما امکان می دهد تماس های سیستمی را فیلتر کنید)، سیستم عامل Chrome از تعدادی رویکرد امنیتی دیگر استفاده می کند.
مرکزی در میان آنها minijail است، یک برنامه کوچک که برای جداسازی سرویس های سیستم (شیطان ها) و سایر اجزای سیستم استفاده می شود. این یک برنامه بسیار منعطف است که به شما امکان می دهد عملکردهایی مانند دادن "قابلیت" به برنامه یا لغو آنها (قابلیت ها یک زیرسیستم هسته لینوکس ویژه برای دادن برخی از قابلیت های ریشه به باینری های غیر SUID است)، قفل کردن آن در chroot، ابطال ریشه حقوق، محدودیت هایی را برای منابع تعیین کنید (rlimits)، فرآیند را در فضای نام اختصاصی (به روش LXC و Docker) قرار دهید و قوانین cgroups را برای آن اعمال کنید.
اگر به خروجی ps aux|grep minijail (نگاه کنید به اسکرین شات) در یک سیستم در حال اجرا نگاه کنید، می بینید که از minijail برای راه اندازی دیمون ها با تنظیمات خاص استفاده می شود، اما تعداد چنین شیاطینی نسبت به تمام کسانی که روی سیستم در حال اجرا هستند، استفاده می شود. آنقدر بزرگ نیست طبق اسناد توسعه دهندگان، برنامه ریزی شده است که minijail در آینده به طور قابل توجهی گسترش یابد و آن را در تعداد بسیار بیشتری از اجزای سیستم، از جمله پشته گرافیکی و کروم اعمال کند. در حال حاضر، آنچه هست، هست.
سایر اقدامات امنیتی شامل استفاده از پرچم های کامپایلر برای به حداقل رساندن خطر شکست پشته (-fno-delete-null-pointer-checks، -fstack-protector، FORTIFY_SOURCE)، استفاده از ASLR "تقویت شده" (تصادفی سازی طرح بندی فضای آدرس) است. ) مکانیسم در هسته لینوکس (پچ PaX)، استفاده از قابلیت ها به جای باینری های SUID در صورت امکان، محدودیت در بارگیری ماژول های هسته، استفاده از ماژول TPM (در کروم بوک ها) برای ذخیره کلیدهای رمزگذاری دیسک و رمز عبور کاربر، منع کردن کاربر از اجرای معمولی باینریهای ELF و برخی تکنیکهای کاملاً استاندارد دیگر که بسیاری از آنها با Android و Hardened Gentoo همپوشانی دارند.
نتیجه گیری
البته، سیستم عامل کروم بسیار پیچیده تر از آن چیزی است که من در این مقاله توضیح داده ام. این تفاوت های ظریف و تعداد زیادی ایده جالب دارد. شما می توانید در مورد همه اینها در وب سایت پروژه Chromium بخوانید، زیرا نویسندگان برای توسعه دهندگان شخص ثالث باز هستند و اسناد بسیار خوبی نوشته اند.