Заглядаємо під капот Chrome OS

Що десктопні програми, та й сам десктоп рано чи пізно переїде в веб, було зрозуміло чи не після народження JavaScript, тому поява Chrome OS багато в чому передбачувана. І що хмарну ОС випустила саме Google теж абсолютно закономірно. Але давай спробуємо відійти від нескінченних дебатів про майбутнє робочого столу, що розпалюються консервативною частиною айтішників, і подивимося на Chrome OS з погляду технічної реалізації.

Дорога до хмар

Google анонсувала Chrome OS влітку 2009 року і вже в листопаді продемонструвала її публіці та виклала вихідні коди у відкритий доступ під ім'ям Chromium OS. Тоді операційна система була досить проста і була запущеним на повний екран браузером Chrome, що працює поверх сильно урізаного дистрибутива Ubuntu. В ній були реалізовані ті самі механізми ізоляції вкладок браузера і плагінів, все та ж багатопроцесна модель роботи браузера, але в цілому нічим особливим операційна система не відрізнялася.

Протягом наступних п'яти років Google безперервно, але не особливо афішуючи свою роботу, розвивала Chrome OS. Принагідно вона випускала так звані Chromebook'и та Chromebox'и, що стали популярними серед юніксоїдів, які зносили Chrome OS відразу після покупки. Поступово Gooogle відмовилася від Ubuntu на користь Gentoo (судячи з усього - щоб отримати можливість складання пакетів без «непотрібних» для неї залежностей та плюшки Hardened-версії дистрибутива) і замінила-таки одновіконний режим на стандартний для десктопів багатовіконний зі стандартною панеллю завдань знизу. Google свідомо відмовилася від нього в перших версіях Chrome OS, оскільки ОС була орієнтована на нетбуки з їхніми невеликими екранами, але, зважаючи на все, користувачі цього не оцінили.

З'явилися і офлайнові веб-програми (доступні також у звичайному Chrome) і, нарешті, підтримка ряду програм для Android. Остання подія стала цілком очікуваною після того, як керівництво розробкою обох операційних систем перейшло до рук Сундара Пічая (Sundar Pichai), який завжди був відповідальний за розвиток Chrome, Chrome OS та веб-додатків Google.

Chrome OS розвивається разом із самим браузером, тому їх версії збігаються. На момент написання статті це була версія 41, але на відміну від браузера у Chrome OS немає готових збірок для встановлення за винятком офіційно підтримуваних Chromebook і Chromebox. Однак у Мережі цілком можна знайти неофіційні збірки на базі вихідних програм Chromium OS. Наприклад, завжди можна завантажити щоденні збірки для x86, x64 та ARM. Достатньо записати одну з них на флешку та завантажитись з неї. Однак треба бути готовим, що не всі компоненти машини заведуть (у моєму випадку відвалився тачпад). До того ж Chromium OS не підтримує Flash, DRM і Netflix, проте в ній є доступ до консолі з правами root.

Базові концепції

