Intel, DRM i mostek północny — to całkiem proste

Szanowni Państwo, przerywamy transmisję, aby odkryć rzecz oczywistą: czego człowiek nie wie, to sobie dopowie. I zmyśli rzecz tak nieprawdopodobną, że osoba choć odrobinę w temacie zorientowana osiwieje. Jest ku temu komunikatowi okazja, bo wczoraj (no, już przedwczoraj) na DP pojawił się tekst Komputery z procesorami Intela są kontrolowane przez… Intela, który takie przyspieszone starzenie u mnie wywołał.

Sprawa, którą tekst porusza, jest stosunkowo prosta: pojawił się wpis blogowy (swoją drogą w aktualności nie podlinkowany!), który bardzo szczegółowo opisuje dlaczego czasem zrobienie zrzutu ekranu z odtwarzanego na komputerze filmu nie jest możliwe. Kluczowe jest tutaj określenie "bardzo szczegółowo", bo przeważnie powody są prozaiczne (o czym za chwilę), ale autor z kronikarską skrupulatnością opisuje także przypadki brzegowe i podaje wartościową bibliografię dla zainteresowanych tematem.

I chwała mu za to, to kawał dobrej lektury. Łukasz był najwyraźniej tematem zainteresowany, ale niestety nie zrozumiał problemu. Postaram się w związku z tym prześledzić wszystkie wątki: od zrzucania ekranu, przez zdalną kontrolę, po sztuczną mgłę i brzozę.

Jak działa dekodowanie wideo?

To zależy, czy komputer posiada sprzętowy dekoder wideo. Ale odpowiedź na to pytanie przeważnie brzmi: tak. Wiele nowoczesnych urządzeń (szczególnie mobilnych) zdaje się na dedykowany, sprzętowy dekoder. Ma to spore zalety, na czele których wysuwa się oszczędność energii (tak ważna w telefonach i tabletach).

Jak to działa w praktyce? Gdzieś w urządzeniu (np. w SoC w telefonie) obok CPU i GPU znajduje się VPU, które samodzielnie przetwarza strumień danych (np. h.264) i tworzy na bazie strumienia poszczególne ramki obrazu. Te ramki to nic innego jak spore obrazki (kto nie lubi FullHD?), które należy wyświetlić na ekranie: najlepiej szybko i zużywając niewiele energii.

Zdradzę Wam przy okazji tajemnicę: kopiowanie danych (czyli transfer danych po szynie) jest bardzo energochłonny. Bardziej nawet niż byłoby dekodowanie filmu na CPU, do kosztów dekodowania w dedykowanym sprzęcie nie mamy zatem nawet czego porównywać. Optymalnym rozwiązaniem jest wobec tego, żeby dane te pojawiły się od razu w buforze ekranowym, z którego wyświetlacz bezpośrednio czyta.

Takie myślenie doprowadziło do mechanizmu o nazwie video overlay. Ovelay, jak nazwa sugeruje, przesłania pewien obszar czegoś innego. W tym wypadku bufora ekranowego w którym inne podsystemy (np. kompozytor UI systemu operacyjnego) wyświetlają coś.

Na pewno większość z czytelników doświadczyła kiedyś dziwnego efektu, w którym obraz wideo opóźniony jest względem reszty obrazu przy przesuwaniu okna programu, który wideo wyświetla. W miejscu, w którym powinien znajdować się film, przez chwilę jest czarna "pustka", wideo opóźnione jest o klatkę czy dwie i stoi w poprzednim miejscu, po czym doskakuje tam, gdzie chcielibyśmy je widzieć. Brzmi znajomo?

To właśnie overlay (w połączeniu z kiepską implementacją w sterowniku i starym Windowsem). W miejscu, w którym ma być wideo, kompozytor systemu operacyjnego (który działa na CPU albo na GPU) nie wyświetla nic. Jednocześnie z innego źródła - VPU - w to puste miejsce trafia zdekodowana ramka animacji. Rzecz w tym, że te dane mają dotrzeć szybko i tanio (w sensie zużycia energii), więc nigdy nie są kopiowane w puste miejsce, a zamiast tego kawałek krzemu odpowiedzialny za wysyłanie sygnału do wyświetlacza (czy to LCD w telefonie, czy też monitora na kablu) miesza dane z dwóch źródeł na żywo.

Jako że te dane nigdy nie trafiają ani do pamięci CPU, ani do pamięci GPU, nasz system operacyjny nie ma do nich dostępu. A jak nie ma do nich dostępu, to nie można ich złapać przy próbie zrobienia zrzutu ekranowego! Bo zrzut ekranowy nie czyta tego, co widzi nasz ekran, tylko to, do czego dostęp ma procesor albo układ graficzny.

