Moduły-Kernela on Morfitronik

Zablokowanie możliwości ładowania modułów kernela na Debian linux

Mikhail Morfikov — Tue, 13 Dec 2022 13:03:00 +0100

Kernele oferowane przez różne dystrybucje linux'a, np. Debian czy Ubuntu, są tak budowane by możliwie jak największa ilość sprzętu na takim jądrze operacyjnym nam zadziałała bez zbędnego przerabiania systemu. Takie podejście sprawia, że nowo nabyty przez nas sprzęt możemy od razu podłączyć do komputera, a stosowne moduły po rozpoznaniu urządzenia zostaną załadowane do pamięci operacyjnej, przez co my będziemy mogli wejść w interakcję z takim kawałkiem elektroniki. Problem w tym, że kernel ma bardzo dużo tych modłów. Dużo modułów, to więcej kodu, a więcej kodu to więcej błędów, które na poziomie jądra mogą być bardzo opłakane w skutkach. Z zagrożeniem, jakie niosą moduły zewnętrzne (te spoza drzewa kernela linux), można sobie poradzić podpisując kernel kluczami od firmware EFI/UEFI. W takim przypadku załadowanie niepodpisanego modułu już się nie powiedzie. Niemniej jednak, dystrybucyjne kernele mają całą masę modułów do różnorakiego sprzętu, które na etapie budowania kernela są podpisywane, co otwiera im drogę do bycia załadowanymi w naszym systemie nawet jeśli nie posiadamy urządzeń, które by użytek z tych modułów robiły. Przydałoby się zatem zabezpieczyć możliwość ładowania modułów kernela w taki sposób, by jedynie administrator systemu miał możliwość określenia jakie moduły i na którym etapie pracy systemu mogą one zostać załadowane.

Chroot do 32-bit systemu ARM z poziomu 64-bit linux'owego hosta

Mikhail Morfikov — Sun, 07 Nov 2021 10:20:00 +0100

Eksperymentując ostatnio z moją maszynką Raspberry Pi 4B, zaszła potrzeba, by zejść do systemu RasPiOS/Raspbian przy pomocy mechanizmu chroot. Problem w tym, że system wyrzuca komunikat: chroot: failed to run command ‘/bin/bash’: Exec format error . Niby wszystko jest na swoim miejscu ale ta widoczna wyżej wiadomość nie chce zniknąć uniemożliwiając tym samym dalszą zabawę z RPI. Okazało się, że winna jest tutaj architektura CPU. Mój laptop działa pod kontrolą 64-bitowego Intel'owskiego procesora (x64, x86-64, AMD64), na którym uruchomiony jest również 64-bitowy Debian linux. Z kolei Raspberry Pi ma 64-bitowy procesor ARM (ARMv8-A) działający pod kontrolą 32-bitowego systemu operacyjnego. Te dość spore rozbieżności sprawiają, że nie damy rady skorzystać z chroot, przynajmniej nie bez zaprzęgnięcia do tego celu emulatora QEMU.

Czym jest linux kernel driver binding

Mikhail Morfikov — Tue, 28 Jul 2020 19:39:00 +0000

Bawiąc się ostatnio QEMU/KVM na swoim laptopie z zainstalowanym Debianem natrafiłem na ciekawe zagadnienie związane z wirtualizacją, tj. z PCI passthrough. Nie chodzi mi tutaj o samą technikę PCI passthrough ale o dobór sterowników do urządzeń działających pod kontrolą linux. Każdy sprzęt, który ma działać w systemie, musi mieć załadowany w pamięci RAM stosowny moduł kernela. Te moduły zwykle są ładowane automatycznie podczas pracy systemu, np. gdy podłączamy nowy sprzęt do komputera (można też te moduły ładować i ręcznie via modprobe ). Gdy nasz linux z jakiegoś powodu dobierze niewłaściwy (z naszego punktu widzenia) moduł dla jakiegoś urządzenia, to możemy to urządzenie odłączyć od komputera, a moduł bez problemu wyładować, po czym dokonać stosownych poprawek w systemie. Problem zaczyna się w sytuacji, gdy mamy do czynienia ze sprzętem, którego nie da się od komputera fizycznie odłączyć, np. wbudowana w płytę główną karta dźwiękowa, czy też wbudowana grafika bezpośrednio w CPU. Podobnie sprawa wygląda w przypadku wkompilowania modułów na stałe w kernel -- jak wyładować moduł, którego się nie da wyładować? By w takich sytuacjach zmienić przypisany urządzeniu sterownik trzeba dodać parę plików w katalogach /etc/modules-load.d/ / /etc/modprobe.d/ oraz zrestartować maszynę, tak by podczas fazy boot kernel dobrał sprzętowi pożądane przez nas moduły i ich konfigurację. Niemniej jednak, istnieje prostszy sposób na zmianę sterownika działającego w systemie sprzętu i to bez potrzeby fizycznego restartowania maszyny. Chodzi o mechanizm ręcznego przypisywania urządzeń do konkretnych sterowników (manual driver binding and unbinding).

