|
|
@@ -0,0 +1,580 @@
|
|
|
+% Політика зменшення бінарних блобів
|
|
|
+% Лія Роу
|
|
|
+% 4 січня 2022 року (оновлено 15 листопада 2022 року)
|
|
|
+
|
|
|
+Вступ
|
|
|
+============
|
|
|
+
|
|
|
+**[Osboot злився з та став частиною Libreboot](merge.md) 16
|
|
|
+листопада 2022 року. Ця сторінка містить нову політику Libreboot, яка є
|
|
|
+похідною із політики osboot.**
|
|
|
+
|
|
|
+Політика Libreboot полягає в тому, щоб надати настільки, наскільки можливо, свободи
|
|
|
+кожному користувачу, на кожному підтримуваному апаратному забезпеченні та *підтримувати
|
|
|
+стільки апаратного забезпечення з coreboot, наскільки це можливо*; це означає, що ви повинні
|
|
|
+мати можливість вивчати, змінювати та *ділитися* всім джерельним кодом, документацією
|
|
|
+чи іншими подібними ресурсами, які роблять Libreboot таким, яким він є. Простіше кажучи, ви повинні
|
|
|
+мати *контроль* над своїми власними обчисленнями.
|
|
|
+
|
|
|
+*Мета* Libreboot полягає в тому, щоб
|
|
|
+зробити саме це та допомогти якомога більшій кількості людей, автоматизувавши
|
|
|
+конфігурацію, компіляцію та встановлення *coreboot* для *нетехнічних*
|
|
|
+користувачів, ще більше спростивши це для звичайного користувача, надаючи користувачам
|
|
|
+дружні інструкції для всього. По суті, Libreboot - це *дистрибутив
|
|
|
+coreboot*, приблизно так само, як *Alpine Linux* є дистрибутивом Linux!
|
|
|
+
|
|
|
+Метою цього документа є окреслення того, як це досягається, і як
|
|
|
+проект працює на цій основі. *Цей* документ здебільшого стосується
|
|
|
+ідеології, тому він (переважно) нетехнічний; для отримання технічної інформації
|
|
|
+ви можете звернутися до [документації системи збірки Libreboot](../docs/maintain/).
|
|
|
+
|
|
|
+Поточний обсяг проекту
|
|
|
+=====================
|
|
|
+
|
|
|
+Проект libreboot стосується того, що входить до основної мікросхеми завантажувальної флеш-пам'яті,
|
|
|
+але є й інші компоненти мікропрограми, які слід взяти до уваги, про що йдеться
|
|
|
+в [поширених запитаннях щодо libreboot](../faq.uk.md#яке-ще-мікропрограмне-забезпечення-існує-за-межами-libreboot).
|
|
|
+
|
|
|
+Найбільш критичні з них це:
|
|
|
+
|
|
|
+* Прошивка вбудованого контролера (EC)
|
|
|
+* Прошивка жорстких дисків/твердотілих накопичувачів
|
|
|
+* Прошивка Intel Management Engine / AMD PSP
|
|
|
+
|
|
|
+Що таке двійковий блоб?
|
|
|
+----------------------
|
|
|
+
|
|
|
+Двійковий блоб у цьому контексті - це будь-який виконуваний файл, для якого не існує вихідного коду,
|
|
|
+який ви не можете досліджувати та змінювати розумним чином. За визначенням,
|
|
|
+усі такі блоби є *пропрієтарними* за своєю природою, і їх слід уникати, якщо це можливо.
|
|
|
+
|
|
|
+Конкретні двійкові блоби також є проблематичними в більшості систем coreboot, але вони
|
|
|
+відрізняються для кожної машини. Дізнайтесь більше в розділі поширених запитань і на цій сторінці про те,
|
|
|
+як ми працюємо з двійковими блобами в проекті Libreboot.
|
|
|
+
|
|
|
+Для інформації про Intel Management Engine та AMD PSP зверніться до поширених запитань.
|
|
|
+
|
|
|
+Політика *зменшення* блобів
|
|
|
+=======================
|
|
|
+
|
|
|
+Конфігурації за замовчуванням
|
|
|
+----------------------
|
|
|
+
|
|
|
+Coreboot, на якому Libreboot базується, є здебільшого вільним програмним забезпеченням, але
|
|
|
+на деяких платформах вимагає двійкових блобів. Найпоширенішим прикладом може бути raminit
|
|
|
+(ініціалізація контролера пам'яті) або ініціалізація кадрового буфера відео. Прошивка
|
|
|
+coreboot використовує двійкові блоби для деяких з цих завдань, на деяких материнських платах,
|
|
|
+але деякі материнські плати з coreboot можна ініціалізувати з 100% вільним джерельним
|
|
|
+кодом, який ви можете перевірити та скомпілювати для свого використання.
|
|
|
+
|
|
|
+Libreboot вирішує цю ситуацію *суворо* та *принципово*. Природа
|
|
|
+цього - це те, що ви збираєтесь прочитати.
|
|
|
+
|
|
|
+Проект libreboot має наступну політику:
|
|
|
+
|
|
|
+* Якщо блоб *можна* уникнути, його слід уникати. Наприклад, якщо ініціалізація VGA ROM
|
|
|
+ в іншому випадку працює краще, але coreboot має *вільний* код ініціалізації
|
|
|
+ для певного графічного пристрою, цей код слід використовувати в libreboot під
|
|
|
+ час створення образу ROM. Подібним чином, якщо *ініціалізація контролера пам'яті* можлива
|
|
|
+ за допомогою бінарного блобу *або* вільного коду в coreboot, *вільний* код
|
|
|
+ слід використовувати в ROM, створених системою збірки Libreboot, а *блоб*
|
|
|
+ для raminit не слід використовувати; однак, якщо вільний код ініціалізації недоступний
|
|
|
+ для зазначеного raminit, це дозволено, і система збірки Libreboot використовуватиме
|
|
|
+ *блоб*.
|
|
|
+* Необхідно звернути увагу на деякі нюанси: у деяких конфігураціях ноутбуків або настільних комп'ютерів
|
|
|
+ зазвичай буде *два* графічних пристрої (наприклад, чіп nvidia та
|
|
|
+ чіп intel, використовуючи технологію nvidia optimus technology, на ноутбуці). Можливо,
|
|
|
+ один із них має вільний код ініціалізації в coreboot, а інший - ні. Абсолютно
|
|
|
+ прийнятно і бажано, щоб libreboot підтримував обидва пристрої та
|
|
|
+ розміщував необхідний двійковий блоб на тому, якому бракує власної
|
|
|
+ ініціалізації.
|
|
|
+* Виняток зроблено для оновлень мікрокоду ЦП: вони дозволені та фактично
|
|
|
+ *обов'язкові* відповідно до політики libreboot. Ці оновлення виправляють помилки ЦП, у тому
|
|
|
+ числі помилки безпеки, і оскільки ЦП уже має невільний мікрокод, записаний в
|
|
|
+ ROM в будь-якому випадку, єдиний вибір - *x86* або *зламаний x86*. Таким чином, libreboot
|
|
|
+ дозволить лише конфігурації материнської плати coreboot, де
|
|
|
+ *ввімкнено* оновлення мікрокоду, якщо доступно для ЦП на цій системній платі.
|
|
|
+* Intel Management Engine: у документації libreboot *повинні* бути написані
|
|
|
+ слова, щоб розповісти людям, як *нейтралізувати* ME, якщо це можливо на даній дошці.
|
|
|
+ Програма `me_cleaner` є дуже корисною та забезпечує набагато безпечнішу конфігурацію
|
|
|
+ ME.
|
|
|
+* Бінарні блоби *ніколи* не слід видаляти, навіть якщо вони не використовуються.
|
|
|
+ У проекті coreboot доступний набір субмодулів `3rdparty` з бінарними блобами
|
|
|
+ для завдань ініціалізації на багатьох платах. *Усі* вони повинні бути включені до випусків
|
|
|
+ libreboot, навіть якщо вони не використовуються. Таким чином, навіть якщо система збірки Libreboot
|
|
|
+ ще не підтримує певну плату, хтось, хто завантажує libreboot, все одно
|
|
|
+ може внести зміни у свою локальну версію системи збірки, якщо
|
|
|
+ забажає, щоб надати конфігурацію свого апаратного забезпечення.
|
|
|
+
|
|
|
+Загалом, застосовано здоровий глузд. Наприклад, винятком
|
|
|
+із мінімізації може бути те, що *блоб* raminit та *вільний* raminit доступні, але
|
|
|
+*вільний* так зламано, що його не можна використовувати. У такій ситуації натомість
|
|
|
+слід використовувати той, що з блобом, тому що в іншому випадку користувач може повернутися до
|
|
|
+повністю пропрієтарної системи замість використання coreboot (через libreboot).
|
|
|
+
|
|
|
+*Стара* політика Libreboot була досить суворою, забороняючи *всі* мікропрограмні блоби, і,
|
|
|
+отже, Libreboot підтримував менше апаратного забезпечення. Проект libreboot об'єднав у себя
|
|
|
+osboot, прийнявши його більш прагматичну політику. Основне повідомлення, що лежить
|
|
|
+в основі нової політики Libreboot, таке:
|
|
|
+
|
|
|
+*Деякі* свободи *краще, ніж жодних*. Старий спосіб роботи Libreboot призвів
|
|
|
+до меншої свободи для всіх, тому що Libreboot - це *єдина* прошивка,
|
|
|
+яка проста для звичайної людини, але раніше вона підтримувала лише обмежену кількість
|
|
|
+апаратного забезпечення. Багато людей мають апаратне забезпечення, яке підтримує coreboot, воно
|
|
|
+надає набагато більше свободи, ніж інакше повністю власницьке мікропрограмне забезпечення, навіть якщо
|
|
|
+користувачеві потрібно встановити один або два блоб-файли, як частину свого образу coreboot.
|
|
|
+
|
|
|
+Нова прагматична політика Libreboot також може призвести до того, що в майбутньому більше людей стануть
|
|
|
+розробниками coreboot, виступаючи в якості важливого *містка* між
|
|
|
+*ним* і нетехнічними людьми, яким просто потрібна допомога, щоб розпочати роботу.
|
|
|
+
|
|
|
+Налаштування
|
|
|
+-------------
|
|
|
+
|
|
|
+Наведені вище принципи мають застосовуватися до конфігурацій *за замовчуванням*. Однак libreboot
|
|
|
+має бути *конфігурованим*, дозволяючи користувачеві робити все, що заманеться.
|
|
|
+
|
|
|
+Цілком природно, що користувач може захотіти створити *менш* вільний параметр, ніж
|
|
|
+стандартний у libreboot. Це цілком прийнятно; свобода вище,
|
|
|
+і її слід заохочувати, але *свободу вибору* користувача
|
|
|
+також слід поважати та пристосовуватись до неї.
|
|
|
+
|
|
|
+Іншими словами, не читайте лекції користувачеві. Просто спробуйте допомогти їм у
|
|
|
+їхній проблемі! Метою проекту libreboot є просто зробити coreboot більш
|
|
|
+доступним для нетехнічних користувачів.
|
|
|
+
|
|
|
+КАТАЛОГ СВОБОДИ
|
|
|
+===============
|
|
|
+
|
|
|
+Також має бути доступна сторінка *статусу блобів*, яка інформуватиме людей про
|
|
|
+статус бінарних блобів на кожній машині, що підтримується системою збірки Libreboot.
|
|
|
+
|
|
|
+Бажано бачити світ, де все апаратне та програмне забезпечення є вільним, під
|
|
|
+тією ж ідеологією, що й проект Libreboot. Обладнання!?
|
|
|
+
|
|
|
+Так, обладнання. RISC-V є чудовим прикладом сучасної спроби вільного апаратного забезпечення, яке
|
|
|
+часто називають *Апаратним забезпеченням з відкритим кодом*.
|
|
|
+Це ISA для виробництва мікропроцесора. Уже існує багато реальних
|
|
|
+реалізацій, які можна використовувати, і їх буде лише
|
|
|
+більше.
|
|
|
+
|
|
|
+Таке *апаратне забезпечення* ще знаходиться в зародковому стані. Ми повинні почати проект, який
|
|
|
+буде каталогізувати статус різних зусиль, у тому числі на апаратному рівні (навіть на
|
|
|
+рівні кремнію). Такі рухи, як OSHW і Право на ремонт (Right To Repair), є надзвичайно
|
|
|
+важливими, включно з нашим власним рухом, який інакше зазвичай менше думатиме про свободу апаратного
|
|
|
+забезпечення (хоча йому справді, справді
|
|
|
+варто!)
|
|
|
+
|
|
|
+Одного дня ми житимемо у світі, де будь-хто зможе виготовити власні чіпи,
|
|
|
+включаючи процесори, а також будь-які інші типи мікросхем. Зусилля зробити домашнє виробництво
|
|
|
+чіпів реальністю зараз знаходяться в зародковому стані, але такі зусилля існують,
|
|
|
+наприклад, робота, виконана Семом Зелофом і проектом Libre Silicon:
|
|
|
+
|
|
|
+* <https://www.youtube.com/channel/UC7E8-0Ou69hwScPW1_fQApA>
|
|
|
+* <http://sam.zeloof.xyz/>
|
|
|
+* <https://libresilicon.com/>
|
|
|
+
|
|
|
+(Сем буквально виробляє процесори в своєму гаражі)
|
|
|
+
|
|
|
+Проблеми з критеріями RYF
|
|
|
+==========================
|
|
|
+
|
|
|
+Раніше Libreboot відповідав критеріям FSF RYF, але тепер він дотримується
|
|
|
+набагато більш прагматичної політики, спрямованої на надання більшої свободи більшій кількості людей у
|
|
|
+більш прагматичний спосіб. Ви можете прочитати ці вказівки, перейшовши за цією URL-адресою:
|
|
|
+
|
|
|
+* Рекомендації FSF Поважає Вашу Свободу (RYF): **https://ryf.fsf.org/about/criteria**
|
|
|
+
|
|
|
+Простіше кажучи, інструкції RYF стосуються комерційних продуктів із застереженням,
|
|
|
+що вони не повинні містити пропрієтарне програмне забезпечення чи відомі проблеми конфіденційності,
|
|
|
+як-от лазівки.
|
|
|
+
|
|
|
+Повне виключення всього пропрієтарного забезпечення наразі неможливе. Наприклад,
|
|
|
+пропрієтарне мікропрограмне забезпечення SDR у чіпсетах WiFi, мікропрограмне забезпечення пристроїв AHCI, таких як
|
|
|
+жорсткі диски або твердотілі накопичувачі тощо. В інструкціях FSF RYF зазначено наступний виняток, щоб пом'якшити цей факт:
|
|
|
+
|
|
|
+* "Однак є один виняток для вторинних вбудованих процесорів. Виняток стосується програмного забезпечення, що постачаєтья в бічних допоміжних і низькорівневих процесорах та FPGA, у яких встановлення програмного забезпечення не передбачається після того, як користувач отримає продукт. Це може включати, наприклад, мікрокод всередині процесора, мікропрограму, вбудовану в пристрій вводу-виводу, або структуру вентилів FPGA. Програмне забезпечення в таких вторинних процесорах не вважається програмним забезпеченням продукту."
|
|
|
+
|
|
|
+Цей виняток порушує всі принципи, за які стоїть FSF, *та має бути відхилено
|
|
|
+з ідеологічних міркувань*. Решта політики libreboot і загальна
|
|
|
+ідеологія, виражена в цій статті, базуватиметься в основному на цьому неприйнятті.
|
|
|
+Визначення *програмного забезпечення продукту* абсолютно довільне; програмне забезпечення
|
|
|
+є програмне забезпечення, а програмне забезпечення завжди має бути *вільним*. Замість того, щоб робити такі
|
|
|
+винятки, слід заохочувати більше апаратного забезпечення, допомогаючи надавати якомога
|
|
|
+більше свободи, одночасно надаючи користувачам інформацію про будь-які підводні
|
|
|
+камені, з якими вони можуть зіткнутися, і заохочувати свободу на всіх рівнях. Коли така організація,
|
|
|
+як FSF, робить такі сміливі винятки, як вище, вона надсилає неправильне повідомлення,
|
|
|
+кажучи людям, по суті, заховати ці інші проблеми лише тому, що вони стосуються програмного забезпечення,
|
|
|
+яке працює на "вторинному процесорі".
|
|
|
+Якщо користувач може оновити програмне забезпечення, воно має бути вільним,
|
|
|
+незалежно від того, *передбачав* виробник оновлення чи ні.
|
|
|
+Там де справді *не* можливо оновити таке програмне забезпечення, пропрієтарне чи ні,
|
|
|
+слід надати поради щодо цього. Освіта важлива, і критерії FSF
|
|
|
+активно перешкоджають такій освіті; це створює помилкову надію, що
|
|
|
+все добре і чудово, лише тому, що програмне забезпечення на одному довільному
|
|
|
+рівні ідеальне.
|
|
|
+
|
|
|
+Цей погляд FSF, виражений у цитованому абзаці, припускає,
|
|
|
+що системою керує переважно *один* головний процесор. На багатьох
|
|
|
+сучасних комп'ютерах це *більше не відповідає дійсності*.
|
|
|
+
|
|
|
+Вільне *програмне забезпечення* не існує у вакуумі, але ми мали менше свободи в
|
|
|
+минулому, особливо коли справа стосувалася апаратного забезпечення, тому *ПЗ* було нашим основним фокусом.
|
|
|
+
|
|
|
+Здатність вільно вивчати, адаптувати, обмінюватися та використовувати/повторно використовувати ПЗ є важливою,
|
|
|
+але є багато нюансів, коли справа доходить до *завантажувального мікропрограмного забезпечення*, нюансів, які
|
|
|
+здебільшого не існують поза розробкою мікропрограмного забезпечення чи поза розробкою ядра.
|
|
|
+Більшість типового прикладного/системного програмного забезпечення є високорівневим і портативним, але
|
|
|
+завантажувальна мікропрограма має бути написана для кожної конкретної машини, і через те, як
|
|
|
+апаратне забезпечення працює, існує багато компромісів, зокрема FSF, коли
|
|
|
+визначає які стандарти слід застосовувати *на практиці*.
|
|
|
+
|
|
|
+Той факт, що майже ніхто не говорить про прошивку EC, *пов'язаний* із
|
|
|
+сертифікацією Поважає Вашу Свободу (Respects Your Freedom). Насправді мікропрограмне забезпечення EC має вирішальне
|
|
|
+значення для свободи користувачів і повинно бути вільним, але FSF повністю ігнорує його як
|
|
|
+*частину апаратного забезпечення*. Це неправильно, і FSF має активно
|
|
|
+заохочувати людей визволяти його на кожному ноутбуці!
|
|
|
+
|
|
|
+Інше мікропрограмне забезпечення, яке наразі не доступне для проекту libreboot, описано на
|
|
|
+сторінці поширених питань libreboot. Наприклад, прошивка жорстких дисків/твердотілих накопичувачів описана в розділі поширених запитань.
|
|
|
+Знову ж таки, повністю проігноровано та знизано плечима FSF.
|
|
|
+
|
|
|
+Проект libreboot не буде приховувати або пропускати ці проблеми, тому що вони
|
|
|
+справді є критичними, але, знову ж таки, наразі виходять за межі того, що робить система збірки Libreboot
|
|
|
+На даний момент, система збірки Libreboot займається лише
|
|
|
+coreboot (і корисними навантаженнями), але в майбутньому це має змінитися.
|
|
|
+
|
|
|
+Приклади *замітання блобів під килим* FSF
|
|
|
+----------------------------------------------
|
|
|
+
|
|
|
+Протягом багатьох років було багато випадків, коли FSF активно не
|
|
|
+заохочував рівень свободи програмного забезпечення, наприклад:
|
|
|
+
|
|
|
+* Робоча станція TALOS II "OpenPOWER" від Raptor Engineering USA. Вона містить
|
|
|
+ мережеву плату Broadcom в собі, яка потребує прошивки, і ця прошивка була невільною.
|
|
|
+ FSF були готові проігнорувати це та сертифікувати продукт TALOS II відповідно до RYF,
|
|
|
+ але Тімоті Пірсон із Raptor Engineering все одно звільнив її, хоча йому навіть
|
|
|
+ про це не було сказано. Гуго Ландау розробив специфікацію, а Еван Лоєвскі
|
|
|
+ написав вільну прошивку. Дивіться:
|
|
|
+ <https://www.devever.net/~hl/ortega> та <https://github.com/meklort/bcm5719-fw>
|
|
|
+* FSF свого часу схвалив ThinkPad X200, який продавав [Minifree Ltd](https://minifree.org),
|
|
|
+ який містить Intel ME; bootrom все ще там, як і співпроцесор ME,
|
|
|
+ але ME переведено в вимкнений стан через Intel Flash
|
|
|
+ Descriptor, а мікропрограму ME у флеш-пам'яті видалено. Однак ME - це цілий
|
|
|
+ співпроцесор, який з вільною прошивкою можна було би використовувати для багатьох
|
|
|
+ речей. У проектах Libreboot та coreboot завжди був інтерес до цього,
|
|
|
+ але FSF повністю ігнорує це. Продукт X200, який вони сертифікували,
|
|
|
+ постачався з попередньо встановленим Libreboot.
|
|
|
+* У Libreboot є утиліта, написана мною, Лією Роу, яка створює флеш-дескриптори ICH9M і образи
|
|
|
+ GbE NVM з нуля. Це необхідно для налаштування
|
|
|
+ машини, але інакше це двійкові блоб-файли; FSF був би цілком
|
|
|
+ задоволений сертифікацією апаратного забезпечення в будь-якому випадку, оскільки це були непрограмні
|
|
|
+ блоби у форматі, повністю задокументованому Intel (це лише двійкові конфігураційні
|
|
|
+ файли), але я все одно пішла вперед і написала ich9gen. За допомогою ich9gen ви можете
|
|
|
+ легше змінювати регіони дескриптора/gbe для вашого образу мікропрограмного забезпечення. Дивіться:
|
|
|
+ <https://libreboot.org/docs/install/ich9utils.html> - libreboot також має це
|
|
|
+* FSF свого часу схвалив ThinkPad T400 з Libreboot, який продавав Minifree. Ця
|
|
|
+ машина доступна в двох версіях: з графічним процесором ATI+Intel або лише Intel. Якщо ATI
|
|
|
+ GPU, можна налаштувати машину так, щоб використовувався будь-який GPU. Якщо буде використовуватися
|
|
|
+ графічний процесор ATI, для ініціалізації потрібен блоб мікропрограми, хоча драйвер для нього
|
|
|
+ повністю вільний. *FSF* проігнорувала цей факт і схвалила апаратне забезпечення,
|
|
|
+ доки Libreboot не вмикає графічний процесор ATI і не повідомляє людям, як його
|
|
|
+ увімкнути. Графічний процесор *Intel* на цій машині має вільний код ініціалізації
|
|
|
+ від проекту coreboot і повністю вільний драйвер в обох ядрах Linux та BSD.
|
|
|
+ У конфігурації, наданій Libreboot, ATI GPU повністю вимкнено
|
|
|
+ та виключено.
|
|
|
+* Усі ноутбуки ThinkPad, сумісні з Libreboot, містять невільне мікропрограмне забезпечення вбудованого контролера,
|
|
|
+ яке можна прошивати користувачем (*і призначене для оновлення
|
|
|
+ виробником*). FSF вирішила ігнорувати прошивку EC, відповідно до
|
|
|
+ свого винятку *вторинного процесора*. Дивіться:
|
|
|
+ <http://libreboot.org/faq.uk.html#прошивка-ec-вбудований-контролер>
|
|
|
+
|
|
|
+У всіх вищезазначених випадках FSF міг бути суворішим і сміливішим, наполягаючи
|
|
|
+на тому, що ці *додаткові* проблеми свободи були вирішені. Вони цього не
|
|
|
+зробили. Є багато інших прикладів цього, але мета цієї статті
|
|
|
+не перелічити їх усі (інакше на цю тему можна були б написати книгу).
|
|
|
+
|
|
|
+Проблеми з FSDG
|
|
|
+------------------
|
|
|
+
|
|
|
+<img tabindex=1 src="https://av.libreboot.org/firmware.uk.png" /><span class="f"><img src="https://av.libreboot.org/firmware.png" /></span>
|
|
|
+
|
|
|
+FSF підтримує ще один набір критеріїв, які називаються Правилами вільного
|
|
|
+розповсюдження системи (GNU FSDG)]
|
|
|
+
|
|
|
+Критерії FSDG відрізняються від RYF, але мають подібні проблеми. FSDG - це
|
|
|
+те, чому відповідають схвалені FSF дистрибутиви GNU+Linux. По суті, він забороняє
|
|
|
+все пропрієтарне програмне забезпечення, включаючи мікропрограму пристрою. Це може здатися благородним, але
|
|
|
+вкрай проблематично в контексті прошивки. Їжа для роздумів:
|
|
|
+
|
|
|
+* Виключення мікропрограмним блобів із ядра linux - це *погано*. Пропрієтарна прошивка
|
|
|
+ є *також поганою*. Включення їх є мудрішим вибором, якщо також забезпечується сильна освіта
|
|
|
+ про те, *чому вони погані* (менше свободи). Якщо ви відкриєте їх для
|
|
|
+ користувача та повідомите йому про це, з'явиться більше стимулів (через просте
|
|
|
+ нагадування про їх існування) провести зворотне проектування та замінити їх.
|
|
|
+* Прошивка *в ядрі вашої ОС* *хороша*. FSF одночасно дає дозвіл на
|
|
|
+ апаратне забезпечення *з тими самими блобами прошивки*, якщо прошивка вбудована в
|
|
|
+ ROM/флеш-пам'ять на пристрої або вбудована в якийсь процесор. Якщо
|
|
|
+ вбудоване програмне забезпечення знаходиться на окремому ROM/флеш-пам'яті, його все одно можна замінити
|
|
|
+ користувачем за допомогою зворотного проектування, але тоді вам, ймовірно, доведеться провести деяку пайку
|
|
|
+ (замінити чіп на картці/пристрої). *Якщо мікропрограма завантажується ядром
|
|
|
+ ОС, тоді вона відкрита для користувача, і її можна легше замінити.
|
|
|
+ Критерії FSF у цьому відношенні заохочують розробників апаратного забезпечення
|
|
|
+ приховувати вбудоване програмне забезпечення, що робить фактичну (програмну) свободу менш імовірною!*
|
|
|
+
|
|
|
+Окрім цього, FSDG здається нормальним. Будь-яка вільна операційна система має в ідеалі не містити
|
|
|
+пропрієтарних *драйверів* або *застосунків*.
|
|
|
+
|
|
|
+Виробники обладнання полюбляють заштовхувать все в мікропрограмне забезпечення, оскільки їх
|
|
|
+продукт часто має поганий дизайн, тому вони пізніше хочуть надати вирішення в
|
|
|
+прошивці для налагодження проблемних питань. В багатьох випадках, пристрій вже матиме прошивку в собі,
|
|
|
+але вимагає оновлення, надане йому вашим ядром ОС.
|
|
|
+
|
|
|
+Найбільш поширений приклад пропрієтарної прошивки в Linux для пристроїв wifi.
|
|
|
+Це цікавий сценарій використання, з джерельним кодом, тому що його може бути
|
|
|
+використано для контрольованого власником *software defined radio*.
|
|
|
+
|
|
|
+Шлях *Debian* є ідеальним. Дистрибутив Debian GNU+Linux повністю вільний
|
|
|
+за замовчуванням, і вони включають додаткову прошивку за необхідності, яку вони мають в
|
|
|
+окремому репозиторії, що містить її. Якщо ви хочете тільки прошивку, тривіально
|
|
|
+взяти образи встановлювача з нею доданою, або додати її до вашої встановленої
|
|
|
+системи. Вони розповідають вам, як зробити це, що означає, що вони допомогають людям
|
|
|
+отримати *деяку* свободу, *замість ніякої*. Це невід'ємно прагматичний
|
|
|
+спосіб робити справи, і це те, як це робить Libreboot.
|
|
|
+
|
|
|
+Більше контексту, стосовно Debian, доступно в публікації цього блога:
|
|
|
+<https://blog.einval.com/2022/04/19#firmware-what-do-we-do> - в ньому, автор,
|
|
|
+відомий розробник Debian, робить чудовий акцент про прошивку
|
|
|
+пристроїв, подібну до статті (Libreboot), яку ви зараз читаєте. Її
|
|
|
+варто прочитати! Станом на жовтень 2022 року, Debian проголосував за включення прошивки пристроїв
|
|
|
+за *замовчуванням*, в наступних випусках Debian. Раніше Debian виключав таке
|
|
|
+мікропрограмне забезпечення, але дозволяв вам його додавати.
|
|
|
+
|
|
|
+OpenBSD майже така сама, але вони розумні в цьому: під час початкового
|
|
|
+завантаження, після інсталяції, він повідомляє вам, яке мікропрограмне забезпечення потрібно,
|
|
|
+і оновляє його для вас. Це дуже прозоро обробляється їхньою
|
|
|
+програмою `fw_update`, про яку ви можете прочитати тут:
|
|
|
+
|
|
|
+<https://man.openbsd.org/fw_update>
|
|
|
+
|
|
|
+*Заборона* прошивки linux конкретно є загрозою свободі в довгостроковій перспективі,
|
|
|
+тому що нові користувачі GNU+Linux можуть бути відбиті від використання ОС, якщо їх
|
|
|
+апаратне забезпечення не працює. Ви можете сказати: просто купіть нове обладнання! Це часто неможливо
|
|
|
+для користувачів, і користувач також може не мати навичок для
|
|
|
+зворотного проектування.
|
|
|
+
|
|
|
+Більш детальна інформація про мікрокод
|
|
|
+=====================================
|
|
|
+
|
|
|
+Щоб було зрозуміло: бажано, щоб мікрокод був вільним. Мікрокод систем Intel
|
|
|
+та AMD *є* пропрієтарним. Факти і почуття рідко збігаються; метою цього
|
|
|
+розділу є поширення *фактів*.
|
|
|
+
|
|
|
+Система збірки libreboot тепер дозволяє оновлення мікрокоду *за замовчуванням.*
|
|
|
+
|
|
|
+Відсутність оновлень мікрокоду ЦП є абсолютною катастрофою для стабільності
|
|
|
+та безпеки системи.
|
|
|
+
|
|
|
+Що ще гірше, той самий текст, цитований із критеріїв FSF RYF,
|
|
|
+насправді конкретно згадує мікрокод. Знову процитую для нащадків:
|
|
|
+
|
|
|
+*"Однак є один виняток для вторинних вбудованих процесорів. Виняток
|
|
|
+стосується програмного забезпечення, що постачається всередині допоміжних і низкорівневих
|
|
|
+процесорів та FPGA, у яких інсталяція програмного забезпечення не передбачається після того,
|
|
|
+як користувач отримає продукт. Це може включати, наприклад, мікрокод всередині
|
|
|
+процесора, мікропрограму, вбудовану в пристрій вводу-виводу, або структуру вентилів FPGA.
|
|
|
+Програмне забезпечення в таких вторинних процесорах не вважається програмним забезпеченням продукту."*
|
|
|
+
|
|
|
+Тут обговорюється мікрокод, який записується в *mask ROM* на самому
|
|
|
+ЦП. Одночасно він не дає ОК для *оновлень* мікрокоду, які надаються
|
|
|
+coreboot або ядром Linux; згідно з FSF, це напад на
|
|
|
+вашу свободу, але старіший мікрокод із більшими помилками, записаний на ROM, є нормальним.
|
|
|
+Це абсолютно непослідовно.
|
|
|
+
|
|
|
+ЦП вже має мікрокод, записаний в mask ROM. Мікрокод налаштовує
|
|
|
+логічні вентилі в ЦП, для реалізації набору інструкцій через спеціальні *декодери*,
|
|
|
+які мають фіксовану функцію; неможливо, наприклад, реалізувати набір інструкцій RISCV
|
|
|
+на процесорі x86. Для мікрокода можливо тільки
|
|
|
+реалізувати x86, або *зламаний* x86, і мікрокод за замовчуваням майже завжди є
|
|
|
+*зламаним x86* на ЦП Intel/AMD; це неминуче через складність цих
|
|
|
+процесорів.
|
|
|
+
|
|
|
+Основою розбіжностей FSF щодо *оновлень* мікрокоду є те, що
|
|
|
+вони вірять в інше; Столлман сам висловив мені таке невігластво в розмові електронною поштою,
|
|
|
+яку я мала з ним 2 січня 2022 року. FSF вважає,
|
|
|
+що ці оновлення мікрокоду x86 (для Intel/AMD) дозволяють повністю створити новий
|
|
|
+ЦП, який принципово відрізняється від x86. Це не правда. Також неправда,
|
|
|
+що *всі* інструкції в наборі інструкцій x86 реалізовано за допомогою мікрокоду. У
|
|
|
+деяких випадках використовується жорстко закодована схема! Оновлення мікрокоду більше нагадують
|
|
|
+крихітні одиничні патчі тут і там у сховищі git, за аналогією.
|
|
|
+Щоб знову потрапити у головний простір FSF: ці оновлення не можуть зробити ЦП
|
|
|
+еквівалентом рефакторингу всієї кодової бази. Це *гарячі виправлення*, нічого
|
|
|
+більше!
|
|
|
+
|
|
|
+Невиключення цих оновлень призведе до нестабільного/невизначеного стану. Intel
|
|
|
+сама визначає, які помилки впливають на які ЦП, і вони визначають обхідні шляхи або надають
|
|
|
+виправлення в мікрокоді. Виходячи з цього, таке програмне забезпечення, як ядро Linux
|
|
|
+може обійти ці помилки/примхи. Крім того, апстрім версії ядра Linux
|
|
|
+можуть оновити мікрокод під час завантаження (однак все одно рекомендується робити це
|
|
|
+з coreboot для більш стабільної ініціалізації контролера пам'яті або “raminit”).
|
|
|
+Подібне можна сказати і про ЦП AMD.
|
|
|
+
|
|
|
+Ось кілька прикладів того, як відсутність оновлень мікрокоду вплинула на *Libreboot*,
|
|
|
+змусивши Libreboot обійти зміни, внесені в апстрім coreboot, зміни,
|
|
|
+які були *хорошими* і зробили coreboot більш сумісним зі стандартами відповідно до
|
|
|
+специфікацій Intel. Libreboot довелося *поламати* coreboot, щоб зберегти деякі
|
|
|
+інші функції на деяких Thinkpad GM45/ICH9M:
|
|
|
+
|
|
|
+<https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0012-fix-speedstep-on-x200-t400-Revert-cpu-intel-model_10.patch?id=9938fa14b1bf54db37c0c18bdfec051cae41448e>
|
|
|
+
|
|
|
+<https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0018-Revert-cpu-intel-Configure-IA32_FEATURE_CONTROL-for-.patch?id=4b7be665968b67463ec36b9afc7e8736be0c9b51>
|
|
|
+
|
|
|
+Ці патчі повертають *виправлення помилок* у coreboot, виправлення, які порушують
|
|
|
+інші функції, але лише якщо оновлення мікрокоду виключено. Найбільш
|
|
|
+правильним з технічної точки зору рішенням є *не* застосування наведених вище патчів, а натомість
|
|
|
+оновлення мікрокоду!
|
|
|
+
|
|
|
+Виберіть свою отруту. Недодавання оновлень є *безвідповідальним* і, зрештою,
|
|
|
+марним, оскільки ви все одно отримуєте пропрієтарний мікрокод, ви просто отримуєте
|
|
|
+старішу, з більшими помилками, версію натомість!
|
|
|
+
|
|
|
+Система збірки libreboot *більше не* застосовує два патчі, на які посилається вище!
|
|
|
+Натомість, оновлення мікрокоду ЦП увімкнено за замовчуванням на платах, уражених проблемою.
|
|
|
+Результатом є чудове керування функціями IA32 та додана підтримка PECI.
|
|
|
+
|
|
|
+*Проект libreboot* повністю відкидає вузький, догматичний погляд FSF.
|
|
|
+
|
|
|
+Ця зміна в політиці проекту зовсім не впливає на вашу свободу,
|
|
|
+тому що в іншому випадку ви все одно маєте старіший мікрокод із більшими помилками. Однак він покращує
|
|
|
+надійність системи, включаючи оновлення!
|
|
|
+
|
|
|
+Така прагматична політика *перевершує* *догму*, яку колись
|
|
|
+доводилося терпіти користувачам Libreboot. Простіше кажучи, проект Libreboot має на меті надати користувачам
|
|
|
+якомога більше свободи для їх апаратного забезпечення; так було завжди,
|
|
|
+але цей менталітет тепер застосовується до [набагато] більшої кількості обладнання.
|
|
|
+
|
|
|
+Інші міркування
|
|
|
+====================
|
|
|
+
|
|
|
+Також Libreboot не покриває суворо: OSHW і Право на ремонт (Right To Repair). Однак свобода
|
|
|
+на рівні кремнію була б дивовижною, і зусилля вже є; наприклад, подивіться на RISCV ISA (на
|
|
|
+практиці фактичне виготовлення все ще є пропрієтарним і не під вашим контролем, але RISCV є повністю вільним
|
|
|
+дизайном ЦП, який компанії можуть використовувати замість того, щоб використовувати пропрієтарний ARM/x86 і
|
|
|
+так далі). Подібним чином, Право на ремонт (можливість відремонтувати свій власний пристрій, що
|
|
|
+передбачає вільний доступ до схем і діаграм) є критично важливим з тієї ж причини, що
|
|
|
+критично важливо вільне програмне забезпечення (Право на хакерство)!
|
|
|
+
|
|
|
+OSHW і Право на ремонт взагалі не охоплюються RYF (критерії FSF Поважає Вашу
|
|
|
+Свободу), критеріями, яких Libreboot дотримувався раніше..
|
|
|
+RYF також робить кілька поступок, які зрештою завдають шкоди, наприклад,
|
|
|
+політика *програмне забезпечення як схема*, яка, чесно кажучи, є безглуздою. ROM все ще
|
|
|
+програмне забезпечення. Був час, коли FSF не вважав програмне забезпечення BIOS проблемою
|
|
|
+свободи, лише тому, що воно записане на mask ROM, а не *прошито*; ця
|
|
|
+політика FSF ігнорує той факт, що, маючи відповідні навички паяння, легко замінити
|
|
|
+автономні мікросхеми mask ROM на сумісну флеш-пам'ять.
|
|
|
+
|
|
|
+Висновки
|
|
|
+==========
|
|
|
+
|
|
|
+Компроміс і нюанси - це назва гри, навіть якщо ви FSF. Це абсолютно
|
|
|
+неминуче, але є деякі, хто намагається заперечувати цей факт і
|
|
|
+вдавати, ніби все відбувається так, як вони хотіли б, щоб воно було, а не те, яким воно є
|
|
|
+насправді в реальному світі.
|
|
|
+
|
|
|
+Факти та *почуття* зазвичай дуже різні речі та суперечливі.
|
|
|
+
|
|
|
+RYF сам по собі не є *неправильним*, просто має недоліки. Певним чином це правильно, і
|
|
|
+якщо його дотримуватися, результат *надає* багато свобод користувачеві, але RYF
|
|
|
+повністю ігнорує багато речей, які зараз можливі, включаючи свободи на
|
|
|
+апаратному рівні (критерії RYF охоплюють лише *програмне забезпечення*). Ці вказівки
|
|
|
+написані з припущеннями, які все ще були вірними в 1990-х роках, але відтоді
|
|
|
+світ змінився. Проект libreboot повністю відкидає цю політику та натомість
|
|
|
+використовує прагматичний підхід.
|
|
|
+
|
|
|
+Висновок, який слід зробити з усього цього, такий:
|
|
|
+
|
|
|
+*Дотримання* критеріїв FSF нічого не шкодить, але ці критерії є дуже
|
|
|
+консервативними. Його винятки слід *ігнорувати* та повністю ігнорувати. RYF
|
|
|
+більше не відповідає меті, і його слід переписати, щоб створити *більш суворий*
|
|
|
+набір інструкцій без усіх лазівок чи винятків.
|
|
|
+Як завжди було, Libreboot намагається завжди виходити за межі, але
|
|
|
+проект Libreboot не розглядає RYF як *золотий стандарт*. Зараз є
|
|
|
+можливі рівні свободи, які вказівки RYF взагалі не охоплюють, а
|
|
|
+в деяких випадках навіть активно не заохочують/перешкоджають, оскільки це робить компроміси
|
|
|
+на основі припущень, які більше не відповідають дійсності.
|
|
|
+
|
|
|
+Сумна правда: RYF активно заохочує *менше* свободи, не будучи достатньо сміливим.
|
|
|
+Він встановлює прапор перемоги та говорить *місію виконано*, незважаючи на те, що
|
|
|
+робота *далека* від завершення!
|
|
|
+
|
|
|
+Якщо дотримуватись *з незаперечними винятками*, RYF може в деяких випадках заохочувати
|
|
|
+компанії *приховувати* будь-які проблеми зі свободою, які існуюють,
|
|
|
+коли це стосується пропрієтарного мікропрограмного забезпечення, яке не працює на центральному процесорі хоста (наприклад, мікропрограмне забезпечення
|
|
|
+вбудованого контролера).
|
|
|
+
|
|
|
+Я пропоную написати нові рекомендації, щоб замінити RYF. Ці нові правила
|
|
|
+ліквідують усі винятки/лазівки та вимагають, щоб *все* програмне забезпечення
|
|
|
+було вільним на машині або якомога більше. Замість того, щоб лише рекламувати продукти,
|
|
|
+які відповідають певним стандартам, просто каталогізуйте всі системи у великій
|
|
|
+*базі даних* свого роду (наприклад, h-node.org, але краще), яка точно визначатиме, які
|
|
|
+*апаратні* **і** програмні проблеми існують на кожному пристрої. Включіть Право
|
|
|
+на ремонт і OSHW (включно з такими речами, як RISCV) до найбільш "ідеальної"
|
|
|
+стандартної машини; золотим стандартом є вільний *кремній*, як те, над чим
|
|
|
+Сем Зелоф та інші працюють зараз.
|
|
|
+
|
|
|
+Цей новий набір критеріїв не повинен намагатися приховати або проігнорувати *щось*. Це
|
|
|
+має заохочувати людей розширювати рамки та впроваджувати інновації, щоб ми могли мати
|
|
|
+набагато *більше* свободи, ніж зараз можливо. Необхідність є матір'ю всіх
|
|
|
+винаходів, а свобода є важливою метою в кожному аспекті життя, не лише в
|
|
|
+обчисленні.
|
|
|
+
|
|
|
+Не називайте це "Поважає вашу свободу" чи щось подібне. Натомість назвіть це
|
|
|
+приблизно так: каталог свободи. І насправді зосередьтеся на апаратному забезпеченні, а не
|
|
|
+лише на програмному забезпеченні!
|
|
|
+
|
|
|
+У 2022 році ми можемо бути краще. Програму RYF слід скасувати.
|
|
|
+Вона більше не підходить для цілей.
|
|
|
+
|
|
|
+Інші ресурси
|
|
|
+===============
|
|
|
+
|
|
|
+Повідомлення в блозі RYF Аріадни Конілл
|
|
|
+------------------------------
|
|
|
+
|
|
|
+Аріадна Конілл, голова групи безпеки *Alpine Linux*, опублікувала дуже серйозну
|
|
|
+статтю про RYF, у якій висловлено схожі моменти в порівнянні з *цією* статтею.
|
|
|
+Однак Аріадна докладно розглядає кілька інших прикладів проблем із
|
|
|
+критеріями FSF RYF; наприклад, йдеться про продукт *Novena* від
|
|
|
+Bunnie.
|
|
|
+
|
|
|
+Варто прочитати! Посилання:
|
|
|
+
|
|
|
+<https://ariadne.space/2022/01/22/the-fsfs-relationship-with-firmware-is-harmful-to-free-software-users/>
|
|
|
+
|
|
|
+Тема RYF Гектора Мартіна
|
|
|
+--------------------------
|
|
|
+
|
|
|
+Гектор Мартін, керівник проекту *Asahi Linux* (для завантаження ядер Linux
|
|
|
+на macbook M1) написав дуже серйозну гілку в twitter, критикуючи критерії RYF,
|
|
|
+і багато з того, що він написав, надихнуло *цю* статтю, яку ви читаєте. Побачити:
|
|
|
+
|
|
|
+<http://web.archive.org/web/20220326234344/https://twitter.com/marcan42/status/1040626210999431168>
|
|
|
+
|
|
|
+Оновлення статті
|
|
|
+===============
|
|
|
+
|
|
|
+23 січня 2022 року
|
|
|
+---------------
|
|
|
+
|
|
|
+Додано посилання на статтю Аріадни Коніл.
|
|
|
+
|
|
|
+21 січня 2022 року
|
|
|
+---------------
|
|
|
+
|
|
|
+Цю статтю було оновлено 21 січня 2022 року, щоб додати розділ із реальними прикладами FSF,
|
|
|
+які прибирають блоби під килим (Thinkpad ATI T400,
|
|
|
+ICH9M дескриптори і прошивка мережевої карти TALOS II).
|
|
|
+
|
|
|
+Також 21 січня 2022 року: додано розділ про FSDG (критика щодо нього).
|
|
|
+
|
|
|
+Також 21 січня 2022 року: додано посилання на гілку Гектора Мартіна у Twitter.
|
Vladislav Shapovalov
Leah Rowe