Shim Secure Boot – linuksowy bootloader dla UEFI Secure Boot

Czasem lepiej iść na ustępstwa, aniżeli babrać się w durną ideologię i szkodzić tym samym wszystkim użytkownikom.

A jakie będzie następne ustępstwo? Może komputery działające jak konsole tylko pod fabrycznym oprogramowaniem? A może obowiązkowe reklamy przy starcie systemu? Użyj trochę wyobraźni zamiast nazywać spostrzeżenia innych "babranie się w durną ideologię". Firmom z taką pozycją jak np MS trzeba patrzeć na ręce.

Nie unoś się tak. To łabędzi śpiew Microsoftu, nie wierzysz chyba w to, że łysol Ballmer poprowadzi i utrzyma Microsoft na poziomie Gatesa?
Poza tym kto broni producentom linuksa opierać się pomysłom MS? Nikt! Takiś mądry? To dawaj, powiedz co mięli zrobić.Problem w tym, że nie mięli żadnego innego racjonalnego pomysłu jak wyjść z zaistniałej sytuacji. Ich polityka, tak chwalona przez pieniaczy, znowu ukazała, że są bezradni niczym berbeć i nawet się obrazić nie mogą, bo wzbudzi to tylko śmiech pożałowania.

Wpierw istniał BIOS, jego następcą jest UEFI. Secure Boot to tylko funkcja zaimplementowana w UEFI.

OK ale czy ten Secure Boot to jest taki wbudowany boot loader jak grub / lilo? No i co z tymi sterownikami mam rozumiec, ze bedzie jakis standardowy interfejs do nich i w systemie trzeba bedzie tylko zaimplementowac "obsluge" hardwareu a co to za hardware to juz nie bedzie systemu obchodzic? Jesli tak to to akurat jest dobre.. bo nic nie stoi na przeszkodzie aby pisac otwarte stery do UEFI i z nich korzystac a dla systemu w tym przypadku to nie bedzie roznicy poniewaz on by korzystal tylko z tego standardowego interfejsu ktory udostepni mu UEFI. No i najepsze byly jeden sterownik pod windows / linux / jakikolwiek inny system, z ktorego moglyby korzystac wszystkie systemy.

Secure Boot ot tylko funkcja zaimplementowana w UEFI, która sprawdza, czy dany bootloader systemowy, w Linuksie grubx64.efi, jest odpowiednio podpisany. Shim ma być jakby takim wczesnym bootloaderem, który komunikuje się z UEFI Secure Boot i zapodaje odpowiedni klucz. Jeżeli weryfikacja przejdzie bez problemów, wtedy Shim ładuje grubx64.efi i dalej już standardowo.

OK teraz juz rozumiem.. czyli w sumie nie taki diabel straszny bo nijak nie ingeruje to w samego linuxa. Co do mojego drugiego pytania, to z tego co doczytalem mniej wiecej takby to wygladalo czyli system operacyjny przestalby sie przejmowac sterownikami. Tutaj mysle, ze linux by na tym zyskal gdyz skonczyloby sie narzekanie na brak / jakosc sterownikow bo dla wszystkich systemow bylyby takie same.. a sam dostawca sprzetu musialby sie o taki steownik zatroszczyc. Tyle, ze teraz co dostawca plyty glownej to pewnie inne UEFI, czy taki sterownik napisany pod UEFI od np intela bedzie musial dzialac takze z UEFI innego dostawcy?

Ale od zawsze miałeś różne wersje BIOSów do płyt głównych. Z tego, co wiem to dominowali w Europie: AMI oraz Phoenix BIOS. I tutaj producent płyt głównych wykupywał licencję i sam już przerabiał taki podsystem.

Tak tylko wczesniej sterowniki nie byly pisane dla biosu (poza tymi potrzebnymi do zbootowania system) a pod system. Do obslugi hw bedzie potrzebny sterownik dla danego UEFI.. co bedzie jesli bede chcial dokupic sobie jakas karte na PCI np.. bede musial szukac takiej, ktora jest wspierana przez moje UEFI?

Wydaje mi się, że to przemyślany ruch, mający na celu ograniczenie wolności użytkowników. Jeśli czytaliście licencję GNU/GPL w wersji 3, to zwróciliście uwagę na problem „obchodzenia skutecznych zabezpieczeń”

(por. https://pl.wikipedia.org/wiki/Zarz%C4%85dzanie_prawami_cyfrowymi).
Jeżeli cokolwiek ładuje się przed systemem operacyjnym i nie wiadomo co to jest (bo jest niesprawdzalne), zawsze istnieje możliwość nadużycia.
Za przykład może posłużyć sterownik, który okresowo wysyła zawartość ekranu do producenta komputera.
I można sobie firewalle instalować, szyfrować dyski…