Dla wygody użytkowników, systemy operacyjne mogą dodatkowo kopiować te niewidoczne dane do pamięci CPU, dzięki czemu możemy zapisać ulubione fragmenty seriali, twarze ukochanych aktorów i najlepsze ujęcia z filmów dla dorosłych. Chyba, że nie możemy.

Protected Audio/Video Path

Żeby takie kopiowanie mogło mieć miejsce, potrzebna jest współpraca systemu operacyjnego, sterownika GPU i sterownika VPU (w przypadku Windowsa oba sterowniki najczęściej są ze sobą mocno związane). Ale skoro można to kontrolować, to na bazie tego mechanizmu możliwe jest zaimplementowanie DRMu. Wystarczy, że treść oznaczona jest jako wrażliwa, a mechanizm dostępu do zdekodowanych klatek filmu może być zablokowany. Napęd Blu‑ray będzie w związku z tym informował system, że strumień danych, który trafia do VPU, nie powinien być przechwytywany. I nie będzie.

Drobna dygresja. Nie jestem fanem DRMu. Może nie ideowo, bo widzę sensowne dla niego zastosowania. Ale zarówno sposób, w jaki jest wykorzystywany jak i konkretne implementacje są najzwyczajniej w świecie słabe. Najczęściej też przeszkadzają bardziej legalnym użytkownikom, niż piratom. Pisałem o tym wiele lat temu, pisał o tym też Tomek.

Niestety moje preferencje nie mają większego znaczenia, bo dostawcy treści mają konkretne wymagania. Jednym z nich jest zabezpieczenie filmów przed jakimkolwiek przechwytywaniem. Dlatego istnieją realizujące to w systemie operacyjnym mechanizmy i dlatego sprzęt i sterowniki wspierają te wymagania. Jest to też jedyny powód dla którego jeszcze ktokolwiek pamięta o Silverlight: implementacja ścieżki bezpiecznej treści we Flashu jest żenująco kiepska. Bez obaw miłośnicy DRMu, powstają już nowe rozwiązania - eimi opisał je jakiś czas temu.

Ale Intel zmienia coś w moich danych, jakoś, chyba

Do zrozumienia reszty układanki (i wydobycia szczątkowego sensu z tekstu Łukasza) warto wyjaśnić jeszcze jedną rzecz: sprzęt to trochę sprzętu i sporo oprogramowania. Kupując CPU nie zastanawiamy się szczególnie mocno nad tym, co się w środku dzieje. A wysokopoziomowy obraz jest dosyć interesujący.

Po pierwsze sam procesor może niewiele. Procesor czyta dane i instrukcje do wykonania z pamięci - inaczej się nie da. Pamięć ta jest gdzieś obok, ale okazuje się, że nie jest całkowitą własnością CPU. I tak jeśli mamy tzw. wbudowane GPU, to pamięć jest najpewniej współdzielona między tymi dwoma układami. Część urządzeń i portów może być widoczna w przestrzeni pamięci fizycznej, tzn. że jeśli zapisujemy pod jakiś adres, dane nigdy nie trafiają do kości pamięci i są przekierowywane w inne, odpowiednio dobrane miejsce (np. do kontrolera Ethernet).

Wbrew pozorom to całkiem skomplikowana praca, bo potrzebujemy do tego jakiegoś kawałka sprzętu, który nie tylko dokonuje arbitrażu na szynie danych (teraz te dane zapisuje X, po nim odczytuje je Y, a reguły read-after-write są takie to, a takie...), ale też musi to robić w sposób konfigurowalny (urządzenia się pojawiają i znikają) oraz szybki (nie chcemy przecież, by nasza super wydajna pamięć się marnowała). Jak można się domyślać stworzenie sprzętu, który realizuje to doskonale, nie jest proste.

Zadanie to, tak w ogóle, realizuje mostek północny (north bridge) lub jego odpowiednik w różnych nowoczesnych systemach komputerowych. Żeby realizować je dobrze i żeby - w razie wpadek - dało się go naprawić, mostek północny jest kawałkiem wyspecjalizowanego krzemu przyspawanym do mikrokontrolera, czyli malutkiego procesora ogólnego przeznaczenia. Tak, mostek północny ma własne CPU i to CPU wykonuje jakiś kod.

Ale to nie koniec magii: CPU też ma wbudowane CPU, bo instrukcje danej ISA (np. x86) są tłumaczone na mikroinstrukcje odpowiadające architekturze właściwej sprzętu (np. Nehalem), a błędy tłumaczenia można łatać instalując nową wersję dekodera. Nie inaczej jest z GPU, VPU, kontrolerem WiFi, Ethernet i każdym innym wyspecjalizowanym układem w waszym komputerze. Wszystkie one mają, lub mogą mieć malutkie wbudowane CPU, które robi coś.