Moduł LKRG (Linux Kernel Runtime Guard)

Mikhail Morfikov — Tue, 09 Jun 2020 20:56:00 +0000

Jakiś czas temu opisywałem moduł TPE (Trusted Path Execution) dla kernela linux, który jest w stanie dość znacznie poprawić bezpieczeństwo naszego systemu. Ostatnio jednak natknąłem się na moduł LKRG (Linux Kernel Runtime Guard), którego to zadaniem jest stać na straży samego jądra operacyjnego i chronić je w czasie rzeczywistym przed różnego rodzaju zagrożeniami poprzez wykrywanie eksploitów wykorzystujących luki w jego mechanizmach bezpieczeństwa. Jako, że ja bardzo lubię zbroić swojego Debiana, to postanowiłem się przyjrzeć nieco bliżej temu całemu LKRG i sprawdzić jego użyteczność. Trzeba jednak wiedzieć, że LKRG jest dostarczany w formie osobnego modułu zamiast łaty na kernel, przez co trzeba będzie także postarać się o automatyzację pewnych rzeczy, m.in. procesu budowania modułu przy aktualizacji kernela via DKMS.

Moduł TPE (Trusted Path Execution) dla kernela linux

Mikhail Morfikov — Fri, 22 Mar 2019 20:10:11 +0000

Użytkownicy linux'a są zwykle chronieni przez mechanizmy bezpieczeństwa, które ten system jest w stanie zaoferować. Oczywiście deweloperzy różnych dystrybucji, np. Debiana, dokładają wszelkich możliwych starań, by system jako całość był wstępnie skonfigurowany tak, by końcowy użytkownik nie musiał za wiele majstrować przy zabezpieczeniach i mógł się czuć i być (przynajmniej względnie) bezpieczny. No i faktycznie złowrogie oprogramowanie ma czasem spore problemy dostać się do maszyny, którą operuje linux. Niemniej jednak, gdy już taki syf się do systemu dostanie, to zwykle niewiele dzieli go od przejęcia kontroli nad komputerem. Może i część zabezpieczeń linux'a zadziała i sprawi, że taki wirus/trojan czy nawet zwykły skrypt będzie miał ograniczone pole manewru, to i tak będzie on mógł przeprowadzić te akcje, które zwyczajny użytkownik systemu (nie root) jest zwykle w stanie poczynić, np. odebrać dźwięk i video ze stosownych urządzeń i przesłać te dane przez sieć. My z kolei możemy nawet tego faktu nie być świadomi. Jasne, że powinno się zwracać uwagę na to jakie pliki się pobiera z internetu i nie uruchamiać wszystkiego lekkomyślnie ale też trzeba mieć na uwadze fakt, że często jedna maszyna jest współdzielona, np. z członkami rodziny i oni już niekoniecznie muszą władać zaawansowaną wiedza z zakresu IT, by przewidzieć wszystkie możliwe zagrożenia czyhające na nich w sieci. Można za to postarać się, by uczynić naszą maszynę nieco bardziej odporną na niezbyt przemyślane zachowania użytkowników jej systemu operacyjnego. Jednym z kroków, które możemy podjąć, jest wdrożenie mechanizmu Trusted Path Execution (TPE), który póki co jest dostępny jedynie w formie patch'a na kernel linux'a lub też jako jego osobny moduł oferujący sporo więcej możliwości w stosunku do wspomnianej wcześniej łaty. W niniejszym artykule rzucimy sobie okiem na ten cały mechanizm TPE i zobaczymy jak jest on w stanie uchronić nasz OS przed niezbyt zaawansowaną ludzką inteligencją.

