Co to jest kernel?

Ktoś kiedyś zapytał mnie, trzymając odnowioną maszynę, którą właśnie wydałem: „to co to właściwie jest ten Linux, który pan tu wgrał?". Zacząłem od uczciwej odpowiedzi — od kernela — i patrzyłem, jak wzrok rozmówcy mętnieje po jakichś czterech sekundach. To była moja wina, nie jego. Jeśli nie umiesz czegoś wytłumaczyć bez żargonu, jest spora szansa, że rozumiesz to gorzej, niż Ci się wydaje.

Poszedłem więc i znalazłem lepszą odpowiedź. Wzięła się z mojego pierwszego zawodu — jestem elektronikiem z wykształcenia, a elektronika ma dokładnie ten sam problem do rozwiązania. Masz komponenty, które wszystkie chcą używać tych samych przewodów w tym samym czasie, i coś musi decydować, kto mówi i kiedy. Tym czymś jest sterownik magistrali. Kernel jest tym samym dla komputera.

Kernel to nie program. To kontroler ruchu

Oto model myślowy, który sprawdza się u większości osób, którym to tłumaczyłem.

Twój komputer ma sprzęt — procesor, pamięć, dysk, kartę sieciową, ekran. Ma też programy — przeglądarkę, arkusz, odtwarzacz muzyki. Programy nie mają prawa rozmawiać ze sprzętem bezpośrednio. Gdyby miały, pierwszy źle napisany program zająłby całą pamięć, nadpisał dane innego programu albo przejął dysk i nigdy go nie oddał. Zamiast tego każde żądanie przechodzi przez jedną warstwę pośrodku, a tą warstwą jest kernel.

Otwierasz plik. Program nie sięga do dysku; pyta kernel, a kernel decyduje, czy ten program ma prawo czytać ten plik, i dopiero potem po niego idzie. Uruchamiasz aplikację. Kernel przydziela jej kawałek pamięci i udział w czasie procesora. Zamykasz ją. Kernel odbiera pamięć i sprząta po niej. Dwa programy chcą procesora naraz — kernel decyduje, kto idzie pierwszy i na jak długo, tysiące razy na sekundę, tak płynnie, że odbierasz to jako „działają jednocześnie", co jest wygodnym złudzeniem.

Wszystko, co uważasz za „system" — pulpit, okna, menu start, ustawienia — siedzi na tej warstwie i kernelem wcale nie jest. Dlatego ten sam kernel pracuje pod maszyną na Twoim biurku, telefonem w kieszeni, routerem w przedpokoju i serwerem w centrum danych. Kernel to ta część, która rozmawia ze sprzętem. To, co się na niej zbuduje, jest osobną decyzją.

Dlaczego ma to obchodzić kogoś spoza branży

Bo kernel jest miejscem, w którym ostatecznie ląduje każde pytanie o bezpieczeństwo. To komponent odpowiadający na pytanie „czy temu programowi wolno to zrobić?" — a jeśli odpowie źle, nic powyżej Cię nie uratuje. Twój antywirus, menedżer haseł i ostrożne nawyki siedzą na tej jednej warstwie decyzyjnej.

Kernel Windowsa wykonuje tę samą pracę i wykonuje ją kompetentnie — to nie jest porównanie jakości inżynierskiej i nie mam interesu w udawaniu, że jest. Różnica jest węższa i dla mnie rozstrzygająca: jeden z nich mogę przeczytać.

Źródło kernela Linuksa jest publiczne. Każdy może je pobrać, przeczytać i zobaczyć pełną historię tego, kto zmienił którą linijkę i dlaczego. Każda zmiana niesie nazwisko i uzasadnienie, a spory o te zmiany toczą się na publicznej liście dyskusyjnej, którą każdy może czytać. Nic w tym układzie nie jest uprzejme — rozwój kernela ma reputację szorstkiego — ale jest widoczne.

Powiem precyzyjnie, co to daje, a czego nie daje, bo przesadzenie byłoby nieuczciwe. Nie czytam źródeł kernela co rano; nikt tego nie robi. To dziesiątki milionów linii i żadna pojedyncza osoba nie rozumie ich w całości. Otwartość nie kupuje mojej osobistej czujności. Kupuje to, że tysiące ludzi o sprzecznych interesach — konkurujące korporacje, uczelnie, badacze bezpieczeństwa, nieufne wobec siebie rządy — patrzą na ten sam kod. Żadna z tych stron nie musi ufać pozostałym. Muszą tylko dalej patrzeć.

