purge remaining stragglers
fsf has never had any say over libreboot; i have. it was all me, but i used to be part of their cult. i no longer am. this is housecleaning. Signed-off-by: Leah Rowe <info@minifree.org>master
Leah Rowe
parent
96e51ca06e
commit
cb8dbd0f38
|
|
@ -196,33 +196,13 @@ systems.
|
|||
Joshua Gay
|
||||
----------
|
||||
|
||||
Joshua is former FSF staff.
|
||||
Joshua was in a position during 2014-2016 to help promote Libreboot in the
|
||||
media, in his capacity working for the employer he worked for at the time;
|
||||
I credit him specifically. Joshua was one of Libreboot's earliest supporters.
|
||||
|
||||
Joshua helped with the early founding of the Libreboot project, in his capacity
|
||||
(at that time) as the FSF's licensing and compliance manager. It was his job to
|
||||
review products sent into to the FSF for review; the FSF has a certification
|
||||
program called *Respects Your Freedom* (RYF) where the FSF will promote your
|
||||
company's products if it comes with all Free Software.
|
||||
|
||||
I, Leah Rowe, was initially just selling ThinkPad X60 laptops with regular
|
||||
coreboot on them, and this included CPU microcode updates. At the time, I didn't
|
||||
think much of that. Joshua contacted me, in his capacity at the FSF, and asked
|
||||
if I would be interested in the FSF's RYF program; I was very surprised that the
|
||||
FSF would take me seriously, and I said yes. This is what started the early
|
||||
work on Libreboot. Joshua showed me all the problems my products had, and from
|
||||
that, the solution was clear:
|
||||
|
||||
Joshua used his media connections at the FSF to heavily promote my work, and
|
||||
on December 13th, 2013, the Libreboot project was born (but not called that).
|
||||
Joshua made sure that everyone knew what I was doing!
|
||||
|
||||
A few months later, the name *Libreboot* was coined, and the domain name
|
||||
*libreboot.org* was registered. At that point, the Libreboot project (in early
|
||||
2014) was officially born. Once again, Joshua provided every bit of help he
|
||||
could, heavily promoting the project and he even wrote this article on the FSF
|
||||
website, announcing it:
|
||||
|
||||
<https://web.archive.org/web/20171222063358/https://www.fsf.org/blogs/licensing/replace-your-proprietary-bios-with-libreboot>
|
||||
He made sure everyone knew what I was doing, and he taught me a *lot* about
|
||||
licensing; many of Libreboot's practises today are still based on his lessons,
|
||||
such as the pitfalls of GPL compliance and how to really audit everything.
|
||||
|
||||
Klemens Nanni
|
||||
-------------
|
||||
|
|
@ -233,55 +213,17 @@ libreboot, and several tweaks to the build system.
|
|||
Lisa Marie Maginnis
|
||||
-------------------
|
||||
|
||||
Lisa is a former sysadmin at the Free Software Foundation. In the early days of
|
||||
the project, she provided Leah with a lot of technical advice. She initially
|
||||
created Libreboot IRC channel, when Leah did not know how to
|
||||
use IRC, and also handed +F founder status to Leah for the channel. As an FSF
|
||||
sysadmin, it was Lisa's job to maintain a lot of the infrastructure used by
|
||||
Libreboot; at the time, mailing lists on the Savannah website were used by
|
||||
the Libreboot project. When Paul Kocialkowski was a member of the project in
|
||||
2016, she helped him get help from the FSF; he was the leader of the Replicant
|
||||
project at the time, which had funding from the FSF, and the FSF authorized him
|
||||
to use some of that funding for his work on Libreboot, thanks to Lisa's
|
||||
encouragement while she worked at the FSF.
|
||||
Lisa was one of Libreboot's early contributors to Libreboot. She personally
|
||||
helped me set up a lot of the early infrastructure, including things like IRC,
|
||||
mailing list and so on. She provided a lot of technical guidance, while working
|
||||
in a sysadmin job for a certain free software organisation; she was both a
|
||||
mentor and a friend.
|
||||
|
||||
Lisa also stepped in when Leah Rowe missed her LibrePlanet 2016 talk. Leah was
|
||||
scheduled to do a talk about Libreboot, but didn't show up in time. Lisa, along
|
||||
with Patrick McDermott (former Libreboot developer, who was present at that
|
||||
conference) did the talk in Leah's place. The talk was never recorded, but the
|
||||
Free Software Foundation has these photos of that talk on their LibrePlanet
|
||||
website (the woman with the blue hair is Lisa, and the long-haired dude with the
|
||||
moustache is Patrick):
|
||||
|
||||
<http://web.archive.org/web/20170319043913/https://media.libreplanet.org/u/libreplanet/m/session-02-c-mws-png-libreplanet-2016-sessions/>
|
||||
|
||||
<http://web.archive.org/web/20170319043915/https://media.libreplanet.org/u/libreplanet/m/session-02-c-wide-png-libreplanet-2016-sessions/>
|
||||
|
||||
Fun fact: Patrick is also the lead developer of ProteanOS, an FSF-endorsed
|
||||
embedded OS project: <http://proteanos.com/> (uses BusyBox and Linux-libre)
|
||||
|
||||
Leah Rowe ran *2* LibrePlanet workshops; one in 2015 and another in 2016, while
|
||||
visiting Boston, MA, USA on both occasions to attend these conferences. These
|
||||
workshops were for Libreboot installations. People came to both workshops, to
|
||||
have Libreboot installed onto their computers. As FSF sysadmin, at that time,
|
||||
Lisa provided all of the infrastructure and equipment used at those workshops.
|
||||
Without her help, those workshops would have not been possible.
|
||||
|
||||
When the ASUS KGPE-D16 mainboard (high-end server board) was ported to Libreboot,
|
||||
Leah, working with Timothy Pearson (the one who ported it), shared patches back
|
||||
and forth with Lisa around mid 2016, mostly raminit patches, to get the board
|
||||
running at the FSF offices. This work ultimately lead to a most wonderful
|
||||
achievement:
|
||||
|
||||
The FSF and GNU websites now run on
|
||||
Librebooted ASUS KGPE-D16 based servers, on a fully free GNU+Linux distro. This
|
||||
means that the FSF now has full software freedom for their hosting infrastructure.
|
||||
|
||||
The FSF also provides access to this infrastructure for many other projects
|
||||
(besides GNU projects).
|
||||
|
||||
Lisa was a strong supporter of Libreboot in the very early days of the project,
|
||||
and her contributions were invaluable. I, Leah Rowe, owe her a debt of gratitude.
|
||||
She got me in touch with a lot of people, and at one point was instrumental in
|
||||
helping Paul Kocialkowski secure funding to work on the Veyron Speedy boards
|
||||
in Libreboot, e.g. ASUS Chromebook C201PA - at the time, this was using
|
||||
Google's own Depthcharge payload, which you can find in 2016 Libreboot
|
||||
releases.
|
||||
|
||||
Lorenzo Aloe
|
||||
------------
|
||||
|
|
@ -316,10 +258,6 @@ relating to the [Intel Management Engine](../faq.md#intelme), in addition
|
|||
to making several improvements to the build system in libreboot. **Former
|
||||
libreboot project maintainer.**
|
||||
|
||||
In 2016, Leah Rowe ran a Libreboot installation workshop at the FSF's
|
||||
LibrePlanet conference. Working alongside Leah, Patrick helped run the workshop
|
||||
and assisted with installing Libreboot onto people's machines.
|
||||
|
||||
Paul Kocialkowski
|
||||
-----------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,467 +0,0 @@
|
|||
---
|
||||
title: Учасники проекту
|
||||
x-toc-enable: true
|
||||
...
|
||||
|
||||
У цьому списку не обов'язково вказується, хто зараз працює над проектом,
|
||||
але в ньому вказано людей, які зробили значний внесок у проект.
|
||||
|
||||
Якщо ми забули вас тут згадати, повідомте нам, і ми вас додамо. (або якщо
|
||||
ви не хочете, щоб вас згадували, повідомте нас, і ми видалимо ваш
|
||||
запис)
|
||||
|
||||
Інформацію про те, хто працює над libreboot і як працює проект, можна
|
||||
знайти на цій сторінці: [who.md](who.md)
|
||||
|
||||
Ви можете дізнатися історію проекту libreboot, просто прочитавши цю сторінку.
|
||||
Тут докладно розповідається про всі основні внески в проект і
|
||||
загалом про те, як створювався проект (і хто допоміг його створити).
|
||||
|
||||
Лія Роу
|
||||
---------
|
||||
|
||||
**Засновник проекту Libreboot, а зараз провідний розробник** Лія
|
||||
працює над усіма аспектами libreboot, такими як:
|
||||
|
||||
* Загальне керівництво. Лія обробляє всі зовнішні внески до libreboot,
|
||||
переглядає пул реквести, має справу із звітами про помилки, делегує завдання, коли це необхідно
|
||||
або бажано. Лія контролює серверну інфраструктуру libreboot.org, розміщену
|
||||
в її лабораторії.
|
||||
* Лія має останнє слово щодо всіх рішень, беручи внесок через обговорення з
|
||||
представниками громадськості, переважно на IRC. Лія контролює випуски libreboot
|
||||
і загалом підтримує проект. Без Лії не було би Libreboot!
|
||||
* Система збірки (lbmk, скорочення від libreboot Make). Це автоматизована
|
||||
система збирання, яка лежить в серці libreboot; він завантажує, патчить, налаштовує
|
||||
та компілює відповідні компоненти, такі як coreboot, GRUB, і генерує образи ROM
|
||||
libreboot, які ви можете знайти в архівах випусків.
|
||||
* Апстрім робота над coreboot, коли необхідно (та іншими проектами, які libreboot
|
||||
використовує). Це також означає роботу з людьми поза межами проекту libreboot,
|
||||
щоб об'єднати виправлення (між іншим) в апстрім проектах,
|
||||
які libreboot використовує
|
||||
* Надання підтримки користувачів на IRC
|
||||
|
||||
Калеб Ла Гранж
|
||||
---------------
|
||||
|
||||
**Вторинний розробник, номер два для Лії.** Калеб - розробник libreboot на повний робочий день
|
||||
з вузьким фокусом. Калеб зосереджується на кількох напрямках розвитку:
|
||||
|
||||
* Система побудови. Калеб відповідає за вдосконалення та виправлення системи побудови libreboot Make.
|
||||
Зокрема, управління бінарними блобами, автоматизація та відтворюваність.
|
||||
* Апаратна модифікація. Калеб має пристрасть до переробки апаратного забезпечення; паяння,
|
||||
розпаювання, та тестування libreboot на отриманому обладнанні.
|
||||
* Перенесення плати. Все, що підтримується в Coreboot, можна перенести на libreboot, Калеб
|
||||
перевірить і перенесе будь-яку плату, до якої зможе потрапити. Крім того, будь-хто може
|
||||
зв'язатись з Калебом, щоб створити образи libreboot для тестування на своїй платі.
|
||||
* Документація. Калеб активно веде документацію щодо зазначених вище сфер
|
||||
інтересу. Додатково, Калеб відповідає за посібники з розбирання з власними
|
||||
малюнками та діаграмами для кількох плат.
|
||||
* Підтримка користувачів. Калеб активний в irc і готовий допомогти будь-якому користувачеві, який зацікавлений в
|
||||
використанні libreboot або потребує допомоги.
|
||||
* Цілі проекту. Калеб співпрацює з Лією над визначенням цілей проекту.
|
||||
Лія має останнє слово в кожному рішенні.
|
||||
|
||||
Зовнішні проекти
|
||||
================
|
||||
|
||||
Проект Coreboot
|
||||
----------------
|
||||
|
||||
Без coreboot проект libreboot був би просто неможливий.
|
||||
|
||||
Людей і компаній, які працюють над coreboot, багато, і вони роблять
|
||||
проект libreboot таким, яким він є. Проект libreboot активно використовує coreboot
|
||||
для ініціалізації обладнання.
|
||||
|
||||
GRUB
|
||||
--------
|
||||
|
||||
GRUB - це завантажувач, який використовується libreboot. Само собою зрозуміло, що
|
||||
розробники GRUB стимулюють libreboot своєю роботою.
|
||||
|
||||
SeaBIOS
|
||||
-------
|
||||
|
||||
Прошивка libreboot надає SeaBIOS як опцію корисного навантаження. SeaBIOS забезпечує
|
||||
застарілу реалізацію BIOS x86.
|
||||
|
||||
U-Boot
|
||||
------
|
||||
|
||||
Libreboot використовує U-Boot як корисне навантаження coreboot на ноутбуках
|
||||
ARM Chromebook з підтримкою coreboot.
|
||||
|
||||
Внески в алфавітному порядку
|
||||
============================
|
||||
|
||||
Алісса Розенцвейг
|
||||
-----------------
|
||||
|
||||
Переключила веб-сайт на використання розмітки замість рукописного HTML та користувацького
|
||||
PHP. **Колишній супроводжувач проекту libreboot (системний адміністратор libreboot.org).**
|
||||
|
||||
Алісса написала оригінальний генератор статичних сайтів (скрипти `sh`, що перетворюють
|
||||
markdown в html, через pandoc) для libreboot.org. Цей генератор статичних сайтів
|
||||
був значно змінений і відгалужений Лією Роу у формальний проект:
|
||||
|
||||
<https://untitled.vimuser.org/> (untitled - це робота Лії, а не Алісси, але вона базується на
|
||||
оригінальній роботі Аліси над генератором статичних сайтів, який раніше використовував Libreboot;
|
||||
веб-сайт Libreboot тепер створено за допомогою Untitled)
|
||||
|
||||
Альпер Небі Ясак
|
||||
----------------
|
||||
|
||||
Надав інтеграцію системи збірки та документацію для використання
|
||||
U-Boot в якості корисного навантаження, та початкові порти Libreboot деяких ARM Chromebook
|
||||
виходячи з того.
|
||||
|
||||
Альпер також займається розробкою на U-Boot, напр. продовжив майже завершений
|
||||
порт плати `gru-kevin` і об'єднав його з апстрімом.
|
||||
|
||||
Артур Хейманс
|
||||
--------------
|
||||
|
||||
Об'єднав патч із coreboot у libreboot, дозволяючи режимам живлення C3 та C4
|
||||
правильно працювати на ноутбуках GM45. Це була давня проблема до внеску
|
||||
Артура. Артур також виправив розмір відеопам'яті на i945 на системах
|
||||
GM45, що дозволило максимально розподілити VRAM для вбудованих графічних процесорів
|
||||
у цих системах, ще одна давня проблема в libreboot.
|
||||
|
||||
Артур також працював над системою збірки Libreboot, коли він був учасником
|
||||
проекту. Він досі працює над coreboot, і Libreboot отримує велику
|
||||
користь від його роботи. Його внесок у проект coreboot і Libreboot
|
||||
неоціненний.
|
||||
|
||||
Володимир Сербіненко
|
||||
-------------------
|
||||
|
||||
Перенес багато thinkpad, які підтримуються в libreboot, на coreboot, а
|
||||
також зробив багато виправлень у coreboot, які принесли користь проекту libreboot.
|
||||
|
||||
Володимир написав багато вихідного коду ініціалізації відео, який використовується різними
|
||||
платформами Intel у Libreboot, під час прошивки (зараз переписаний
|
||||
іншими в Ada, для libgfxinit в coreboot, але спочатку він був написаний на
|
||||
C і включений безпосередньо в coreboot; libgfxinit є субмодуль третьої сторони).
|
||||
|
||||
Демієн Замміт
|
||||
-------------
|
||||
|
||||
Підтримує порт coreboot Gigabyte GA-G41M-ES2L, інтегрований у
|
||||
libreboot. Також працює над іншим апаратним забезпеченням на користь
|
||||
проекту libreboot.
|
||||
|
||||
Демієн не працював безпосередньо над самим Libreboot, але він багато працював з
|
||||
Лією Роу, інтегруючи патчі та нові порти плати в Libreboot на основі
|
||||
попередньої роботи Демієна над coreboot.
|
||||
|
||||
Денис Каріклі
|
||||
-------------
|
||||
|
||||
На основі роботи, виконаної Пітером Стюджем, Володимиром Сербіненко та іншими
|
||||
в проекті coreboot, вдалось налагодити нативну ініціалізацію графіки для роботи
|
||||
на ThinkPad X60, що дозволяє підтримувати її в libreboot. Денис дав
|
||||
багато порад і допоміг створити проект libreboot.
|
||||
|
||||
Денис був наставником Лії Роу в ранні дні, коли вона заснувала проект
|
||||
Libreboot. Багато прийнятих рішень, особливо щодо системи збірки
|
||||
Libreboot (lbmk), були натхненні розмовами з Денисом.
|
||||
|
||||
Денис навчив Лію про регістри, які використовуються графічним процесором Intel для керування підсвічуванням.
|
||||
В ранні дні, ноутбуки ThinkPad X60 та T60 в Libreboot не мали працюючого
|
||||
контроля підсвічуванням, тому яскравість завжди була 100%. За допомогою Дениса,
|
||||
Лія змогла налаштувати керування підсвічуванням шляхом зворотньої розробки
|
||||
правильних значень для запису в ці регістри. На основі цього в coreboot
|
||||
було написано просте виправлення; однак виправлення перезаписувало безпосередньо регістр
|
||||
і не працювало з елементами керування яскравістю на основі ACPI. Інші в coreboot
|
||||
пізніше вдосконалили його, змусивши елементи керування підсвічуванням на основі ACPI працювати належним чином, на основі цієї
|
||||
попередньої роботи.
|
||||
|
||||
Джерун Квінт
|
||||
------------
|
||||
|
||||
Додав кілька виправлень до документації libreboot, пов'язаної зі
|
||||
встановленням Arch з повним дисковим шифруванням у системах libreboot.
|
||||
|
||||
Джошуа Гей
|
||||
----------
|
||||
|
||||
Джошуа колишній співробітник FSF.
|
||||
|
||||
Джошуа допоміг із раннім заснуванням проекту Libreboot, будучи
|
||||
(на той час) менеджером з ліцензування та відповідності FSF. Його роботою було
|
||||
переглядати продукти, надіслані до FSF для перевірки; FSF має програму
|
||||
сертифікації, під назвою *Поважає Вашу Свободу* (Respects Your Freedom), за якою FSF рекламуватиме
|
||||
продукти вашої компанії, якщо вони постачаються з усім вільним програмним
|
||||
забезпеченням.
|
||||
|
||||
Я, Лія Роу, спочатку просто продавала ноутбуки ThinkPad X60 із звичайним
|
||||
coreboot, і це включало оновлення мікрокоду ЦП. У той час
|
||||
я не дуже про це думала. Джошуа зв'язався зі мною, в своїх повноваженнях FSF, і спитав,
|
||||
чи зацікавить мене програма RYF FSF; Я була дуже здивована, що FSF
|
||||
сприйме мене серйозно, і я сказала так. Саме з цього почалася рання робота
|
||||
над Libreboot. Джошуа показав мені всі проблеми з моїми продуктами, і з
|
||||
цього, рішення було очевидним:
|
||||
|
||||
Необхідно, щоб існував проект із повністю вільною версією coreboot без будь-яких
|
||||
бінарних блобів. У той час (і це актуально й сьогодні) coreboot не був
|
||||
повністю вільним програмним забезпеченням і за замовчуванням постачався з двійковими блобами. Зокрема,
|
||||
оновлення мікрокоду ЦП включено за замовчуванням на всіх машинах x86. Працюючи
|
||||
з Джошуа, я створила повністю вільну версію coreboot.
|
||||
Спочатку він не називався Libreboot, і робота була призначена виключно для моєї
|
||||
компанії (на той час вона називалася Gluglug), яку просувала FSF.
|
||||
|
||||
Джошуа використовував свої медійні зв'язки в FSF, щоб активно рекламувати мою роботу, і
|
||||
13 грудня 2013 року народився проект Libreboot (але не названий так).
|
||||
Джошуа переконався, щоб всі знали, що я роблю!
|
||||
|
||||
Через кілька місяців було створено назву *Libreboot* і зареєстровано доменне ім'я
|
||||
*libreboot.org*. У цей момент офіційно народився проект Libreboot (на початку
|
||||
2014 року). Знову Джошуа надав всю можливу допомогу,
|
||||
активно просуваючи проект, і навіть написав цю статтю на веб-сайті FSF
|
||||
оголосивши про це:
|
||||
|
||||
<https://web.archive.org/web/20171222063358/https://www.fsf.org/blogs/licensing/replace-your-proprietary-bios-with-libreboot>
|
||||
|
||||
Ендрю Роббінс
|
||||
--------------
|
||||
|
||||
Працював над великими частинами старої системи збірки Libreboot і пов'язаною документацією.
|
||||
Ендрю приєднався до проекту Libreboot як штатний розробник у червні 2017,
|
||||
до моменту свого відходу в березні 2021 року.
|
||||
|
||||
Я, Лія Роу, дуже вдячна Ендрю Роббінсу за його численні внески
|
||||
протягом багатьох років.
|
||||
|
||||
Клеменс Нанні
|
||||
-------------
|
||||
|
||||
Внесено багато виправлень і покращень у конфігурацію GRUB, яка використовується в
|
||||
libreboot, а також кілька змін у системі збірки.
|
||||
|
||||
Ліза Марі Магінніс
|
||||
-------------------
|
||||
|
||||
Ліза - колишній системний адміністратор Free Software Foundation. На перших днях
|
||||
проекту вона давала Лії багато технічних порад. Спочатку вона створила
|
||||
IRC-канал Libreboot, коли Лія не знала, як користуватися
|
||||
IRC, а також передала +F статус засновника для каналу. Як системний
|
||||
адміністратор FSF, роботою Лізи було підтримувати велику частину інфраструктури,
|
||||
яку використовує Libreboot; на той час списки розсилки на веб-сайті Savannah
|
||||
використовувалися проектом Libreboot. Коли Пол Коціалковскі був
|
||||
учасником проекту в 2016 році, вона допомогла йому отримати допомогу від FSF; на той час він був
|
||||
керівником проекту Replicant, який фінансував FSF, і FSF дозволив
|
||||
йому використати частину цього фінансування для його роботи над Libreboot, завдяки Лізи
|
||||
підтримці, коли вона працювала у FSF.
|
||||
|
||||
Ліза також втрутилася, коли Лія Роу пропустила виступ на LibrePlanet 2016. Лія мала
|
||||
виступити з доповіддю про Libreboot, але не з'явилася вчасно. Ліза разом
|
||||
із Патріком Макдермоттом (колишнім розробником Libreboot, який був присутній
|
||||
на тій конференції) виступили замість Лії. Розмова ніколи не була записана, але
|
||||
Фонд вільного програмного забезпечення має ці фотографії цієї розмови на веб-сайті LibrePlanet
|
||||
(жінка з блакитним волоссям - Ліза, а довговолосий хлопець із вусами -
|
||||
Патрік):
|
||||
|
||||
<http://web.archive.org/web/20170319043913/https://media.libreplanet.org/u/libreplanet/m/session-02-c-mws-png-libreplanet-2016-sessions/>
|
||||
|
||||
<http://web.archive.org/web/20170319043915/https://media.libreplanet.org/u/libreplanet/m/session-02-c-wide-png-libreplanet-2016-sessions/>
|
||||
|
||||
Цікавий факт: Патрік також є провідним розробником ProteanOS, проекту вбудованої
|
||||
ОС, схваленого FSF: <http://proteanos.com/> (використовує BusyBox і Linux-libre)
|
||||
|
||||
Лія Роу провела *2* семінари LibrePlanet; один у 2015 році та інший у 2016 році,
|
||||
відвідуючи Бостон, Массачусетс, США в обох випадках для участі в цих конференціях. Ці
|
||||
семінари стосувалися встановлення Libreboot. Люди приходили на обидва семінари, щоб
|
||||
встановити Libreboot на свої комп'ютери. Як системний адміністратор FSF, на той час,
|
||||
Ліза забезпечила всю інфраструктуру та обладнання, яке використовувалося на цих семінарах.
|
||||
Без її допомоги ці майстер-класи були б неможливими.
|
||||
|
||||
Коли материнська плата ASUS KGPE-D16 (серверна плата високого класу) була перенесена на Libreboot,
|
||||
Лія, працюючи з Тімоті Пірсоном (той, хто її переніс),
|
||||
приблизно в середині 2016 року поділилася з Лізою виправленнями, в основному виправленнями raminit, щоб отримати плату, яка працює в офісах FSF. Ця робота
|
||||
зрештою призвела до чудового досягнення:
|
||||
|
||||
Веб-сайти FSF і GNU тепер працюють на, з встановленим Libreboot,
|
||||
заснованих на ASUS KGPE-D16 серверах, на повністю вільному GNU+Linux дистрибутиві. Це
|
||||
означає, що FSF тепер має повну свободу програмного забезпечення для своєї
|
||||
інфраструктури хостингу.
|
||||
|
||||
FSF також надає доступ до цієї інфраструктури для багатьох інших проектів
|
||||
(крім проектів GNU).
|
||||
|
||||
Ліза була сильною прихильницею Libreboot на перших днях проекту,
|
||||
і її внесок був неоціненним. Я, Лія Роу, у боргу перед нею.
|
||||
|
||||
Lorenzo Aloe
|
||||
------------
|
||||
|
||||
Provided hardware testing for the [Dell OptiPlex 9020](docs/hardware/dell9020.md),
|
||||
also provided testing for proxmox with GPU passthrough on Dell Precision T1650,
|
||||
confirming near-native performance; with this, you can boot operating systems
|
||||
virtually natively, performance-wise, on a Libreboot system in cases where
|
||||
that OS is not natively supported.
|
||||
|
||||
All round good guy, an honest and loyal fan.
|
||||
|
||||
Маркус Мьоллер
|
||||
--------------
|
||||
|
||||
Зробив логотип libreboot.
|
||||
|
||||
Nicholas Chin
|
||||
-------------
|
||||
|
||||
[Ported Dell Latitude E6400 to Libreboot](news/e6400.md).
|
||||
|
||||
Патрік "П. Дж." Макдермотт
|
||||
---------------------------
|
||||
|
||||
Патрік також провів багато досліджень і написав розділ поширених запитань libreboot,
|
||||
пов'язаний із [Intel Management Engine](../faq.md#intelme), а також зробив кілька покращень у
|
||||
системі збірки libreboot. **Колишній супроводжувач проекту
|
||||
libreboot.**
|
||||
|
||||
У 2016 році Лія Роу провела семінар зі встановлення Libreboot на конференції FSF
|
||||
LibrePlanet. Працюючи разом з Лією, Патрік допомагав вести семінар
|
||||
та допомагав установлювати Libreboot на комп'ютери людей.
|
||||
|
||||
Пітер Стюдж
|
||||
-----------
|
||||
|
||||
Допоміг написати [розділ поширених запитань про DMA](../faq.md#hddssd-firmware), та надав
|
||||
загальні поради на перших днях проекту. У той час Пітер був розробником coreboot
|
||||
і головним розробником проекту *libusb* (який flashrom
|
||||
активно використовує).
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 27 January 2024.
|
||||
|
||||
Пітер також написав утиліту *bucts*, яка використовується для встановлення біта Top Swap
|
||||
(TS) для керування резервним копіюванням (BUC) на ноутбуках i945, таких як ThinkPad X60/T60, яка є корисною для
|
||||
обхідного шляху для прошивки Libreboot без використання зовнішнього обладнання; на цій машині,
|
||||
з Lenovo BIOS, можна перепрошити все, крім головного завантажувального
|
||||
блоку, але платформи Intel мають 2 завантажувальні блоки, і ви вказуєте, який із них
|
||||
використовувати, встановленням біта TS. Потім ви завантажуєтеся лише з одним прошитим завантажувальним блоком
|
||||
(завантажувальним блоком проекту coreboot на цій машині), а потім скидаєте
|
||||
bucts перед повторною прошивкою ROM, щоб прошити основний завантажувальний блок. Libreboot
|
||||
розміщує копію його роботи, оскільки його веб-сайт, на якому розміщено bucts,
|
||||
більше не відповідає.
|
||||
|
||||
Пол Коціалковський
|
||||
-----------------
|
||||
|
||||
Переніс ноутбуки Chromebook на основі ARM (Rockchip RK3288 SoC) до
|
||||
libreboot. Також один із головних розробників [Replicant](http://www.replicant.us/).
|
||||
|
||||
Пол Менцель
|
||||
-----------
|
||||
|
||||
Дослідив та виправив помилку в coreboot на ThinkPad X60/T60, яку виявляло
|
||||
ядро Linux 3.12 і новіших версій, через яку прискорення 3D не
|
||||
працювало, а відео загалом ставало нестабільним. Проблема полягала в тому, що
|
||||
coreboot під час ініціалізації відеочіпсета Intel, відображав *GTT Stolen Memory* в
|
||||
не тому місці, оскільки код базувався на коді ядра, а в ядрі Linux
|
||||
була така сама помилка. Коли Linux це виправив, він виявив ту саму помилку в coreboot.
|
||||
|
||||
Пол працював над цим із Libreboot,
|
||||
періодично надсилаючи патчі для тестування, доки помилку не було виправлено
|
||||
в coreboot, а потім допоміг ій інтегрувати виправлення в libreboot.
|
||||
|
||||
Riku Viitanen
|
||||
-------------
|
||||
|
||||
Added support for HP Elite 8200 SFF desktop PC to Libreboot. You can read
|
||||
about this in the hardware page:
|
||||
|
||||
[HP Elite 8200 SFF](docs/hardware/hp8200sff.md)
|
||||
|
||||
Стів Шентон
|
||||
-------------
|
||||
|
||||
Стів виконав першу роботу зі зворотньої розробки Intel Flash Descriptor, який використовується
|
||||
на машинах ICH9M, таких як ThinkPad X200. Він створив структуру C, що визначає (використовуючи
|
||||
бітові поля в C) цю область дескриптора. За допомогою деяких хитрих трюків він зміг
|
||||
виявити існування біта в дескрипторі для *вимкнення* Intel ME
|
||||
(management engine) на цих платформах.
|
||||
|
||||
Його початкове підтвердження концепції визначило лише дескриптор, і зробило би це:
|
||||
|
||||
* Читання дескриптора за замовчуванням і регіонів GbE з ROM Lenovo X200 (прошивка
|
||||
за замовчуванням, не coreboot)
|
||||
* Вимкнення ME, встановивши 2 біти в дескрипторі
|
||||
* Вимкнення регіона ME
|
||||
* Переміщення дескриптора+GbE (загалом 12КБ) поруч
|
||||
* Виділення решти флеш-пам'яті для регіону BIOS
|
||||
* На основі цього створено 12КБ регіон дескриптор+область GBE для вставки
|
||||
в образ ROM coreboot.
|
||||
|
||||
У перші дні, до того, як Libreboot підтримував платформи GM45+ICH9M, такі як
|
||||
ThinkPad X200/T400, ви могли використовувати ці машини, але щоб уникнути
|
||||
Intel ME, вам доводилося виконувати прошивку без області дескриптора. У ті часи це працювало нормально,
|
||||
тому що ME обробляв лише TPM та AMT на цих машинах, і система
|
||||
працювала нормально, але Intel Flash Descriptor також обробляє область Intel GbE NVM
|
||||
у флеш-пам'яті, яка використовується для інтерфейсу Intel Gigabit Ethernet.
|
||||
|
||||
Отже, ви або мали Intel ME, або не підтримували ethernet. Стів зрозумів, як
|
||||
вимкнути Intel ME за допомогою 2 бітів перемикання в дескрипторі, а також як видалити область
|
||||
Intel ME з флеш-пам'яті.
|
||||
|
||||
Ґрунтуючись на його дослідженні, я, Лія Роу, працюючи разом зі Стівом, також виконала зворотню розробку
|
||||
області Intel GbE NVM (енергонезалежна пам'ять) у
|
||||
завантажувальній флеш-пам'яті. Цей регіон визначає параметри конфігурації для вбудованої мережевої карти Intel
|
||||
GbE, якщо присутня.
|
||||
|
||||
На основі цього я змогла взяти початкове підтвердження концепції та написати
|
||||
утиліту `ich9gen`, яка генерує Intel Flash Descriptor та регіон GbE NVM,
|
||||
з нуля, без визначення регіону Intel ME. Саме цей інструмент,
|
||||
інструмент `ich9gen`, використовує Libreboot для надання образів ROM для GM45+ICH9M
|
||||
платформ (таких як ThinkPad X200/T400/T500/W500), із повнофункціональним
|
||||
дескриптором та функціональним Gigabit Ethernet, але *без* необхідності мікропрограми Intel
|
||||
Management Engine (ME), що робить ці машини *вільними* (ME
|
||||
повністю вимкнено, коли ви використовуєте образ дескриптора+gbe, створене `ich9gen`).
|
||||
|
||||
З *моїм* інструментом `ich9gen` (інструмент Стіва називався `ich9deblob`), вам більше
|
||||
не потрібен був дамп оригінальної мікропрограми Lenovo BIOS! Я не могла би написати цей інструмент
|
||||
без первинного підтвердження концепції Стіва. Я працювала з ним
|
||||
протягом багатьох місяців. Вся GM45+ICH9M підтримка (X200, T400 і так далі) в
|
||||
Libreboot стала можливою завдяки його роботі у 2014 році.
|
||||
|
||||
Тімоті Пірсон
|
||||
---------------
|
||||
|
||||
Перенес плату ASUS KGPE-D16 до coreboot для компанії Raptor
|
||||
Engineering, генеральним директором якої є Тімоті.
|
||||
Тімоті підтримує цей код у coreboot, допомогаючи проекту,
|
||||
з його інтеграцією з libreboot. Контактні
|
||||
дані цієї людини є на сайті raptor.
|
||||
|
||||
**Підтримку D16 було припинено 19 листопада 2022 року. Ви все ще можете використовувати
|
||||
старіші версії Libreboot, і старіші випуски.**
|
||||
|
||||
Swift Geek
|
||||
----------
|
||||
|
||||
Додав патч для ich9gen для створення дескрипторів розміром 16MiB.
|
||||
|
||||
Після цього Swift Geek повільно почав долучатися, поки не став розробником на повний
|
||||
робочий день. Внески Swift Geek насправді ніколи не були у формі *коду*,
|
||||
але те, що йому не вистачало в коді, він компенсував чудовою підтримкою як для користувачів,
|
||||
так і для інших розробників, допомагаючи іншим дізнатися більше про технології на
|
||||
низькому рівні.
|
||||
|
||||
Коли Swift Geek був учасником проекту, його роль здебільшого полягала в
|
||||
наданні підтримки користувачам (на каналі IRC) і проведенні досліджень. Swift Geek знає
|
||||
багато про апаратне забезпечення. Swift Geek також зробив деяку апстрім розробку GRUB.
|
||||
|
||||
Swift Geek неодноразово надавав технічні поради Лії Роу
|
||||
та допоміг їй покращити її навички паяння, а також навчив її
|
||||
деяким навичкам ремонту, до того моменту, коли вона тепер може виправляти більшість несправностей
|
||||
на материнських платах ThinkPad (під час перегляду схем та бордв'ю).
|
||||
|
||||
Swiftgeek залишив проект у березні 2021 року. Я, Лія Роу, бажаю його всього найкращого в його
|
||||
починаннях і дуже вдячна за його численні внески протягом багатьох
|
||||
років.
|
||||
|
||||
vitali64
|
||||
--------
|
||||
|
||||
Додав підтримку cstate 3 на macbook21, що забезпечує тривалий термін служби батареї
|
||||
та нижчу температуру процесора під час простою. vitali64 на irc
|
||||
|
|
@ -8,7 +8,7 @@
|
|||
* [Ліцензія](/license.md)
|
||||
* [Шаблон](/template-license.uk.md)
|
||||
* [Логотип](/logo-license.uk.md)
|
||||
* [Автори](/contrib.uk.md)
|
||||
* [Автори](/contrib.md)
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
|
|
|
|||
1280
site/news/10.md
1280
site/news/10.md
File diff suppressed because it is too large
Load Diff
|
|
@ -6,7 +6,6 @@ libreboot20240126.md
|
|||
x201.md
|
||||
hp820g2.md
|
||||
audit4.md
|
||||
10.md
|
||||
libreboot20231106.md
|
||||
libreboot20231101.md
|
||||
libreboot20231021.md
|
||||
|
|
|
|||
|
|
@ -156,7 +156,7 @@ are also repeated below but in more detail:
|
|||
* Don't use the `-B` option in make commands.
|
||||
* Where no-microcode ROM images are provided, ensure that the ROM hashes still
|
||||
match when running the vendor inject script. This is only useful on the
|
||||
Dell Latitude E6400, which is otherwise FSDG-compatible but (in Libreboot)
|
||||
Dell Latitude E6400, which is otherwise blob-free but (in Libreboot)
|
||||
comes with or without microcode updates, and with or without the Nvidia VGA
|
||||
ROM (handled by vendor inject/download scripts) for dGPU variants. Verification
|
||||
previously failed, under certain conditions, when inserting that VGA ROM.
|
||||
|
|
@ -198,8 +198,8 @@ are also repeated below but in more detail:
|
|||
spaces in them.
|
||||
* Don't support removal of microcode (during release time) on untested targets.
|
||||
Set `microcode_required="y"` on most boards, but leave it set to `"n"` on
|
||||
platfroms such as GM45 (ThinkPad X200/T400, Dell E6400, etc); anything FSDG
|
||||
compatible, in other words.
|
||||
platfroms such as GM45 (ThinkPad X200/T400, Dell E6400, etc); anything that
|
||||
can run without blobs, in other words.
|
||||
* Improved Dell Latitude E6400 support; the same image now provides iGPU and
|
||||
dGPU support, since it's SeaBIOS-only anyway, so a VGA ROM is inserted into
|
||||
the same ROM that also enables libgfxinit, enabling the Intel or Nvidia GPU
|
||||
|
|
|
|||
|
|
@ -303,7 +303,7 @@ logs, combined:
|
|||
* Don't use the `-B` option in make commands.
|
||||
* Where no-microcode ROM images are provided, ensure that the ROM hashes still
|
||||
match when running the vendor inject script. This is only useful on the
|
||||
Dell Latitude E6400, which is otherwise FSDG-compatible but (in Libreboot)
|
||||
Dell Latitude E6400, which is otherwise blob-free but (in Libreboot)
|
||||
comes with or without microcode updates, and with or without the Nvidia VGA
|
||||
ROM (handled by vendor inject/download scripts) for dGPU variants. Verification
|
||||
previously failed, under certain conditions, when inserting that VGA ROM.
|
||||
|
|
@ -345,8 +345,8 @@ logs, combined:
|
|||
spaces in them.
|
||||
* Don't support removal of microcode (during release time) on untested targets.
|
||||
Set `microcode_required="y"` on most boards, but leave it set to `"n"` on
|
||||
platfroms such as GM45 (ThinkPad X200/T400, Dell E6400, etc); anything FSDG
|
||||
compatible, in other words.
|
||||
platfroms such as GM45 (ThinkPad X200/T400, Dell E6400, etc); anything that
|
||||
can be blob-free, in other words.
|
||||
* Improved Dell Latitude E6400 support; the same image now provides iGPU and
|
||||
dGPU support, since it's SeaBIOS-only anyway, so a VGA ROM is inserted into
|
||||
the same ROM that also enables libgfxinit, enabling the Intel or Nvidia GPU
|
||||
|
|
|
|||
|
|
@ -176,365 +176,3 @@ exist, for example, the work done by Sam Zeloof and the Libre Silicon project:
|
|||
* <https://libresilicon.com/>
|
||||
|
||||
(Sam literally makes CPUs in his garage)
|
||||
|
||||
Problems with RYF criteria
|
||||
==========================
|
||||
|
||||
Libreboot previously complied with FSF RYF criteria, but it now adheres to a
|
||||
much more pragmatic policy aimed at providing more freedom to more people, in a
|
||||
more pragmatic way. You can read those guidelines by following this URL:
|
||||
|
||||
* FSF Respects Your Freedom (RYF) guidelines:
|
||||
<https://web.archive.org/web/20220604203538/https://ryf.fsf.org/about/criteria/>
|
||||
|
||||
Put simply, the RYF guidelines pertain to commercial products, with the
|
||||
stipulation that they must not contain proprietary software, or known privacy
|
||||
issues like backdoors.
|
||||
|
||||
The total exclusion of all proprietary software is currently not feasible. For
|
||||
example, proprietary SDR firmware in WiFi chipsets, firmware in AHCI devices
|
||||
like HDDs or SSDs, and the like. The FSF RYF guidelines state the following
|
||||
exception, to mitigate this fact:
|
||||
|
||||
* "However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software."
|
||||
|
||||
*This should be
|
||||
rejected on ideological grounds*. The rest of libreboot's policy and overall
|
||||
ideology expressed, in this article, will be based largely on that rejection.
|
||||
The definition of *product software* is completely arbitrary; software is
|
||||
software, and software should always be *libre*. Instead of making such
|
||||
exceptions, more hardware should be encouraged, with help given to provide as
|
||||
much freedom as possible, while providing education to users about any pitfalls
|
||||
they may encounter, and encourage freedom at all levels. When an organisation
|
||||
like the FSF makes such bold exceptions as above, it sends the wrong message,
|
||||
by telling people essentially to sweep these other problems under the rug, just
|
||||
because they involve software that happens to run on a "secondary processor".
|
||||
If the software is possible to update by the user, then it should be libre,
|
||||
regardless of whether the manufacturer *intended* for it to be upgraded or not.
|
||||
Where it really *isn't* possible to update such software, proprietary or not,
|
||||
advice should be given to that effect. Education is important, and the FSF's
|
||||
criteria actively discourages such education; it creates a false hope that
|
||||
everything is great and wonderful, just because the software on one arbitrary
|
||||
level is all perfect.
|
||||
|
||||
This view of the FSF's, as expressed in the quoted paragraph, assumes that
|
||||
there is primarily *one* main processor controlling your system. On many
|
||||
modern computers, this is *no longer true*.
|
||||
|
||||
Libre *software* does not exist in a vacuum, but we had less freedom in the
|
||||
past, especially when it came to hardware, so *software* was our primary focus.
|
||||
|
||||
The ability to study, adapt, share and use/re-use software freely is important,
|
||||
but there is a lot of nuance when it comes to *boot firmware*, nuance which is
|
||||
largely non-existent outside of firmware development, or kernel development.
|
||||
Most typical application/system software is high level and portable, but boot
|
||||
firmware has to be written for each specific machine, and due to the way
|
||||
hardware works, there are many trade-offs made, including by the FSF when
|
||||
defining what standards should apply *in practise*.
|
||||
|
||||
The fact that almost nobody talks about the EC firmware is *because* of the
|
||||
Respects Your Freedom certification. In reality, the EC firmware is crucial
|
||||
to user freedom, and ought to be free, but it is completely disregarded by
|
||||
the FSF as *part of the hardware*. This is wrong, and the FSF should actively
|
||||
encourage people to free it, on every laptop!
|
||||
|
||||
Other firmware currently outside the reach of the libreboot project are covered
|
||||
in the libreboot FAQ page. For example, HDD/SSD firmware is covered in the FAQ.
|
||||
Again, completely disregarded and shrugged off by the FSF.
|
||||
|
||||
The libreboot project will not hide or overlook these issues, because they are
|
||||
indeed critical, but again, currently outside the scope of what the Libreboot
|
||||
build system does. At the moment, the Libreboot build system concerns itself
|
||||
just with coreboot (and payloads), but this ought to change in the future.
|
||||
|
||||
Examples of FSF *sweeping blobs under the rug*
|
||||
----------------------------------------------
|
||||
|
||||
Over the years, there have been numerous cases where the FSF actively fails to
|
||||
provide incentive for levels of software freedom, such as:
|
||||
|
||||
* TALOS II "OpenPOWER" workstation from Raptor Engineering USA. It contains a
|
||||
broadcom NIC inside it which requires firmware, and that firmware was non-free.
|
||||
The FSF were willing to ignore it, and certify the TALOS II product under RYF,
|
||||
but Timothy Pearson of Raptor Engineering had it freed anyway, without being
|
||||
told to. Hugo Landau reverse engineered the specification and Evan Lojewski
|
||||
wrote libre firmware. See:
|
||||
See: <https://www.devever.net/~hl/ortega> and <https://github.com/meklort/bcm5719-fw>
|
||||
* FSF once endorsed the ThinkPad X200, as sold by [Minifree Ltd](https://minifree.org),
|
||||
which contains the Intel ME; the bootrom is still there, as is the ME
|
||||
coprocessor, but the ME is put into a disabled state via the Intel Flash
|
||||
Descriptor, and the ME firmware in flash is removed. However, the ME is an
|
||||
entire coprocessor which, with libre firmware, could be used for a great many
|
||||
things. In the Libreboot and coreboot projects, there has always been interest
|
||||
in this but the FSF disregards it entirely. The X200 product they certified
|
||||
came with Libreboot pre-installed.
|
||||
* Libreboot has a utility written by I, Leah Rowe, that generates ICH9M flash
|
||||
descriptors and GbE NVM images from scratch. This is necessary to configure
|
||||
the machine, but these are binary blobs otherwise; the FSF would have been
|
||||
quite content to certify the hardware anyway since these were non-software
|
||||
blobs in a format fully documented by Intel (they are just binary configuration
|
||||
files), but I went ahead and wrote ich9gen anyway. With ich9gen, you can
|
||||
more easily modify the descriptor/gbe regions for your firmware image. See:
|
||||
<https://libreboot.org/docs/install/ich9utils.html> - libreboot also has this
|
||||
* FSF once endorsed the ThinkPad T400 with Libreboot, as sold by Minifree. This
|
||||
machine comes in two versions: with ATI+Intel GPU, or only Intel GPU. If ATI
|
||||
GPU, it's possible to configure the machine so that either GPU is used. If the
|
||||
ATI GPU is to be used, a binary blob is needed for initialization, though the
|
||||
driver for it is entirely libre. *The FSF* ignored this fact and endorsed the
|
||||
hardware, so long as Libreboot does not enable the ATI GPU or tell people how
|
||||
to enable it. The *Intel* GPU on that machine has libre initialization code by
|
||||
the coreboot project, and a fully libre driver in both Linux and BSD kernels.
|
||||
In the configuration provided by Libreboot, the ATI GPU is completely disabled
|
||||
and powered down.
|
||||
* All Libreboot-compatible ThinkPads contain proprietary Embedded Controller
|
||||
firmware, which is user-flashable (*and intended for update by the
|
||||
manufacturer*). The FSF chose to ignore the EC firmware, under
|
||||
their *secondary processor* exemption. See:
|
||||
<http://libreboot.org/faq.html#ec-embedded-controller-firmware>
|
||||
|
||||
In all of the above cases, the FSF could have been stricter, and bolder, by
|
||||
insisting that these *additional* problems for freedom were solved. They did
|
||||
not. There are many other examples of this, but the purpose of this article is
|
||||
not to list all of them (otherwise, a book could be written on the subject).
|
||||
|
||||
Problems with FSDG
|
||||
------------------
|
||||
|
||||
<img tabindex=1 src="https://av.libreboot.org/firmware.png" /><span class="f"><img src="https://av.libreboot.org/firmware.png" /></span>
|
||||
|
||||
The FSF maintains another set of criteria, dubbed Free System Distribution
|
||||
Guidelines (GNU FSDG)]
|
||||
|
||||
The FSDG criteria is separate from RYF, but has similar problems. FSDG is
|
||||
what the FSF-endorsed GNU+Linux distros comply with. Basically, it bans
|
||||
all proprietary software, including device firmware. This may seem noble, but
|
||||
it's extremely problematic in the context of firmware. Food for thought:
|
||||
|
||||
* Excluding vendor blobs in the linux kernel is *bad*. Proprietary firmware
|
||||
is *also bad*. Including them is a wiser choice, if strong education is also
|
||||
provided about *why they are bad* (less freedom). If you expose them to
|
||||
the user, and tell them about it, there is greater incentive (by simple
|
||||
reminder of their existence) to reverse engineer and replace them.
|
||||
* Firmware *in your OS kernel* is *good*. The FSF simultaneously gives the OK
|
||||
for hardware *with those same binary blobs* if the firmware is embedded
|
||||
into a ROM/flash chip on the device, or embedded in some processor. If the
|
||||
firmware is on separate ROM/flash, it could still be replaced by the user via
|
||||
reverse engineering, but then you would probably have to do some soldering
|
||||
(replace the chip on the card/device). *If the firmware is loaded by the
|
||||
OS kernel, then the firmware is exposed to the user and it can be more
|
||||
easily replaced. FSF criteria in this regard encourages hardware designers
|
||||
to hide the firmware instead, making actual (software) freedom less likely!*
|
||||
|
||||
Besides this, FSDG seems OK. Any libre operating system should ideally not
|
||||
have proprietary *drivers* or *applications*.
|
||||
|
||||
Hardware manufacturers like to shove everything into firmware because their
|
||||
product is often poorly designed, so they later want to provide workarounds in
|
||||
firmware to fix issues. In many cases, a device will already have firmware on it
|
||||
but require an update supplied to it by your OS kernel.
|
||||
|
||||
The most common example of proprietary firmware in Linux is for wifi devices.
|
||||
This is an interesting use-case scenario, with source code, because it could be
|
||||
used for owner-controlled *software defined radio*.
|
||||
|
||||
The *Debian* way is ideal. The Debian GNU+Linux distribution is entirely libre
|
||||
by default, and they include extra firmware if needed, which they have in a
|
||||
separate repository containing it. If you only want firmware, it is
|
||||
trivial to get installer images with it included, or add that to your installed
|
||||
system. They tell you how to do it, which means that they are helping people
|
||||
to get *some* freedom *rather than none*. This is an inherently pragmatic
|
||||
way to do things, and it's now how Libreboot does it.
|
||||
|
||||
More context regarding Debian is available in this blog post:
|
||||
<https://blog.einval.com/2022/04/19#firmware-what-do-we-do> - in it, the
|
||||
author, a prominent Debian developer, makes excellent points about device
|
||||
firmware similar to the (Libreboot) article that you're reading now. It's
|
||||
worth a read! As of October 2022, Debian has voted to include device firmware
|
||||
by *default*, in following Debian releases. It used to be that Debian excluded
|
||||
such firmware, but allowed you to add it.
|
||||
|
||||
OpenBSD is very much the same, but they're clever about it: during the initial
|
||||
boot, after installation, it tells you exactly what firmware is needed and
|
||||
updates that for you. It's handled in a very transparent way, by
|
||||
their `fw_update` program which you can read about here:
|
||||
|
||||
<https://man.openbsd.org/fw_update>
|
||||
|
||||
*Banning* linux-firmware specifically is a threat to freedom in the long term,
|
||||
because new users of GNU+Linux might be discouraged from using the OS if their
|
||||
hardware doesn't work. You might say: just buy new hardware! This is often not
|
||||
possible for users, and the user might not have the skill to reverse engineer
|
||||
it either.
|
||||
|
||||
More detailed insight about microcode
|
||||
=====================================
|
||||
|
||||
[Releases after 20230423 will provide separate ROM images with microcode
|
||||
excluded, alongside the default ones that include microcode.](microcode.md)
|
||||
|
||||
To be clear: it is preferable that microcode be libre. The microcode on Intel
|
||||
and AMD systems *are* proprietary. Facts and feelings rarely coincide; the
|
||||
purpose of this section is to spread *facts*.
|
||||
|
||||
The libreboot build system now enables microcode updates *by default.*
|
||||
|
||||
Not including CPU microcode updates is an absolute disaster for system
|
||||
stability and security.
|
||||
|
||||
Making matters worse, that very same text quoted from the FSF RYF criteria in
|
||||
fact specifically mentions microcode. Quoted again for posterity:
|
||||
|
||||
*"However, there is one exception for secondary embedded processors. The
|
||||
exception applies to software delivered inside auxiliary and low-level
|
||||
processors and FPGAs, within which software installation is not intended after
|
||||
the user obtains the product. This can include, for instance, microcode inside
|
||||
a processor, firmware built into an I/O device, or the gate pattern of an FPGA.
|
||||
The software in such secondary processors does not count as product software."*
|
||||
|
||||
Here, it is discussing the microcode that is burned into *mask ROM* on the CPU
|
||||
itself. It is simultaneously not giving the OK for microcode *updates* supplied
|
||||
by either coreboot or the Linux kernel; according to the FSF, these are an
|
||||
attack on your freedom, but the older, buggier microcode burned into ROM is OK.
|
||||
|
||||
The CPU already has microcode burned into mask ROM. The microcode configures
|
||||
logic gates in the CPU, to implement an instruction set, via special *decoders*
|
||||
which are fixed-function; it is not possible, for example, to implement a RISCV
|
||||
ISA on an otherwise x86 processor. It is only possible for the microcode to
|
||||
implement x86, or *broken* x86, and the default microcode is almost always
|
||||
*broken x86* on Intel/AMD CPUs; it is inevitable, due to the complexity of
|
||||
these processors.
|
||||
|
||||
The FSF believes
|
||||
that these x86 microcode updates (on Intel/AMD) allow you to completely create
|
||||
a new CPU that is fundamentally different than x86. This is not true. It is also
|
||||
not true that *all* instructions in x86 ISA are implemented with microcode. In
|
||||
some cases, hardcoded circuitry is used! The microcode updates are more like
|
||||
tiny one liner patches here and there in a git repository, by way of analogy.
|
||||
To once again get in the head-space of the FSF: these updates cannot do the CPU
|
||||
equivalent of re-factoring an entire codebase. They are *hot fixes*, nothing
|
||||
more!
|
||||
|
||||
Not including these updates will result in an unstable/undefined state. Intel
|
||||
themselves define which bugs affect which CPUs, and they define workarounds, or
|
||||
provide fixes in microcode. Based on this, software such as the Linux kernel
|
||||
can work around those bugs/quirks. Also, upstream versions of the Linux kernel
|
||||
can update the microcode at boot time (however, it is recommend still to do it
|
||||
from coreboot, for more stable memory controller initialization or “raminit”).
|
||||
Similar can be said about AMD CPUs.
|
||||
|
||||
Here are some examples of where lack of microcode updates affected *Libreboot*,
|
||||
forcing Libreboot to work around changes made upstream in coreboot, changes
|
||||
that were *good* and made coreboot behave in a more standards-compliant manner
|
||||
as per Intel specifications. Libreboot had to *break* coreboot to retain
|
||||
certain other functionalities, on some GM45/ICH9M thinkpads:
|
||||
|
||||
<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>
|
||||
|
||||
These patches revert *bug fixes* in coreboot, fixes that happen to break other
|
||||
functionality but only when microcode updates are excluded. The most
|
||||
technically correct solution is to *not* apply the above patches, and instead
|
||||
supply microcode updates!
|
||||
|
||||
Pick your poison. Not adding the updates is *irresponsible*, and ultimately
|
||||
futile, because you still end up with proprietary microcode, but you just get
|
||||
an older, buggier version instead!
|
||||
|
||||
This shift in project policy does not affect your freedom at all, because you
|
||||
still otherwise have older, buggier microcode anyway. However, it does improve
|
||||
system reliability by including the updates!
|
||||
|
||||
Such pragmatic policy is *superior* to the *dogma* that Libreboot users once
|
||||
had to endure. Simply put, the Libreboot project aims to give users as much
|
||||
freedom as is possible for their hardware; this was always the case, but this
|
||||
mentality is now applied to [a lot] more hardware.
|
||||
|
||||
Other considerations
|
||||
====================
|
||||
|
||||
Also not covered strictly by Libreboot: OSHW and Right To Repair. Freedom at
|
||||
the silicon level would however be amazing, and efforts already exist; for
|
||||
example, look at the RISCV ISA (in practise, actual fabrication is still
|
||||
proprietary and not under your control, but RISCV is a completely libre CPU
|
||||
design that companies can use, instead of having to use proprietary ARM/x86 and
|
||||
so on). Similarly, Right To Repair (ability to repair your own device, which
|
||||
implies free access to schematics and diagrams) is critical, for the same
|
||||
reason that Libre Software (Right To Hack) is critical!
|
||||
|
||||
OSHW and Right To Repair are not covered at all by RYF (FSF's Respects Your
|
||||
Freedom criteria), the criteria which Libreboot previously complied with.
|
||||
RYF also makes several concessions that are ultimately damaging, such as
|
||||
the *software as circuitry* policy which is, frankly, nonsensical. ROM is still
|
||||
software. There was a time when the FSF didn't consider BIOS software a freedom
|
||||
issue, just because it was burned onto a mask ROM instead of *flashed*; those
|
||||
FSF policies ignore the fact that, with adequate soldering skills, it is trivial
|
||||
to replace stand-alone mask ROM ICs with compatible flash memory.
|
||||
|
||||
Conclusion
|
||||
==========
|
||||
|
||||
RYF isn't *wrong* per se, just flawed. It is correct in some ways and if
|
||||
complied with, the result *does* give many freedoms to the user, but RYF
|
||||
completely disregards many things that are now possible, including freedoms at
|
||||
the hardware level (the RYF criteria only covers *software*). Those guidelines
|
||||
are written with assumptions that were still true in the 1990s, but the world
|
||||
has since evolved. The libreboot project rejects those policies in their
|
||||
entirety, and instead takes a pragmatic approach.
|
||||
|
||||
The conclusion that should be drawn from all of this is as follows:
|
||||
|
||||
*Following* FSF criteria does not damage anything, but that criteria is very
|
||||
conservative. Its exemptions should be *disregarded* and entirely ignored.
|
||||
RYF is no longer fit for purpose, and should be rewritten to create
|
||||
a *more strict* set of guidelines, without all the loopholes or exemptions.
|
||||
As has always been the case, Libreboot tries to always go above and beyond, but
|
||||
the Libreboot project does not see RYF as a *gold standard*. There are levels
|
||||
of freedom possible now that the RYF guidelines do not cover at all, and in
|
||||
some cases even actively discourage/dis-incentivize because it makes compromises
|
||||
based on assumptions that are no longer true.
|
||||
|
||||
Sad truth: RYF actively encourages *less* freedom, by not being bold enough.
|
||||
It sets a victory flag and says *mission accomplished*, despite the fact
|
||||
that the work is *far* from complete!
|
||||
|
||||
If followed *with exemptions unchallenged*, RYF may in some cases encourage
|
||||
companies to *sweep under the rug* any freedom issues that exist, where it
|
||||
concerns proprietary firmware not running on the host CPU (such as the
|
||||
Embedded Controller firmware).
|
||||
|
||||
I propose that new guidelines be written, to replace RYF. These new guidelines
|
||||
will do away with all exemptions/loopholes, and demand that *all* software be
|
||||
libre on the machine, or as much as possible. Instead of only promoting products
|
||||
that meet some arbitrary standard, simply catalog all systems on a grand
|
||||
*database* of sorts (like h-node.org, but better), which will define exactly
|
||||
what *hardware* **and** software issues exist on each device. Include Right to
|
||||
Repair and OSHW (including things like RISCV) in the most "ideal"
|
||||
standard machine; the gold standard is libre *silicon*, like what Sam Zeloof
|
||||
and others are working on nowadays.
|
||||
|
||||
This new set of criteria should not attempt to hide or ignore *anything*. It
|
||||
should encourage people to push the envelope and innovate, so that we can have
|
||||
much *more* freedom than is currently possible. Necessity is the mother of all
|
||||
invention, and freedom is an important goal in every aspect of life, not just
|
||||
computing.
|
||||
|
||||
Don't call it "Respects Your Freedom" or something similar. Instead, call it
|
||||
something like: the freedom catalog. And actually focus on hardware, not just
|
||||
software!
|
||||
|
||||
Other resources
|
||||
===============
|
||||
|
||||
Ariadne Conill's RYF blog post
|
||||
------------------------------
|
||||
|
||||
Ariadne Conill, security team chair of *Alpine Linux*, posted a very robust
|
||||
article about RYF, with similar points made when compared to *this* article.
|
||||
However, Ariadne goes into detail on several other examples of problems with
|
||||
the FSF RYF criteria; for example, it talks about the *Novena* product by
|
||||
Bunnie.
|
||||
|
||||
It's worth a read! Link:
|
||||
|
||||
<https://ariadne.space/2022/01/22/the-fsfs-relationship-with-firmware-is-harmful-to-free-software-users/>
|
||||
|
|
|
|||
|
|
@ -168,375 +168,3 @@ exist, for example, the work done by Sam Zeloof and the Libre Silicon project:
|
|||
* <https://libresilicon.com/>
|
||||
|
||||
(Sam literally makes CPUs in his garage)
|
||||
|
||||
Problems with RYF criteria
|
||||
==========================
|
||||
|
||||
Libreboot previously complied with FSF RYF criteria, but it now adheres to a
|
||||
much more pragmatic policy aimed at providing more freedom to more people, in a
|
||||
more pragmatic way. You can read those guidelines by following this URL:
|
||||
|
||||
* FSF Respects Your Freedom (RYF) guidelines:
|
||||
<https://web.archive.org/web/20220604203538/https://ryf.fsf.org/about/criteria/>
|
||||
|
||||
Put simply, the RYF guidelines pertain to commercial products, with the
|
||||
stipulation that they must not contain proprietary software, or known privacy
|
||||
issues like backdoors.
|
||||
|
||||
The total exclusion of all proprietary software is currently not feasible. For
|
||||
example, proprietary SDR firmware in WiFi chipsets, firmware in AHCI devices
|
||||
like HDDs or SSDs, and the like. The FSF RYF guidelines state the following
|
||||
exception, to mitigate this fact:
|
||||
|
||||
* "However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software."
|
||||
|
||||
*This should be
|
||||
rejected on ideological grounds*. The rest of libreboot's policy and overall
|
||||
ideology expressed, in this article, will be based largely on that rejection.
|
||||
The definition of *product software* is completely arbitrary; software is
|
||||
software, and software should always be *libre*. Instead of making such
|
||||
exceptions, more hardware should be encouraged, with help given to provide as
|
||||
much freedom as possible, while providing education to users about any pitfalls
|
||||
they may encounter, and encourage freedom at all levels. When an organisation
|
||||
like the FSF makes such bold exceptions as above, it sends the wrong message,
|
||||
by telling people essentially to sweep these other problems under the rug, just
|
||||
because they involve software that happens to run on a "secondary processor".
|
||||
If the software is possible to update by the user, then it should be libre,
|
||||
regardless of whether the manufacturer *intended* for it to be upgraded or not.
|
||||
Where it really *isn't* possible to update such software, proprietary or not,
|
||||
advice should be given to that effect. Education is important, and the FSF's
|
||||
criteria actively discourages such education; it creates a false hope that
|
||||
everything is great and wonderful, just because the software on one arbitrary
|
||||
level is all perfect.
|
||||
|
||||
This view of the FSF's, as expressed in the quoted paragraph, assumes that
|
||||
there is primarily *one* main processor controlling your system. On many
|
||||
modern computers, this is *no longer true*.
|
||||
|
||||
Libre *software* does not exist in a vacuum, but we had less freedom in the
|
||||
past, especially when it came to hardware, so *software* was our primary focus.
|
||||
|
||||
The ability to study, adapt, share and use/re-use software freely is important,
|
||||
but there is a lot of nuance when it comes to *boot firmware*, nuance which is
|
||||
largely non-existent outside of firmware development, or kernel development.
|
||||
Most typical application/system software is high level and portable, but boot
|
||||
firmware has to be written for each specific machine, and due to the way
|
||||
hardware works, there are many trade-offs made, including by the FSF when
|
||||
defining what standards should apply *in practise*.
|
||||
|
||||
The fact that almost nobody talks about the EC firmware is *because* of the
|
||||
Respects Your Freedom certification. In reality, the EC firmware is crucial
|
||||
to user freedom, and ought to be free, but it is completely disregarded by
|
||||
the FSF as *part of the hardware*. This is wrong, and the FSF should actively
|
||||
encourage people to free it, on every laptop!
|
||||
|
||||
Other firmware currently outside the reach of the libreboot project are covered
|
||||
in the libreboot FAQ page. For example, HDD/SSD firmware is covered in the FAQ.
|
||||
Again, completely disregarded and shrugged off by the FSF.
|
||||
|
||||
The libreboot project will not hide or overlook these issues, because they are
|
||||
indeed critical, but again, currently outside the scope of what the Libreboot
|
||||
build system does. At the moment, the Libreboot build system concerns itself
|
||||
just with coreboot (and payloads), but this ought to change in the future.
|
||||
|
||||
Examples of FSF *sweeping blobs under the rug*
|
||||
----------------------------------------------
|
||||
|
||||
Over the years, there have been numerous cases where the FSF actively fails to
|
||||
provide incentive for levels of software freedom, such as:
|
||||
|
||||
* TALOS II "OpenPOWER" workstation from Raptor Engineering USA. It contains a
|
||||
broadcom NIC inside it which requires firmware, and that firmware was non-free.
|
||||
The FSF were willing to ignore it, and certify the TALOS II product under RYF,
|
||||
but Timothy Pearson of Raptor Engineering had it freed anyway, without being
|
||||
told to. Hugo Landau reverse engineered the specification and Evan Lojewski
|
||||
wrote libre firmware. See:
|
||||
See: <https://www.devever.net/~hl/ortega> and <https://github.com/meklort/bcm5719-fw>
|
||||
* FSF once endorsed the ThinkPad X200, as sold by [Minifree Ltd](https://minifree.org),
|
||||
which contains the Intel ME; the bootrom is still there, as is the ME
|
||||
coprocessor, but the ME is put into a disabled state via the Intel Flash
|
||||
Descriptor, and the ME firmware in flash is removed. However, the ME is an
|
||||
entire coprocessor which, with libre firmware, could be used for a great many
|
||||
things. In the Libreboot and coreboot projects, there has always been interest
|
||||
in this but the FSF disregards it entirely. The X200 product they certified
|
||||
came with Libreboot pre-installed.
|
||||
* Libreboot has a utility written by I, Leah Rowe, that generates ICH9M flash
|
||||
descriptors and GbE NVM images from scratch. This is necessary to configure
|
||||
the machine, but these are binary blobs otherwise; the FSF would have been
|
||||
quite content to certify the hardware anyway since these were non-software
|
||||
blobs in a format fully documented by Intel (they are just binary configuration
|
||||
files), but I went ahead and wrote ich9gen anyway. With ich9gen, you can
|
||||
more easily modify the descriptor/gbe regions for your firmware image. See:
|
||||
<https://libreboot.org/docs/install/ich9utils.html> - libreboot also has this
|
||||
* FSF once endorsed the ThinkPad T400 with Libreboot, as sold by Minifree. This
|
||||
machine comes in two versions: with ATI+Intel GPU, or only Intel GPU. If ATI
|
||||
GPU, it's possible to configure the machine so that either GPU is used. If the
|
||||
ATI GPU is to be used, a binary blob is needed for initialization, though the
|
||||
driver for it is entirely libre. *The FSF* ignored this fact and endorsed the
|
||||
hardware, so long as Libreboot does not enable the ATI GPU or tell people how
|
||||
to enable it. The *Intel* GPU on that machine has libre initialization code by
|
||||
the coreboot project, and a fully libre driver in both Linux and BSD kernels.
|
||||
In the configuration provided by Libreboot, the ATI GPU is completely disabled
|
||||
and powered down.
|
||||
* All Libreboot-compatible ThinkPads contain proprietary Embedded Controller
|
||||
firmware, which is user-flashable (*and intended for update by the
|
||||
manufacturer*). The FSF chose to ignore the EC firmware, under
|
||||
their *secondary processor* exemption. See:
|
||||
<http://libreboot.org/faq.html#ec-embedded-controller-firmware>
|
||||
|
||||
In all of the above cases, the FSF could have been stricter, and bolder, by
|
||||
insisting that these *additional* problems for freedom were solved. They did
|
||||
not. There are many other examples of this, but the purpose of this article is
|
||||
not to list all of them (otherwise, a book could be written on the subject).
|
||||
|
||||
Problems with FSDG
|
||||
------------------
|
||||
|
||||
<img tabindex=1 src="https://av.libreboot.org/firmware.png" /><span class="f"><img src="https://av.libreboot.org/firmware.png" /></span>
|
||||
|
||||
The FSF maintains another set of criteria, dubbed Free System Distribution
|
||||
Guidelines (GNU FSDG)]. They recommend a special version of the Linux kernel,
|
||||
dubbed *linux-libre*, which removes all vendor code from upstream. These
|
||||
vendor files are required for certain hardware to work correctly.
|
||||
|
||||
The FSDG criteria is separate from RYF, but has similar problems. FSDG is
|
||||
what the FSF-endorsed GNU+Linux distros comply with. Basically, it bans
|
||||
all proprietary software, including device firmware. This may seem noble, but
|
||||
it's extremely problematic in the context of firmware.
|
||||
|
||||
*Banning* linux-firmware specifically is a threat to freedom in the long term,
|
||||
because new users of GNU+Linux might be discouraged from using the OS if their
|
||||
hardware doesn't work. You might say: just buy new hardware! This is often not
|
||||
possible for users, and the user might not have the skill to reverse engineer
|
||||
it either. **Banning such firmware constitutes
|
||||
*[censorship](https://en.wikipedia.org/wiki/Book_burning)*, in the name of
|
||||
freedom, but all it does is reduce freedom of choice; somebody else has already
|
||||
made that decision for you, *against* you.** You should not use linux-libre at
|
||||
all. Some wisdom:
|
||||
|
||||
* Excluding vendor blobs in the linux kernel is *bad*. Proprietary firmware
|
||||
is *also bad*. Including them is a wiser choice, if strong education is also
|
||||
provided about *why they are bad* (less freedom). If you expose them to
|
||||
the user, and tell them about it, there is greater incentive (by simple
|
||||
reminder of their existence) to reverse engineer and replace them.
|
||||
* Firmware *in your OS kernel* is *good*. The FSF simultaneously gives the OK
|
||||
for hardware *with those same binary blobs* if the firmware is embedded
|
||||
into a ROM/flash chip on the device, or embedded in some processor. If the
|
||||
firmware is on separate ROM/flash, it could still be replaced by the user via
|
||||
reverse engineering, but then you would probably have to do some soldering
|
||||
(replace the chip on the card/device). *If the firmware is loaded by the
|
||||
OS kernel, then the firmware is exposed to the user and it can be more
|
||||
easily replaced. FSF criteria in this regard encourages hardware designers
|
||||
to hide the firmware instead, making actual (software) freedom less likely!*
|
||||
|
||||
Besides this, FSDG seems OK. Any libre operating system should ideally not
|
||||
have proprietary *drivers* or *applications*. Libreboot *previously* adhered
|
||||
to FSDG, but now takes a more pragmatic approach when it comes to things like
|
||||
CPU microcode or *EC firmware*.
|
||||
|
||||
Hardware manufacturers like to shove everything into firmware because their
|
||||
product is often poorly designed, so they later want to provide workarounds in
|
||||
firmware to fix issues. In many cases, a device will already have firmware on it
|
||||
but require an update supplied to it by your OS kernel.
|
||||
|
||||
The most common example of proprietary firmware in Linux is for wifi devices.
|
||||
This is an interesting use-case scenario, with source code, because it could be
|
||||
used for owner-controlled *software defined radio*.
|
||||
|
||||
The *Debian* way is ideal. The Debian GNU+Linux distribution is entirely libre
|
||||
by default, and they include extra firmware if needed, which they have in a
|
||||
separate repository containing it. If you only want firmware, it is
|
||||
trivial to get installer images with it included, or add that to your installed
|
||||
system. They tell you how to do it, which means that they are helping people
|
||||
to get *some* freedom *rather than none*. This is an inherently pragmatic
|
||||
way to do things, and it's now how Libreboot does it.
|
||||
|
||||
More context regarding Debian is available in this blog post:
|
||||
<https://blog.einval.com/2022/04/19#firmware-what-do-we-do> - in it, the
|
||||
author, a prominent Debian developer, makes excellent points about device
|
||||
firmware similar to the (Libreboot) article that you're reading now. It's
|
||||
worth a read! As of October 2022, Debian has voted to include device firmware
|
||||
by *default*, in following Debian releases. It used to be that Debian excluded
|
||||
such firmware, but allowed you to add it.
|
||||
|
||||
OpenBSD is very much the same, but they're clever about it: during the initial
|
||||
boot, after installation, it tells you exactly what firmware is needed and
|
||||
updates that for you. It's handled in a very transparent way, by
|
||||
their `fw_update` program which you can read about here:
|
||||
|
||||
<https://man.openbsd.org/fw_update>
|
||||
|
||||
OpenBSD is great.
|
||||
|
||||
More detailed insight about microcode
|
||||
=====================================
|
||||
|
||||
[Releases after 20230423 will provide separate ROM images with microcode
|
||||
excluded, alongside the default ones that include microcode.](microcode.md)
|
||||
|
||||
To be clear: it is preferable that microcode be libre. The microcode on Intel
|
||||
and AMD systems *are* proprietary. Facts and feelings rarely coincide; the
|
||||
purpose of this section is to spread *facts*.
|
||||
|
||||
The libreboot build system now enables microcode updates *by default.*
|
||||
|
||||
Not including CPU microcode updates is an absolute disaster for system
|
||||
stability and security.
|
||||
|
||||
Making matters worse, that very same text quoted from the FSF RYF criteria in
|
||||
fact specifically mentions microcode. Quoted again for posterity:
|
||||
|
||||
*"However, there is one exception for secondary embedded processors. The
|
||||
exception applies to software delivered inside auxiliary and low-level
|
||||
processors and FPGAs, within which software installation is not intended after
|
||||
the user obtains the product. This can include, for instance, microcode inside
|
||||
a processor, firmware built into an I/O device, or the gate pattern of an FPGA.
|
||||
The software in such secondary processors does not count as product software."*
|
||||
|
||||
Here, it is discussing the microcode that is burned into *mask ROM* on the CPU
|
||||
itself. It is simultaneously not giving the OK for microcode *updates* supplied
|
||||
by either coreboot or the Linux kernel; according to the FSF, these are an
|
||||
attack on your freedom, but the older, buggier microcode burned into ROM is OK.
|
||||
|
||||
The CPU already has microcode burned into mask ROM. The microcode configures
|
||||
logic gates in the CPU, to implement an instruction set, via special *decoders*
|
||||
which are fixed-function; it is not possible, for example, to implement a RISCV
|
||||
ISA on an otherwise x86 processor. It is only possible for the microcode to
|
||||
implement x86, or *broken* x86, and the default microcode is almost always
|
||||
*broken x86* on Intel/AMD CPUs; it is inevitable, due to the complexity of
|
||||
these processors.
|
||||
|
||||
The FSF believes
|
||||
that these x86 microcode updates (on Intel/AMD) allow you to completely create
|
||||
a new CPU that is fundamentally different than x86. This is not true. It is also
|
||||
not true that *all* instructions in x86 ISA are implemented with microcode. In
|
||||
some cases, hardcoded circuitry is used! The microcode updates are more like
|
||||
tiny one liner patches here and there in a git repository, by way of analogy.
|
||||
To once again get in the head-space of the FSF: these updates cannot do the CPU
|
||||
equivalent of re-factoring an entire codebase. They are *hot fixes*, nothing
|
||||
more!
|
||||
|
||||
Not including these updates will result in an unstable/undefined state. Intel
|
||||
themselves define which bugs affect which CPUs, and they define workarounds, or
|
||||
provide fixes in microcode. Based on this, software such as the Linux kernel
|
||||
can work around those bugs/quirks. Also, upstream versions of the Linux kernel
|
||||
can update the microcode at boot time (however, it is recommend still to do it
|
||||
from coreboot, for more stable memory controller initialization or “raminit”).
|
||||
Similar can be said about AMD CPUs.
|
||||
|
||||
Here are some examples of where lack of microcode updates affected *Libreboot*,
|
||||
forcing Libreboot to work around changes made upstream in coreboot, changes
|
||||
that were *good* and made coreboot behave in a more standards-compliant manner
|
||||
as per Intel specifications. Libreboot had to *break* coreboot to retain
|
||||
certain other functionalities, on some GM45/ICH9M thinkpads:
|
||||
|
||||
<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>
|
||||
|
||||
These patches revert *bug fixes* in coreboot, fixes that happen to break other
|
||||
functionality but only when microcode updates are excluded. The most
|
||||
technically correct solution is to *not* apply the above patches, and instead
|
||||
supply microcode updates!
|
||||
|
||||
Pick your poison. Not adding the updates is *irresponsible*, and ultimately
|
||||
futile, because you still end up with proprietary microcode, but you just get
|
||||
an older, buggier version instead!
|
||||
|
||||
This shift in project policy does not affect your freedom at all, because you
|
||||
still otherwise have older, buggier microcode anyway. However, it does improve
|
||||
system reliability by including the updates!
|
||||
|
||||
Such pragmatic policy is *superior* to the *dogma* that Libreboot users once
|
||||
had to endure. Simply put, the Libreboot project aims to give users as much
|
||||
freedom as is possible for their hardware; this was always the case, but this
|
||||
mentality is now applied to [a lot] more hardware.
|
||||
|
||||
Other considerations
|
||||
====================
|
||||
|
||||
Also not covered strictly by Libreboot: OSHW and Right To Repair. Freedom at
|
||||
the silicon level would however be amazing, and efforts already exist; for
|
||||
example, look at the RISCV ISA (in practise, actual fabrication is still
|
||||
proprietary and not under your control, but RISCV is a completely libre CPU
|
||||
design that companies can use, instead of having to use proprietary ARM/x86 and
|
||||
so on). Similarly, Right To Repair (ability to repair your own device, which
|
||||
implies free access to schematics and diagrams) is critical, for the same
|
||||
reason that Libre Software (Right To Hack) is critical!
|
||||
|
||||
OSHW and Right To Repair are not covered at all by RYF (FSF's Respects Your
|
||||
Freedom criteria), the criteria which Libreboot previously complied with.
|
||||
RYF also makes several concessions that are ultimately damaging, such as
|
||||
the *software as circuitry* policy which is, frankly, nonsensical. ROM is still
|
||||
software. There was a time when the FSF didn't consider BIOS software a freedom
|
||||
issue, just because it was burned onto a mask ROM instead of *flashed*; those
|
||||
FSF policies ignore the fact that, with adequate soldering skills, it is trivial
|
||||
to replace stand-alone mask ROM ICs with compatible flash memory.
|
||||
|
||||
Conclusion
|
||||
==========
|
||||
|
||||
RYF isn't *wrong* per se, just flawed. It is correct in some ways and if
|
||||
complied with, the result *does* give many freedoms to the user, but RYF
|
||||
completely disregards many things that are now possible, including freedoms at
|
||||
the hardware level (the RYF criteria only covers *software*). Those guidelines
|
||||
are written with assumptions that were still true in the 1990s, but the world
|
||||
has since evolved. The libreboot project rejects those policies in their
|
||||
entirety, and instead takes a pragmatic approach.
|
||||
|
||||
The conclusion that should be drawn from all of this is as follows:
|
||||
|
||||
*Following* FSF criteria does not damage anything, but that criteria is very
|
||||
conservative. Its exemptions should be *disregarded* and entirely ignored.
|
||||
RYF is no longer fit for purpose, and should be rewritten to create
|
||||
a *more strict* set of guidelines, without all the loopholes or exemptions.
|
||||
As has always been the case, Libreboot tries to always go above and beyond, but
|
||||
the Libreboot project does not see RYF as a *gold standard*. There are levels
|
||||
of freedom possible now that the RYF guidelines do not cover at all, and in
|
||||
some cases even actively discourage/dis-incentivize because it makes compromises
|
||||
based on assumptions that are no longer true.
|
||||
|
||||
Sad truth: RYF actively encourages *less* freedom, by not being bold enough.
|
||||
It sets a victory flag and says *mission accomplished*, despite the fact
|
||||
that the work is *far* from complete!
|
||||
|
||||
If followed *with exemptions unchallenged*, RYF may in some cases encourage
|
||||
companies to *sweep under the rug* any freedom issues that exist, where it
|
||||
concerns proprietary firmware not running on the host CPU (such as the
|
||||
Embedded Controller firmware).
|
||||
|
||||
I propose that new guidelines be written, to replace RYF. These new guidelines
|
||||
will do away with all exemptions/loopholes, and demand that *all* software be
|
||||
libre on the machine, or as much as possible. Instead of only promoting products
|
||||
that meet some arbitrary standard, simply catalog all systems on a grand
|
||||
*database* of sorts (like h-node.org, but better), which will define exactly
|
||||
what *hardware* **and** software issues exist on each device. Include Right to
|
||||
Repair and OSHW (including things like RISCV) in the most "ideal"
|
||||
standard machine; the gold standard is libre *silicon*, like what Sam Zeloof
|
||||
and others are working on nowadays.
|
||||
|
||||
This new set of criteria should not attempt to hide or ignore *anything*. It
|
||||
should encourage people to push the envelope and innovate, so that we can have
|
||||
much *more* freedom than is currently possible. Necessity is the mother of all
|
||||
invention, and freedom is an important goal in every aspect of life, not just
|
||||
computing.
|
||||
|
||||
Don't call it "Respects Your Freedom" or something similar. Instead, call it
|
||||
something like: the freedom catalog. And actually focus on hardware, not just
|
||||
software!
|
||||
|
||||
Other resources
|
||||
===============
|
||||
|
||||
Ariadne Conill's RYF blog post
|
||||
------------------------------
|
||||
|
||||
Ariadne Conill, security team chair of *Alpine Linux*, posted a very robust
|
||||
article about RYF, with similar points made when compared to *this* article.
|
||||
However, Ariadne goes into detail on several other examples of problems with
|
||||
the FSF RYF criteria; for example, it talks about the *Novena* product by
|
||||
Bunnie.
|
||||
|
||||
It's worth a read! Link:
|
||||
|
||||
<https://ariadne.space/2022/01/22/the-fsfs-relationship-with-firmware-is-harmful-to-free-software-users/>
|
||||
|
|
|
|||
|
|
@ -170,363 +170,3 @@ Libreboot вирішує цю ситуацію *суворо* та *принци
|
|||
* <https://libresilicon.com/>
|
||||
|
||||
(Сем буквально виробляє процесори в своєму гаражі)
|
||||
|
||||
Проблеми з критеріями RYF
|
||||
==========================
|
||||
|
||||
Раніше Libreboot відповідав критеріям FSF RYF, але тепер він дотримується
|
||||
набагато більш прагматичної політики, спрямованої на надання більшої свободи більшій кількості людей у
|
||||
більш прагматичний спосіб. Ви можете прочитати ці вказівки, перейшовши за цією URL-адресою:
|
||||
|
||||
* Рекомендації FSF Поважає Вашу Свободу (RYF):
|
||||
<https://web.archive.org/web/20220604203538/https://ryf.fsf.org/about/criteria/>
|
||||
|
||||
Простіше кажучи, інструкції RYF стосуються комерційних продуктів із застереженням,
|
||||
що вони не повинні містити пропрієтарне програмне забезпечення чи відомі проблеми конфіденційності,
|
||||
як-от лазівки.
|
||||
|
||||
Повне виключення всього пропрієтарного забезпечення наразі неможливе. Наприклад,
|
||||
пропрієтарне мікропрограмне забезпечення SDR у чіпсетах WiFi, мікропрограмне забезпечення пристроїв AHCI, таких як
|
||||
жорсткі диски або твердотілі накопичувачі тощо. В інструкціях FSF RYF зазначено наступний виняток, щоб пом'якшити цей факт:
|
||||
|
||||
* "Однак є один виняток для вторинних вбудованих процесорів. Виняток стосується програмного забезпечення, що постачаєтья в бічних допоміжних і низькорівневих процесорах та FPGA, у яких встановлення програмного забезпечення не передбачається після того, як користувач отримає продукт. Це може включати, наприклад, мікрокод всередині процесора, мікропрограму, вбудовану в пристрій вводу-виводу, або структуру вентилів FPGA. Програмне забезпечення в таких вторинних процесорах не вважається програмним забезпеченням продукту."
|
||||
|
||||
*та має бути відхилено
|
||||
з ідеологічних міркувань*. Решта політики 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.uk.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 можуть бути відбиті від використання ОС, якщо їх
|
||||
апаратне забезпечення не працює. Ви можете сказати: просто купіть нове обладнання! Це часто неможливо
|
||||
для користувачів, і користувач також може не мати навичок для
|
||||
зворотного проектування.
|
||||
|
||||
Більш детальна інформація про мікрокод
|
||||
=====================================
|
||||
|
||||
[Releases after 20230423 will provide separate ROM images with microcode
|
||||
excluded, alongside the default ones that include microcode.](microcode.md)
|
||||
|
||||
Щоб було зрозуміло: бажано, щоб мікрокод був вільним. Мікрокод систем Intel
|
||||
та AMD *є* пропрієтарним. Факти і почуття рідко збігаються; метою цього
|
||||
розділу є поширення *фактів*.
|
||||
|
||||
Система збірки libreboot тепер дозволяє оновлення мікрокоду *за замовчуванням.*
|
||||
|
||||
Відсутність оновлень мікрокоду ЦП є абсолютною катастрофою для стабільності
|
||||
та безпеки системи.
|
||||
|
||||
Що ще гірше, той самий текст, цитований із критеріїв FSF RYF,
|
||||
насправді конкретно згадує мікрокод. Знову процитую для нащадків:
|
||||
|
||||
*"Однак є один виняток для вторинних вбудованих процесорів. Виняток
|
||||
стосується програмного забезпечення, що постачається всередині допоміжних і низкорівневих
|
||||
процесорів та FPGA, у яких інсталяція програмного забезпечення не передбачається після того,
|
||||
як користувач отримає продукт. Це може включати, наприклад, мікрокод всередині
|
||||
процесора, мікропрограму, вбудовану в пристрій вводу-виводу, або структуру вентилів FPGA.
|
||||
Програмне забезпечення в таких вторинних процесорах не вважається програмним забезпеченням продукту."*
|
||||
|
||||
Тут обговорюється мікрокод, який записується в *mask ROM* на самому
|
||||
ЦП. Одночасно він не дає ОК для *оновлень* мікрокоду, які надаються
|
||||
coreboot або ядром Linux; згідно з FSF, це напад на
|
||||
вашу свободу, але старіший мікрокод із більшими помилками, записаний на ROM, є нормальним.
|
||||
|
||||
ЦП вже має мікрокод, записаний в mask ROM. Мікрокод налаштовує
|
||||
логічні вентилі в ЦП, для реалізації набору інструкцій через спеціальні *декодери*,
|
||||
які мають фіксовану функцію; неможливо, наприклад, реалізувати набір інструкцій RISCV
|
||||
на процесорі x86. Для мікрокода можливо тільки
|
||||
реалізувати x86, або *зламаний* x86, і мікрокод за замовчуваням майже завжди є
|
||||
*зламаним x86* на ЦП Intel/AMD; це неминуче через складність цих
|
||||
процесорів.
|
||||
|
||||
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. Простіше кажучи, проект Libreboot має на меті надати користувачам
|
||||
якомога більше свободи для їх апаратного забезпечення; так було завжди,
|
||||
але цей менталітет тепер застосовується до [набагато] більшої кількості обладнання.
|
||||
|
||||
Інші міркування
|
||||
====================
|
||||
|
||||
Також Libreboot не покриває суворо: OSHW і Право на ремонт (Right To Repair). Однак свобода
|
||||
на рівні кремнію була б дивовижною, і зусилля вже є; наприклад, подивіться на RISCV ISA (на
|
||||
практиці фактичне виготовлення все ще є пропрієтарним і не під вашим контролем, але RISCV є повністю вільним
|
||||
дизайном ЦП, який компанії можуть використовувати замість того, щоб використовувати пропрієтарний ARM/x86 і
|
||||
так далі). Подібним чином, Право на ремонт (можливість відремонтувати свій власний пристрій, що
|
||||
передбачає вільний доступ до схем і діаграм) є критично важливим з тієї ж причини, що
|
||||
критично важливо вільне програмне забезпечення (Право на хакерство)!
|
||||
|
||||
OSHW і Право на ремонт взагалі не охоплюються RYF (критерії FSF Поважає Вашу
|
||||
Свободу), критеріями, яких Libreboot дотримувався раніше..
|
||||
RYF також робить кілька поступок, які зрештою завдають шкоди, наприклад,
|
||||
політика *програмне забезпечення як схема*, яка, чесно кажучи, є безглуздою. ROM все ще
|
||||
програмне забезпечення. Був час, коли FSF не вважав програмне забезпечення BIOS проблемою
|
||||
свободи, лише тому, що воно записане на mask ROM, а не *прошито*; ця
|
||||
політика FSF ігнорує той факт, що, маючи відповідні навички паяння, легко замінити
|
||||
автономні мікросхеми mask ROM на сумісну флеш-пам'ять.
|
||||
|
||||
Висновки
|
||||
==========
|
||||
|
||||
RYF сам по собі не є *неправильним*, просто має недоліки. Певним чином це правильно, і
|
||||
якщо його дотримуватися, результат *надає* багато свобод користувачеві, але RYF
|
||||
повністю ігнорує багато речей, які зараз можливі, включаючи свободи на
|
||||
апаратному рівні (критерії RYF охоплюють лише *програмне забезпечення*). Ці вказівки
|
||||
написані з припущеннями, які все ще були вірними в 1990-х роках, але відтоді
|
||||
світ змінився. Проект libreboot повністю відкидає цю політику та натомість
|
||||
використовує прагматичний підхід.
|
||||
|
||||
Висновок, який слід зробити з усього цього, такий:
|
||||
|
||||
*Дотримання* критеріїв FSF нічого не шкодить, але ці критерії є дуже
|
||||
консервативними. Його винятки слід *ігнорувати* та повністю ігнорувати. RYF
|
||||
більше не відповідає меті, і його слід переписати, щоб створити *більш суворий*
|
||||
набір інструкцій без усіх лазівок чи винятків.
|
||||
Як завжди було, Libreboot намагається завжди виходити за межі, але
|
||||
проект Libreboot не розглядає RYF як *золотий стандарт*. Зараз є
|
||||
можливі рівні свободи, які вказівки RYF взагалі не охоплюють, а
|
||||
в деяких випадках навіть активно не заохочують/перешкоджають, оскільки це робить компроміси
|
||||
на основі припущень, які більше не відповідають дійсності.
|
||||
|
||||
Сумна правда: RYF активно заохочує *менше* свободи, не будучи достатньо сміливим.
|
||||
Він встановлює прапор перемоги та говорить *місію виконано*, незважаючи на те, що
|
||||
робота *далека* від завершення!
|
||||
|
||||
Якщо дотримуватись *з незаперечними винятками*, RYF може в деяких випадках заохочувати
|
||||
компанії *приховувати* будь-які проблеми зі свободою, які існуюють,
|
||||
коли це стосується пропрієтарного мікропрограмного забезпечення, яке не працює на центральному процесорі хоста (наприклад, мікропрограмне забезпечення
|
||||
вбудованого контролера).
|
||||
|
||||
Я пропоную написати нові рекомендації, щоб замінити RYF. Ці нові правила
|
||||
ліквідують усі винятки/лазівки та вимагають, щоб *все* програмне забезпечення
|
||||
було вільним на машині або якомога більше. Замість того, щоб лише рекламувати продукти,
|
||||
які відповідають певним стандартам, просто каталогізуйте всі системи у великій
|
||||
*базі даних* свого роду (наприклад, h-node.org, але краще), яка точно визначатиме, які
|
||||
*апаратні* **і** програмні проблеми існують на кожному пристрої. Включіть Право
|
||||
на ремонт і OSHW (включно з такими речами, як RISCV) до найбільш "ідеальної"
|
||||
стандартної машини; золотим стандартом є вільний *кремній*, як те, над чим
|
||||
Сем Зелоф та інші працюють зараз.
|
||||
|
||||
Цей новий набір критеріїв не повинен намагатися приховати або проігнорувати *щось*. Це
|
||||
має заохочувати людей розширювати рамки та впроваджувати інновації, щоб ми могли мати
|
||||
набагато *більше* свободи, ніж зараз можливо. Необхідність є матір'ю всіх
|
||||
винаходів, а свобода є важливою метою в кожному аспекті життя, не лише в
|
||||
обчисленні.
|
||||
|
||||
Не називайте це "Поважає вашу свободу" чи щось подібне. Натомість назвіть це
|
||||
приблизно так: каталог свободи. І насправді зосередьтеся на апаратному забезпеченні, а не
|
||||
лише на програмному забезпеченні!
|
||||
|
||||
Інші ресурси
|
||||
===============
|
||||
|
||||
Повідомлення в блозі 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/>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ x-toc-enable: true
|
|||
проект, як приймаються рішення, і взагалі як проект функціонує.
|
||||
|
||||
Ви можете знайти інформацію про великий внесок, зроблений у libreboot, на цій
|
||||
сторінці, яка перелічує таких людей: [Список учасників](contrib.uk.md)
|
||||
сторінці, яка перелічує таких людей: [Список учасників](contrib.md)
|
||||
|
||||
Лія Роу (засновниця, провідний розробник)
|
||||
===================================
|
||||
|
|
@ -17,7 +17,7 @@ x-toc-enable: true
|
|||
і керує серверами libreboot.org зі своєї лабораторії у Великобританії.
|
||||
|
||||
Ви можете дізнатися більше про участь Лії в libreboot, прочитавши її запис на
|
||||
[сторінці зі списком усіх учасників, минулих і теперішніх](contrib.uk.md)
|
||||
[сторінці зі списком усіх учасників, минулих і теперішніх](contrib.md)
|
||||
|
||||
Калеб Ла Гранж
|
||||
===============
|
||||
|
|
@ -27,7 +27,7 @@ x-toc-enable: true
|
|||
та документацією.
|
||||
|
||||
Ви можете дізнатись більше про участь Калеба в libreboot, прочитавши його
|
||||
запис на [сторінці зі списком усіх учасників, минулих і теперішніх](contrib.uk.md)
|
||||
запис на [сторінці зі списком усіх учасників, минулих і теперішніх](contrib.md)
|
||||
|
||||
Альпер Небі Ясак
|
||||
================
|
||||
|
|
@ -37,7 +37,7 @@ x-toc-enable: true
|
|||
апстрім роботу над самим U-Boot. `alpernebbi` на Libera IRC.
|
||||
|
||||
Ви можете дізнатись більше про участь Альпера в Libreboot, читаючи його
|
||||
запис на [сторінці зі списком усіх учасників, минулих і теперішніх](contrib.uk.md)
|
||||
запис на [сторінці зі списком усіх учасників, минулих і теперішніх](contrib.md)
|
||||
|
||||
Потрібні розробники!
|
||||
==================
|
||||
|
|
|
|||
Loading…
Reference in New Issue