Jak ręcznie zweryfikować sygnaturę modułu kernela linux

Mikhail Morfikov — Sat, 26 Jan 2019 10:10:12 +0000

Bawiąc się ostatnio kernelem linux na dystrybucji Debian i opcjami mającymi poprawić jego bezpieczeństwo, włączyłem sobie mechanizm podpisywania modułów. W ten sposób żaden zewnętrzny moduł nie zostanie załadowany przez jądro operacyjne, no chyba, że taki moduł będzie podpisany przez ten sam klucz co i kernel. Zdziwiłem się odrobinę, gdy moim oczom pokazał się hash md4 w wyjściu polecenia modinfo . Jak się okazało później, to niezbyt dokładne zinterpretowanie wiadomości PKCS#7 przez kmod było (i nadal jest) wynikiem błędu obecnego w tym pakiecie od już paru lat. W efekcie modinfo nie jest w stanie zweryfikować tej sygnatury, a w moim umyśle zaistniało pytanie: czy istnieje w ogóle możliwość manualnego sprawdzenia czy ta sygnatura jest w porządku? Kernel co prawda ten cały zabieg przeprowadza automatycznie ale przydałoby się ręcznie zweryfikować poprawność sygnatury modułu i przy okazji obadać sobie co tak naprawdę się dzieje podczas tego procesu.

Automatyczne podpisywanie modułów kernela przez DKMS

Mikhail Morfikov — Sat, 05 Jan 2019 04:10:10 +0000

Budując kernel linux'a trzeba zastanowić się nad kwestią modułów, które nie są wbudowane bezpośrednio w samo jądro operacyjne. Nie chodzi tutaj bezpośrednio o funkcjonalność kernela, którą można zbudować jako moduł w procesie jego kompilacji ale raczej o wszystkie zewnętrzne moduły, które przez zespół kernela są traktowane jako out-of-tree . By poprawić nieco bezpieczeństwo związane z takimi modułami, można wdrożyć podpisy cyfrowe, które takie moduły muszą okazać podczas próby załadowania ich w systemie. Gdy moduł nie został podpisany, to kernel go nie załaduje zwracając przy tym błąd modprobe: ERROR: could not insert 'module': Required key not available . W ten sposób można ochronić się przed częścią ataków, w których moduły pochodzenia trzeciego mogą zostać załadowane i poczynić nam ogromne spustoszenie w systemie. Problem w tym, że w dystrybucji Debian wykorzystywany jest mechanizm DKMS (Dynamic Kernel Module Support). Może i mamy dzięki niemu możliwość instalacji w systemie całej masy dodatkowych modułów ale ich również nie będzie można załadować, bo nie zostały podpisane kluczem, którego certyfikat został zaszyty w kernelu. Można jednak zmusić mechanizm DKMS, by wskazane przez nas moduły podpisywał automatycznie przy ich instalacji i aktualizacji.

Sterowniki dla karty WiFi Archer T1U (mt7610u_sta)

Mikhail Morfikov — Thu, 18 Aug 2016 14:35:52 +0000

Dziś postanowiłem się wziąć za ostatnią kartę WiFi, którą podesłał mi TP-LINK. Jest to nano adapter Archer T1U V1 na czipie MediaTek MT7610U identyfikowany w systemie jako idVendor=2357 , idProduct=0105 . Na opakowaniu pisało, że ta karta działa na linux'ach ale oczywiście w przypadku mojego Debiana, ten adapter nie został w ogóle wykryty. Winą są zbyt stare sterowniki, które nie zostały zaktualizowane przez MediaTek od 2013 roku. TP-Link może i ma u siebie na stronie nieco nowszą wersję sterowników, bo z 2015 roku ale nie udało mi się za ich sprawą zbudować poprawnie modułu mt7610u_sta na kernelu 4.6 . Na szczęście mamy jedną alternatywę, która pomoże nam jako tako wybrnąć z tej sytuacji.