Ключова ідея Chrome OS в тому, що за великим рахунком це ОС для тонких клієнтів, де все, окрім графічного інтерфейсу та браузера, знаходиться у Мережі. Фактично без підключення до інтернету та облікового запису Google операційка навіть не пустить користувача всередину (принаймні вперше). Файли Google пропонує зберігати у свій Google Drive (покупцям Chromebook'ів компанія дає 100 Гб), налаштування, розширення та встановлені програми синхронізуються стандартним для браузера Chrome способом. Для друку пропонується використовувати Google Cloud Print.

У російських реаліях такий підхід нічого не дає і створює багато труднощів, та й у іншому світі теж. Але Chrome OS - це заділ Google на майбутнє, і така модель роботи дозволила програмістам реалізувати низку цікавих архітектурних рішень та підходів до безпеки. Про що ми і поговоримо в частині статті, що залишилася.

Все починається з BIOS

Незважаючи на те, що Chromium OS може працювати на комп'ютерах зі стандартним BIOS, Chromebook'і базуються на CoreBoot. І це не просто одна з їхніх технічних особливостей, а навмисна оптимізація. CoreBoot – повністю 32-бітний «BIOS», позбавлений баласту з великої кількості коду ініціалізації обладнання, марного в наші дні. Разом із оптимізаціями Google він здатний виконати холодний старт від натискання кнопки живлення до завантаження ядра буквально за частки секунди.

Далі CoreBoot знаходить завантажувальний розділ GPT і завантажує в пам'ять бінарник, що містить бутлоадер u-boot (він зазвичай використовується у електроніці, що вбудовується) і ядро Linux, після чого віддає управління u-boot, і починається майже стандартна для Linux-дистрибутивів процедура завантаження, що включає в себе монтування кореневого розділу, запуск демонів, графічної системи та, нарешті, інтерфейсу.

Цікаво у всій цій процедурі те, що завантажувач з ядром і кореневою ФС має «резервні копії» в окремих розділах, і ця особливість використовується для оновлення ОС і відкату в разі збою. Під час автоматичного оновлення Chrome OS взагалі не торкається поточної установки, а натомість прописує нову версію ОС в ті самі «резервні розділи», які стають «поточними» після перезавантаження. У разі збою при завантаженні нової версії ОС відбудеться зворотна зміна місцями і користувач зможе отримати доступ до свідомо робочої системи (система сама здатна зрозуміти, що вона успішно завантажилася, і поставити відповідний прапор на поточні розділи GPT).

Більш того, на кожному етапі передачі керування від одного компонента до іншого (наприклад, від CoreBoot до u-boot) відбувається звіряння цифрового підпису (у разі кореневої ФС - поблочна звірка контрольних сум на льоту), при розбіжності якої система також відкотиться до попередньої версії . Це працює, тому що розділи з поточною версією системи монтуються лише на читання і користувач навіть не зможе їх змінити.

INFO

EEPROM Chromebook'а містить не тільки дві копії firmware (одна з яких резервна), а й неперезаписуваний recovery firmware, що дозволяє завантажити систему з USB-флешки або картки пам'яті та провести перевірку та відновлення системи.

Крім CoreBoot, EEPROM будь-якого Chromebook'а включає SeaBIOS - відкриту реалізацію BIOS, яка дозволяє без зайвого клопоту встановити на пристрій Windows або Linux.

Всюдисущий Linux

Поточні версії Chrome OS засновані на Gentoo Linux з винятком, що замість стандартної для даного дистрибутива системи ініціалізації OpenRC тут задіяний убунтівський Upstart. Порівняно зі звичайним дистрибутивом Linux система сильно урізана, тому завантажувати тут нема чого й стартує вона буквально за секунду. Звичайного терміналу немає, але є місцевий shell crosh, доступний.

Виконавши в ньому команду shell, ми отримаємо доступ до стандартного bash з правами root (в Chromium OS, звичайно) і зможемо дослідити систему. Тут є всім нам відомі демони rsyslogd, dbus-daemon (D-Bus використовується в Chrome OS для обміну даними між браузером та рештою частин системи), wpa_supplicant (аутентифікація у Wi-Fi-мережах), dhcpcd, ікси, ModemManager (робота з 3G -модемами), udev, ConnMan (керує з'єднаннями з мережею) плюс більше десятка специфічних для Chrome OS демонів, які відповідають у тому числі за оновлення системи (update_engine), роботу з TPM-модулем (chapsd), шифрування домашнього каталогу (cryptohomed), налагодження (debugd) та інші завдання.

Особливе місце займає демон session_manager, відповідальний за ініціалізацію високорівневої частини ОС. До його завдань входить:

Запустіть X-сервер.
Ініціалізувати змінні оточення для браузера Chrome.
Створити необхідні каталоги, файли та правила cgroups для Chrome.
Запустити Chrome.
Викликати Upstart-подію login-prompt-visible, у результаті на екрані з'явиться вікно логіна.

Під час цього процесу дійсно не запускаються будь-які компоненти, що відповідають за формування робочого столу (за винятком вікна логіна). Його малюванням займається сам браузер, покладаючись на фреймворк Aura, що включає низькорівневі функції для роботи з графікою та вікнами (з хардварним прискоренням через DRI) і оточення робочого столу Ash, яке малює панель завдань, декорації вікон, Google Now та інші стандартні елементи інтерфейсу ОС. Будучи частиною браузера Chrome, вони, проте, працюють усередині кількох незалежних процесів.

INFO

У разі збою завантаження системи, яка реєструється, якщо процес браузера не може бути запущений протягом 30 с, Chromium OS автоматично запускає SSH-сервер і перезапускає опитування ядра на наявність обладнання за допомогою команди udevtrigger.

Завдяки інтеграції Aura і Ash в сам Chrome отримати робочий стіл Chrome OS можна в будь-якій ОС, запустивши браузер з прапором Open-ash.

Безпека

Крім вже розглянутих методів забезпечення безпеки та цілісності даних, таких як безпечне завантаження системи, зашифрований домашній каталог з кешованими даними (шифрування виконується окремо для кожного користувача), а також стандартних для браузера Chrome методів ізоляції процесів, плагінів та Native Client від системи (тут використовується механізм seccomp-bpf, що дозволяє фільтрувати звернення до системних викликів), в Chrome OS задіяно низку інших підходів до безпеки.

Центральне місце серед них займає minijail - невелика програма, що застосовується для ізоляції системних сервісів (демонів) та інших компонентів системи. Це дуже гнучка програма, яка дозволяє виконувати такі функції, як наділення програми «можливостями» або їх відгук (capabilities - спеціальна підсистема ядра Linux для наділення не SUID-бінарників деякими можливостями root), замкнути його в chroot, відкликати права root, встановити ліміти на ресурси (rlimits), розмістити процес у виділених просторах імен (на кшталт LXC і Docker) і застосувати щодо нього правила cgroups.

Якщо поглянути на висновок ps aux|grep minijail (див. скріншот) у працюючій системі, то можна помітити, що minijail використовується для запуску демонів з тими чи іншими налаштуваннями, але кількість таких демонів по відношенню до всіх працюючих в системі не така велика . Судячи з документів розробників, у майбутньому minijail планують суттєво розширити та застосовувати його до значно більшої кількості компонентів системи, включаючи графічний стек та Chrome. Поки що є, тобто.

З інших засобів забезпечення безпеки можна відзначити застосування прапорів компілятора для мінімізації ризику зриву стека (-fno-delete-null-pointer-checks, -fstack-protector, FORTIFY_SOURCE), задіяння «посиленого» механізму ASLR (Address space layout randomization) в я (патч PaX), використання capabilities замість SUID-бінарників де це можливо, обмеження на завантаження модулів ядра, використання модуля TPM (в Chromebook'ах) для зберігання ключів шифрування диска та пароля користувача, заборона на запуск звичайних ELF-бінарників користувачем та деякі інші цілком стандартні техніки, багато з яких перетинаються з Android та Hardened Gentoo.

Висновки

Звичайно, Chrome OS набагато складніше, ніж я зміг описати у цій статті. У ній є безліч нюансів та безліч цікавих ідей. Про все це можна почитати на сайті проекту Chromium, благо автори відкриті по відношенню до сторонніх розробників і написали дуже непогану документацію.