r   e   k   l   a   m   a
r   e   k   l   a   m   a

Twórca Ubuntu wzywa producentów sprzętu do porzucenia ACPI i własnościowego firmware

Strona główna AktualnościOPROGRAMOWANIE

Powodów, dla których ktoś prowadzący firmę związaną z Linuksem może nie lubić ACPI (zaawansowanego interfejsu zarządzania konfiguracją i energią) jest wiele. Krytycy tego rozwiązania skarżą się, że jego implementacje to w praktyce najniższy poziom sterowników Windows, więc praca z tym na innych systemach operacyjnych jest udręką. Mark Shuttleworth – to on jest człowiekiem nie lubiącym ACPI – podkreśla, że to rozwiązanie jest reliktem czasów, w których systemy operacyjne były własnościowe i nie mogły być zmieniane przez producentów sprzętu. Dziś czasy są (według Shuttlewortha) zupełnie inne, więc należy posłać ACPI do lamusa. Ale jak bez ACPI sterować konfiguracją sprzętu i zużyciem energii?

Szef Canonicala wydaje się posiadać maszynę czasu do podróży w przyszłość, gdyż wyjaśnia nam, że dawno dawno temu producenci płyt głównych, nie mogąc zmieniać systemu operacyjnego (czyli Windows), a chcąc dokonać jakichś innowacji, musieli tworzyć firmware udostępniające standardowy interfejs do np. zarządzania energią, by Windows mogło z tego skorzystać.

Z tego co widać na rynku, Windows jest wciąż dominującą platformą (choć już może nie monopolistą). Shuttleworth wierzy jednak, że producenci nie potrzebują dziś ACPI takiego jakie znamy, gdyż swoje innowacje mogą oprogramować bezpośrednio, w postaci łatek dla jądra Linuksa – a to Linux jest niemal na pewno tą platformą, która ma znaczenie. Windows miałoby się zaadaptować do tego modelu, porzucając dotychczas stosowane powszechnie nieweryfikowalne, binarne bloby.

r   e   k   l   a   m   a

Uzasadniając konieczność pozbycia się ACPI, Shuttleworth sięga po argument z bezpieczeństwa, przywołując słowa Bruce'a Schneiera: bezpieczeństwo nie jest produktem, jest procesem. Własnościowe firmware jest najlepszym przyjacielem NSA, ale nie tylko NSA. Dobrze wiemy, że większość producentów sprzętu nie potrafi napisać zbyt dobrych sterowników, liczba błędów w nich jest niemała – a ile z tych błędów zagraża bezpieczeństwu? Tak więc ci, którzy opowiadają się po stronie tego rozwiązania równie dobrze mogliby opowiadać się po stronie zainstalowania w salonie czy nawet centrum danych ogromnego konia trojańskiego.

Z perspektywy producenta Ubuntu idealna sytuacja wygląda tak, że sprzęt zawiera jedynie deklaratywny kod, firmware opisujący powiązania i zależności sprzętu (na wzór drzewa urządzeń Linuksa), jednak nie ma w nim żadnego kodu wykonywalnego. Software'owe komponenty innowacji sprzętowych znaleźć by się miały w oficjalnym linuksowym kernelu. W efekcie uzyskalibyśmy wolną platformę, której bezpieczeństwo można by było publicznie testować, i która działałaby dobrze pod kontrolą każdego, zgodnego z tym modelem systemu operacyjnego.

Apel do producentów sprzętu brzmi dziś bardzo utopijnie, choć możliwe, że w przyszłości, w której żyje Shuttleworth, jest zupełnie inaczej. Dziś przecież trudno niezależnym deweloperom uzyskać od producentów informacje, co dany blob WMI (Windows Management Instrumentation) w sterownikach płyty głównej robi, a co dopiero otrzymać kod źródłowy. Rozpowszechnianie sterowników jako binarnych blobów ma też duże uzasadnienie z perspektywy ochrony własności intelektualnej: dla wielu producentów sprzętu (szczególnie związanych z grafiką i wideo) ujawnienie kodu źródłowego sterowników oznaczałoby naruszenie licencji pozyskanych od firm trzecich.

Zarzuty Shuttlewortha wobec samego ACPI i jego propozycja są też wątpliwe pod względem technicznym. Czy sam deklaratywny firmware, opisujący położenie funkcji, wystarczy bez kodu, który by wiedział, co można zrobić z tą funkcją? Posiadanie standardowego interfejsu, zajmującego się kontrolą systemu, nie jest złym pomysłem. ACPI przecież nie odpowiada tylko za uruchamianie sprzętu, zajmuje się obsługą komponentów, których w praktyce kernel nie jest w stanie obsłużyć (chyba że chcemy np. w kernelu sterowników dla regulatorów napięcia, a w konfiguracji systemu ręcznego wpisywania parametrów sprzętu, jak w czasach starożytnych kart ISA). Z kolei obawy o bezpieczeństwo własnościowych blobów są oczywiście uzasadnione, ale nie trzeba do tego pozbywać się ACPI: aktywnie rozwijana jest otwarta implementacja interfejsu, ACPICA.

To nawoływanie do zmian może mieć więc dziś nieco inny powód. Najnowsza specyfikacja ACPI 5.0, z którą zgodne są już płyty główne wielu nowych laptopów, wprowadza m.in. tryb Connected Standby. Wykorzystuje on zupełnie odmienne od znanych z wcześniejszych wersji ACPI rozwiązania w zakresie zarządzania energią, by pozwolić komputerom osobistym na działanie w trybie bardzo niskiego zużycia energii, nie odłączając przy tym ich od sieci. Obecnie Connected Standby jest wspierane tylko przez Windows 8/8.1. Jego wprowadzenie na Linuksie wymagałoby ogromnego nakładu pracy, tymczasem wciąż, mimo prac ludzi Intela, wiele jest do zrobienia na Linuksie w bardziej podstawowych kwestiach związanych z ACPI 5.0

© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.