Co to zmienia w praktyce

Dwie rzeczy i obie są przyziemne, nie dramatyczne.

Pierwsza to długowieczność. Ponieważ kernel jest oddzielny od wszystkiego, co się na nim buduje, obsługa starego sprzętu zwykle zostaje na długo po tym, jak komercyjny producent by ją porzucił. Ktoś gdzieś wciąż używa tej karty sieciowej, więc kod, który nią steruje, zostaje. To jest techniczny powód, dla którego maszyna uznana przez jednego producenta za przestarzałą dalej dostaje aktualizacje bezpieczeństwa pod innym systemem. To nie dobroczynność. To konsekwencja tego, że nikt nie ma komercyjnego motywu, żeby usuwać działający kod.

Druga to diagnozowalność, która brzmi abstrakcyjnie do dnia, w którym jej potrzebujesz. Kiedy serwer zaczyna wariować o trzeciej nad ranem, użyteczne pytanie nie brzmi „do kogo dzwonić?", tylko „co on właściwie robi?". Na otwartym systemie mogę prześledzić ten wątek do samego dołu — od aplikacji, przez wywołania systemowe, które wykonuje, aż do własnych raportów kernela. Spędziłem tak niejedną noc. Odpowiedź bywa zawstydzająca i jest moja do znalezienia. Na zamkniętym systemie wątek kończy się na zgłoszeniu do wsparcia.

Jedno uczciwe zastrzeżenie, bo otwarty model ma realny koszt, a udawanie, że nie ma, to prosta droga do rozczarowania. Otwartość nie oznacza prostoty. Kiedy na Linuksie coś pójdzie nie tak, dostajesz całą prawdę, a cała prawda bywa przytłaczająca. Zamknięty system, który mówi „wystąpił błąd", jest dla wielu osób w wiele dni po prostu łaskawszy. Wartość przejrzystości ujawnia się wtedy, kiedy jej potrzebujesz, a nie wtedy, kiedy próbujesz wydrukować dokument.

Skąd biorą się aktualizacje

Jedna praktyczna konsekwencja tej struktury jest warta wyłożenia, bo stoi za obietnicą, którą składam, wydając maszynę: że ośmioletni komputer będzie dalej dostawał aktualizacje bezpieczeństwa.

Kernel jest rozwijany ciągle, a niektóre wersje zostają wyznaczone do długoterminowego utrzymania. Takie wersje przestają dostawać nowe funkcje i dostają wyłącznie poprawki, przez lata. Dystrybucja taka jak ta, którą instaluję, wybiera długoterminowy kernel i długoterminowy zestaw otaczającego oprogramowania, po czym zobowiązuje się łatać tę kombinację przez określony czas. Kiedy ten czas się kończy, przechodzisz na kolejne wydanie długoterminowe — na tym samym sprzęcie, bo to nie sprzęt stracił ważność.

Zwróć uwagę, czego w tym opisie nie ma: żadnej decyzji o generacji Twojego procesora. Kernel obsługuje sprzęt tak długo, jak długo ktoś utrzymuje kod, który nim steruje, a stary sprzęt jest utrzymywany, bo stary sprzęt wciąż pracuje, często w miejscach, których nie da się wymienić zgodnie z harmonogramem marketingowym — w urządzeniach przemysłowych, sprzęcie medycznym, infrastrukturze. Twoje biurko korzysta z decyzji podjętej dla fabryki.

Wersja krótka, dla osoby przy mojej ladzie

Kernel to warstwa między Twoimi programami a Twoim sprzętem. Decyduje, kto dostaje pamięć, kto dostaje procesor i komu wolno przeczytać który plik. To najbardziej krytyczny dla bezpieczeństwa komponent w maszynie i jednocześnie ta część, której nigdy nie widzisz.

Wybieram ten, którego źródło mogę otworzyć. Nie dlatego, że czytam je codziennie, i nie dlatego, że jest bezbłędne — nie jest, łatki bezpieczeństwa kernela wychodzą regularnie jak u wszystkich. Dlatego, że kiedy potrzebuję wiedzieć, co maszyna robi, odpowiedź istnieje w miejscu, do którego mam dostęp. To jest cały argument i jest mniejszy, niż ludzie zwykle oczekują.

Jeśli ufasz sercu maszyny, bo ktoś Ci kazał, to jest wiara. Jeśli ufasz mu, bo da się je zbadać, to jest inżynieria. Wolę to drugie i na tej preferencji buduję to, co sprzedaję.