Przeważnie mówimy, że dany układ ma własny firmware i nie zastanawiamy się zbyt mocno co to w praktyce oznacza. A to nie oznacza wcale, że mamy jakieś pokrętła i przełączniki; to znaczy, że w dany układ wbudowany jest na stałe lub ładowany jest przez BIOS albo sterownik program, który pozwala temu układowi w ogóle funkcjonować. Te urządzenia bez firmware'u nie zrobią nic.

W większość mostków północnych Intela wbudowany jest mikrokontroler ARC. Intel nie stworzył póki co malutkich układów dedykowanych tego typu rozwiązaniom, więc najłatwiej było im licencjonować istniejące, sprawdzone IP. Tak samo robią producenci telefonów licencjonując ARMa albo producenci routerów WiFi licencjonując MIPSa. Z racji funkcji realizowanych przez mostek północny, ten ARC ma całkiem spore możliwości. W końcu dokonuje arbitrażu wszystkich danych, więc może je nie tylko odczytywać, ale i zmieniać (lub ich transfer całkowicie blokować).

Podstawą każdego bezpiecznego systemu (w sensie: DRMu) jest wsparcie sprzętowe. Przy analizie bezpieczeństwa mówi się o chain of trust, łańcuchu zaufania, który jest tak silny, jak najsłabsze jego ogniwo. Żeby ten łańcuch faktycznie cokolwiek zabezpieczał, musi mieć oba końce mocno do czegoś przytwierdzone. To mocowanie to właśnie wsparcie sprzętowe.

W opisanym wcześniej scenariuszu system operacyjny i sterownik muszą ze sobą uzgodnić, że jakaś treść jest wrażliwa. Ale ogólna zasada jest taka, że jeśli coś jest w sofcie, to inny soft to może zmienić. Potrzeba wobec tego silnego wsparcia sprzętowego. Po jednej ze stron funkcję tę spełnia właśnie mostek północny (przynajmniej w przypadku sprzętu Intela). Nie powinno to być dla nikogo nowością, a szczególnie nie dla redaktora, który ten temat porusza. Najwyraźniej jednak było to dla niego novum.

To Intel nie kontroluje naszych komputerów?

Nie, kontrolują je administratorzy Waszych sieci. Słyszeliście kiedyś o funkcji Wakeup-on-LAN (WoL)? Wasza karta sieciowa może pozwolić na zdalne uruchomienie wyłączonego komputera. Jak by na to nie patrzeć, to zdalna kontrola Waszego sprzętu. Tylko że szalenia wygodna, jeśli z jakiegoś powodu chcielibyśmy się SSHować do swojego komputera, który akurat przypadkiem jest uśpiony. Funkcja ta (jak i wiele innych) ma jednak przede wszystkim znaczenie w środowisku biznesowym.

Bo administratorzy dużych sieci potrzebują zdalnych mechanizmów na masowe zmiany w komputerach użytkowników. Antywirus wymaga aktualizacji, Windowsa trzeba załatać, a do tego zmieniły się adresy udziałów sieciowych, które wszyscy pracownicy mapują? Realizowanie tego komputer po komputerze, ręcznie, zajęłoby wieki. Zdalne zarządzanie komputerami jest kluczowe w takich środowiskach.

Czasem jednak administratorzy chcieliby wpłynąć na coś poniżej systemu operacyjnego (szczególnie kiedy OS przestał w ogóle odpowiadać). Typowym scenariuszem jest zdalna inspekcja konfiguracji sprzętowych, by odpowiedzieć na pytanie "kto ma dostać nową stację roboczą?" - i do tego właśnie służy Active Management Technology. AMT jest dosyć potężnym mechanizmem, bo pozwala m.in. na komunikację z BIOSem (w którym też najczęściej można AMT wyłączyć). I, ponownie, z racji uprzywilejowania mostka północnego można jego programowalne aspekty wykorzystać do bardzo ciekawych operacji.

Ale nie dajmy się zwariować, administratorzy nie są Waszymi wrogami (pozdrawiam Docenta!) i nie będą Was w ten sposób prześladować. Tego typu rozbudowany mechanizm stanowi jednakże poważny wektor ataku dla napastników. Czary-mary, które mostek północny może robić są w stanie przetrwać reinstalację systemu operacyjnego i wymianę BIOSu, więc w nieodpowiednich rękach mogą być bardzo niebezpieczne.

Dlatego niezwykle ważne są badania Tereshkina, Wojtczuka czy Skochinskiego w zakresie możliwych ataków na AMT. Ale równie istotne jest, żeby dziennikarz rozumiał temat o którym pisze i nie generował masowej histerii swoją niekompetencją. Szczególnie, jeśli taki bzdurny tekst znajduje posłuch na Wykopie. ;)