Sterowniki do karty TP-LINK TL-WN823N (8192eu)

Mikhail Morfikov — Fri, 12 Aug 2016 20:50:39 +0000

Systemy operacyjne nie są w stanie wejść w interakcję ze sprzętem, do którego nie posiadają sterowników. Linux już od dość dawna żyje sobie wśród nas i coraz bardziej pcha się na desktopy. Niemniej jednak producenci tych wszystkich urządzeń niechętnie wypuszczają sterowniki dla alternatywnych systemów. Ostatnio próbowałem uruchomić adapter TL-WN823N V2 od firmy TP-LINK. Na opakowaniu widnieje napis sugerujący, że ta karta działa pod linux'em. Rzeczywistość jednak okazała się zupełnie inna. Mianowicie, mój Debian w ogóle nie rozpoznał tej karty. Jedyne informacje jakie mi zwrócił to nazwę producenta czipu, którym okazał się być Realtek , oraz idVendor=2357 i idProduct=0109 . Sterowników dostępnych na stronie TP-LINK'a nie szło zbudować na obecnym kernelu 4.6 . Trzeba było zatem poszukać innej alternatywy. Na szczęście udało się znaleźć moduł 8192eu (rtl8192eu), który się skompilował i zainstalował bez problemu. Karta TL-WN823N V2 została wykryta i działa. W tym wpisie zostanie pokazany proces kompilacji tego modułu.

Jak wyłączyć systemowy "beep"

Mikhail Morfikov — Mon, 25 Jan 2016 21:56:20 +0000

Zgodnie z tym co można wyczytać na wiki Archlinux'a, mamy kilka źródeł generowania dźwięków, które trafiają do wbudowanego głośnika naszego komputera (case speaker). Te dźwięki określane mianem "beep" mogą powstać za sprawą BIOS'u płyty głównej, systemu operacyjnego, środowiska graficznego lub też różnych programów użytkowych. Najbardziej uporczywe są dźwięki generowane przez BIOS. Na dobrą sprawę, jeśli w BIOS'ie nie ma żadnych opcji dotyczących konfiguracji tego głośnika, to raczej niewiele jesteśmy w stanie zrobić w tej kwestii. Możemy zawsze ten głośnik odłączyć fizycznie. Choć nie jest to zalecane, bo na podstawie wydawanych przez niego dźwięków, jesteśmy w stanie określić czy z naszym komputerem jest wszystko w porządku. Niemniej jednak, w tych pozostałych trzech w/w punkach mamy większe pole manewru, gdzie możemy dostosować sobie szereg parametrów i o tym właśnie będzie ten wpis.

Jak skonfigurować bonding w Debian linux (eth0+wlan0)

Mikhail Morfikov — Sat, 02 Jan 2016 15:07:13 +0000

W artykule poświęconym konfiguracji sieci WiFi na Debianie z wykorzystaniem narzędzia wpa_supplicant wspomniałem parę słów na temat interfejsu bond. Bonding na linux wykorzystywany jest w zasadzie do spięcia kilku interfejsów sieciowych, w tym przewodowych ( eth0 ) i bezprzewodowych ( wlan0 ) w jeden (zwykle bond0 ). Takie rozwiązanie sprawia, że w przypadku awarii któregoś z podpiętych interfejsów, my nie tracimy połączenia z siecią i nie musimy nic nigdzie przełączać, by to połączenie przywrócić. To rozwiązanie jest o tyle użyteczne, że w przypadku, gdy podepniemy przewód do gniazda RJ-45 w naszym laptopie, to komunikacja będzie odbywać się po kablu. Natomiast jeśli przewód zostanie odłączony, to system automatycznie przejdzie na komunikację bezprzewodową. W tym wpisie spróbujemy zaprojektować sobie właśnie tego typu mechanizm zarówno za sprawą pakietu ifupdown , gdzie konfiguracja interfejsów sieciowych jest zarządzana przez plik /etc/network/interfaces , jak i przy pomocy natywnego rozwiązania jakie oferuje systemd/networkd.

