Kernel space to uprzywilejowany obszar pamięci i wykonania, w którym działa jądro systemu operacyjnego z pełnym, niczym nieograniczonym dostępem do sprzętu: procesora, pamięci RAM, sterowników i urządzeń wejścia/wyjścia. To przeciwieństwo user space, czyli strefy, w której kręcą się zwykłe programy: przeglądarka, edytor kodu czy twój skrypt w Pythonie. Podział wymusza sam procesor, który pracuje w różnych poziomach uprawnień (na x86 to tzw. protection rings: jądro siedzi w ringu 0, aplikacje w ringu 3). Dzięki temu krzaczący się program nie pociąga za sobą całego systemu.
Jak to działa
Kod w kernel space może wszystko: czytać i zapisywać dowolny adres pamięci, rozmawiać bezpośrednio z dyskiem czy kartą sieciową, obsługiwać przerwania sprzętowe. Kod w user space jest celowo trzymany na smyczy — nie ma prawa dotknąć sprzętu ani cudzej pamięci. Gdy twój program potrzebuje czegoś „od systemu” (otworzyć plik, wysłać pakiet, zaalokować pamięć), wykonuje syscall — kontrolowane przejście do kernel space. Procesor przełącza tryb, jądro robi robotę, sprawdza uprawnienia i oddaje wynik. To przełączanie kosztuje, dlatego wydajne aplikacje starają się minimalizować liczbę syscalli.
Granica user/kernel to też granica bezpieczeństwa. Aplikacja nie może ot tak nadpisać struktur jądra, bo MMU (jednostka zarządzania pamięcią) pilnuje, kto gdzie ma wstęp. Naruszysz zasady — dostajesz segmentation fault i tyle.
Przykład z praktyki
Chcesz zobaczyć, ile czasu twój program spędza w user space, a ile w kernel space? Odpal strace -c ./twoj_program — zobaczysz, które syscalle wołasz i jak często. A klasyczny time ./twoj_program rozbije czas na user i sys (czyli właśnie czas w jądrze). Jeśli sys jest podejrzanie wysoki, prawdopodobnie zarzynasz system milionem drobnych odczytów zamiast buforować.
Częste mity
- „Sterowniki zawsze działają w kernel space”. Niekoniecznie. Istnieją sterowniki w user space (np. przez framework
FUSEdla systemów plików czyuio), co ogranicza skutki awarii. - „Crash w user space położy system”. Nie — od tego jest izolacja. Za to panika w kernel space (kernel panic, a na Windowsie BSOD) potrafi zatrzymać całą maszynę.
- „Im więcej kodu w jądrze, tym szybciej”. Bywa odwrotnie — błąd w kernel space ma dostęp do wszystkiego, więc to też większa powierzchnia ataku.
Pojęcia powiązane, które warto ogarnąć obok: user space, syscall, protection rings, kernel panic, context switch, jądro monolityczne kontra mikrojądro oraz MMU.