Linux in varen zagon. Napaka, ki je ne moremo ponoviti

V prejšnji članek Spomnil sem se na precedens Microsoftove zahteve, da od modula TPM različice 2 zahteva uporabo sistema Windows 11. Sklicujem se na zahtevo, da računalniki z vnaprej nameščenim sistemom Windows 8 uporabljajo UEFI namesto BIOS-a za zagonski nalagalnik in da modul Secure Boot je bil vnaprej nameščen.  Zdaj bom govoril o, po mojem mnenju, napačnem načinu, kako je Linux rešil težavo.

Linux in varen zagon

Secure Boot zahteva, da ima vsak program, ki se zažene, podpis, ki jamči za njegovo pristnost, shranjeno v bazi podatkov nenehnega pomnilnika matične plošče. V tej zbirki podatkov lahko vidite dva načina. Ne glede na to, ali jih vključuje proizvajalec ali Microsoft.

Rešitev, ki so jo pri Microsoftu dosegle nekatere distribucije Linuxa je bilo, da je to podjetje sprejelo podpis binarnega dokumenta, ki bi bil zadolžen za zagon zagonskega nalagalnika vsake distribucije. Te binarne datoteke so bile na voljo skupnosti.

Kasneje bo Linux Foundation uvedla generično rešitev, ki jo bodo lahko sprejele vse distribucije.

V iskanju boljše rešitve je razvijalec Red Hat Linusu Torvaldsu predlagal naslednje:

Živjo Linus,

Lahko prosim vključite ta komplet popravkov?

Zagotavlja funkcijo, s katero je mogoče ključe dinamično dodajati jedru, ki deluje v načinu varnega zagona. Če želite dovoliti nalaganje ključa pod takšnim pogojem, zahtevamo, da se novi ključ podpiše s ključem, ki ga že imamo (in mu zaupamo), kjer bi lahko ključi, ki jih "že imamo", vključevali tiste, vdelane v jedro, tiste v zbirki podatkov UEFI in tiste iz kriptografske strojne opreme.

Zdaj bo "keyctl add" že obdeloval potrdila X.509, ki so podpisana tako, vendar bo Microsoftova storitev podpisovanja podpisala samo izvedljive binarne datoteke EFI PE.

Od uporabnika bi lahko zahtevali, da se znova zažene v BIOS -u, doda ključ in se nato preklopi nazaj, vendar v nekaterih okoliščinah želimo, da to zmoremo, medtem ko jedro deluje.

Način, kako smo to odpravili, je vdelava potrdila X.509, ki vsebuje ključ v razdelku, imenovanem ".keylist", v binarni datoteki EFI PE, nato pa dobimo podpisani binarni dokument Microsoft

Linusova beseda

Linusov odgovor (Spomnimo se, da je moral pred duhovnim umikom premisliti o svojem odnosu v odnosih z drugimi ljudmi) je bil naslednji:

OBVESTILO: Naslednje besedilo vključuje kletvice

Fantje, to ni tekmovanje v sesanju tičkov.

Če želite uporabiti dvojiške datoteke PE, nadaljujte. Če želi Red Hat poglobiti svoj odnos z Microsoftom, je to * vaša * težava. To nima nič opraviti z jedrom, ki ga vzdržujem. Z lahkoto imate mehanizem podpisov, ki razčlenjuje binarni dokument PE, preverja podpise in podpisuje nastale ključe z lastnim ključem. Koda, za božjo voljo, je že napisana in je v tisti prekleti prošnji za vključitev.

Zakaj bi me skrbelo? Zakaj bi moralo jedro skrbeti za neke idiotske "podpisujemo samo PE binarne datoteke" neumnega? Podpiramo X.509, ki je standard za podpisovanje.

To je mogoče storiti na ravni uporabnika. V jedru ni izgovora za to.

Linus

Moje mnenje je, da je imel Linus enkrat prav. Pravzaprav Microsoft ne bi smel izsiljevati niti fundacije Linux niti distribucij.  Res je, da bi lahko bili uporabniki izgubljeni. Toda, kot se je kasneje izkazalo, je bil Windows 8 neuspešen in XP je vladal še dlje.

Dejstvo je, da se mora Microsoft, ko se sooča z bitko, držati standardov. Zgodilo se je, ko ni uspela s SIlverlight in je bila prisiljena sprejeti spletni standard HTML 5. Zgodilo se je, ko je morala opustiti razvoj motorja za spletno upodabljanje in zasnovati Edge na Chromiumu.

Prav tako ne smemo pozabiti, da je za privabljanje programerjev moralo vključevati le možnost izvajanja Linuxa v sistemu Windows.

Distribucije Linuxa so v boljšem položaju kot kdaj koli prej in uporabnikom ponujajo alternativo za nadaljnjo uporabo popolnoma funkcionalne strojne opreme.