Konfiguracja interfejsów IFB w linux'ie

Mikhail Morfikov — Wed, 16 Dec 2015 14:46:50 +0000

Ten wpis również będzie poświęcony tematyce kontroli i kształtowania ruchu sieciowego w linux'ie, z tym, że ograniczymy się tutaj do konfiguracji interfejsów IFB. Działają one na podobnej zasadzie co interfejsy IMQ. Niewątpliwą zaletą interfejsów IFB jest fakt, że są one natywnie wspierane przez kernel linux'a, przez co ich obsługa jest dziecinnie prosta. Wadą jest z kolei to, że nie do końca damy radę kształtować ruch przychodzący do naszej maszyny. Tak czy inaczej, postaramy się skonfigurować te interfejsy i zobaczymy co z nich idzie wycisnąć.

Konfiguracja interfejsów IMQ w linux'ie

Mikhail Morfikov — Tue, 15 Dec 2015 14:38:30 +0000

W linux'ie, kształtowanie przychodzącego ruchu sieciowego stwarza dość poważne problemy. Na dobrą sprawę, obecnie w kernelu nie ma żadnego mechanizmu, który byłby w stanie to zadanie realizować. Istnieją, co prawda, interfejsy IFB ale za ich pomocą jesteśmy w stanie z powodzeniem kształtować jedynie ruch wychodzący. W przypadku pakietów napływających, możemy jedynie ograniczyć im przepustowość. W tym powyższym linku jest wzmianka, że te interfejsy IFB są następcą interfejsów IMQ. Niemniej jednak, ten drugi projekt zdaje się działać, choć nie jest obecnie wspierany przez kernel linux'a. W tym wpisie postaramy się skonfigurować działające interfejsy IMQ, tak, by za ich pomocą skutecznie kształtować ruch przychodzący.

Moduł kernela i wartości jego parametrów

Mikhail Morfikov — Fri, 23 Oct 2015 19:35:57 +0000

Raczej na pewno spotkaliśmy się już z modułami kernela w linux'ie. Generalnie rzecz biorąc, taki moduł może być ładowany dynamicznie i w sporej części przypadków niezależnie, choć z zwykle jest pociągany przy zdarzeniach udev'a. Czasem jednak, dany moduł nie działa jak należy i może to być wynikiem, np. problemów w samym module, lub też jego niewłaściwej konfiguracji, która konfliktuje z podzespołami naszego komputera. Ten wpis będzie dotyczył tego jak ustalić parametry modułów i ich domyślne wartości, tak by móc je sobie zmienić w późniejszym czasie.

Karta dźwiękowa w trybie powersave

Mikhail Morfikov — Tue, 06 Oct 2015 10:47:38 +0000

Kilka dni temu, na forum DUG'a, jeden z użytkowników miał problem z dźwiękiem. Udało się tę niedogodność wprawdzie poprawić ale został tam poruszony temat trybu powersave, czyli oszczędzania energii, jaki może posiadać karta dźwiękowa. Na dobrą sprawę, nigdy mi nawet do głowy nie przyszło, by te karty mogły przełączać sobie stan i zjadać mniej prądu, tak jak to robią, np. karty WiFi. Oczywiście, postanowiłem zgłębić to zagadnienie i ustalić na ile przydatna jest ta funkcja i czy da radę bez problemów słuchać muzyki lub oglądać filmy po jej aktywowaniu.

Aplikowanie zmiennych sysctl przy pomocy udev'a

Mikhail Morfikov — Sun, 06 Sep 2015 11:08:42 +0000

Kernele linux'owe mają dość sporo opcji, które możemy zmienić przy pomocy pliku /etc/sysctl.conf . Niby nic nadzwyczajnego ale co w przypadku tych zmiennych, które muszą być ustawione, z tym, że moduł, który stworzy odpowiednie ścieżki w katalogu /proc/sys/ , nie został załadowany z jakichś względów przy starcie systemu? Zmienne te nie zostaną ustawione, a w logu pojawi się komunikat informujący nas o nieodnalezieniu określonego pliku. Okazuje się, że jesteśmy w stanie aplikować określone ustawienia sysctl w momencie ładowania określonych modułów i temu mechanizmowi się przyjrzymy bliżej w tym wpisie.

Autosuspend i zasilanie portów USB na linux

Mikhail Morfikov — Tue, 23 Jun 2015 15:34:50 +0000

Kernel w linux'ie odcina zasilanie urządzeniom podpiętym do portów USB jeśli sterownik wspiera tego typu możliwość oraz samo urządzenie nie jest używane przez pewien okres czasu. W taki oto sposób, jeśli podłączymy, np. zewnętrzną klawiaturę USB do laptopa, możemy zaobserwować, że przy pisaniu tekstu gubiony jest zwykle pierwszy znak. Może i klawiatura po przyciśnięciu klawisza wyszła ze stanu bezczynności ale system nie zareagował na tyle szybko by złapać sygnał przycisku. Na necie ludzie piszą, że jest to problem niekompatybilności urządzeń i tego typu sytuacja nie powinna się zdarzać. Jeśli jednak natrafiliśmy na klawiaturę czy myszę, która cierpi z powodu automatycznego zawieszania jej zasilania, możemy wyłączyć ten ficzer zupełnie.

Sterowniki do karty TP-LINK Archer T4U (8812au)

Mikhail Morfikov — Tue, 23 Jun 2015 11:45:07 +0000

Póki co, w kernelu linux'a (4.5) nie ma odpowiednich sterowników do adaptera WiFi Archer T4U i trzeba je sobie skompilować ręcznie. Trochę to dziwne, bo przecie kod sterownika jest na licencji GPLv2 i dostępny już szmat czasu na github'ie. W każdym razie, jeśli zakupiliśmy w/w kartę i nie jest ona wykrywana po wsadzeniu jej do portu USB, to czeka nas proces kompilacji modułu 8812au i jego automatyzacja przy pomocy mechanizmu DKMS.

Obsługa wielu partycji w module loop

Mikhail Morfikov — Sun, 14 Jun 2015 16:37:34 +0000

Wszelkie obrazy .iso płyt cd/dvd czy nawet pliki .img zawierające strukturę obrazów live możemy zamontować lokalnie na komputerze uzyskując tym samym dostęp do ich systemu plików. W większości przypadków, każdy taki obraz zawiera tylko jedną partycję, czasem lekko przesuniętą względem początku ale generalnie nie ma większych problemów z zamontowaniem tego typu plików. Najwyżej trzeba podać jeden dodatkowy parametr, tj. offset . A co w przypadku obrazów dysków, które zwykle mają więcej niż jedną partycję? Gdybyśmy spróbowali zamontować taki plik w systemie, to zostanie nam zwrócony błąd, no bo przecież kernel nie wie za bardzo jak taki plik ma odczytać. Możemy za to skorzystać z urządzeń loop , które po odpowiedniej konfiguracji, są w stanie nam takie obrazy z powodzeniem zamontować na naszym linux'ie.

DKMS, czyli automatycznie budowane moduły

Mikhail Morfikov — Sat, 30 May 2015 21:05:27 +0000

Jeśli zamierzamy kupić sprzęt, który dopiero co trafił na półki w sklepach, to prawdopodobnie zaraz po podłączeniu go do naszego komputera okaże się, że to urządzenie nie jest nawet wykrywane przez system operacyjny. W przypadku gdy jego producent zapewnia w miarę przyzwoity support, to być może problemy, których doświadczamy, zostaną rozwiązane wraz z instalacją najnowszego kernela. Co jednak w przypadku gdy nawet po aktualizacji kernela nie jesteśmy w stanie odpalić, np. nowo zakupionej karty WiFi? Jako, że te wszystkie sprzęty działają w oparciu określone moduły, wystarczy taki moduł pozyskać, skompilować i załadować w systemie. Problem w tym, że z każdą nową wersją jądra operacyjnego, która trafi do repo debiana, będziemy musieli ręcznie budować moduł na nowo i właśnie w tym artykule opiszę jak nauczyć system, by sam przeprowadzał tę mozolną czynność bez naszego udziału.