Dnia 29-07-2020 do publicznej wiadomości zostały podane informacje na temat podatności BootHole, która to za sprawą bootloader'a GRUB2 w różnych dystrybucjach linux'a jest w stanie obejść mechanizm bezpieczeństwa EFI/UEFI, tj. Secure Boot. Z informacji, które opublikował Debian, sprawa nie wygląda miło, jako że poza aktualizacją GRUB2, shim, jądra linux, Fwupdate oraz Fwupd, unieważnieniu podlegają również klucze dystrybucji Debian/Ubuntu, przez co praktycznie cały soft podpisany tymi kluczami (w tym systemy live) przestaną działać w trybie Secure Boot. Czy jest się czego obawiać i co użytkownik korzystający z mechanizmu SB powinien w takiej sytuacji zrobić?

Jakiś czas temu opisywałem konfigurację własnych kluczy EFI/UEFI, którymi można zastąpić te wbudowane standardowo w firmware naszego komputera. W tamtym artykule napotkałem jednak dość dziwny problem, za sprawą którego nie można było zaktualizować zmiennych PK , KEK , db i dbx przy pomocy efi-updatevar z poziomu działającego linux'a. Gdy próbowało się te zmienne przepisać, dostawało się błąd typu Operation not permitted . Niby system został uruchomiony w trybie Setup Mode ale z jakiegoś powodu odmawiał on współpracy i trzeba było te zmienne aktualizować bezpośrednio z poziomu firmware EFI/UEFI, co było trochę upierdliwe. Szukając wtedy informacji na ten temat, jedyne co znalazłem, to fakt, że sporo osób ma podobny problem i najwyraźniej firmware mojego laptopa jest ździebko niedorobiony, przez co efi-updatevar nie mógł realizować swojego zdania. Rzeczywistość okazała się nieco inna, a rozwiązanie samego problemu było wręcz banalne.

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).

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.

Jakiś już czas temu opisywałem w jaki sposób skonfigurować AdBlock'a na routerze WiFi z wgranym firmware OpenWRT oraz jak wdrożyć szyfrowanie zapytań DNS w oparciu o dnscrypt-proxy dla wszystkich klientów naszej sieci domowej. Zarówno AdBlock jak i dnscrypt-proxy można w dalszym ciągu wykorzystywać, zwłaszcza na routerach wyposażonych w niewielkich rozmiarów flash i mało pamięci RAM. Niemniej jednak, nie każdy lubi konfigurować swój bezprzewodowy router za pośrednictwem terminala. Dla takich osób powstał właśnie AdGuard Home, który ma na celu możliwie uprościć konfigurację routera, przynajmniej jeśli chodzi o rzeczy związane z protokołem DNS. W tym artykule przyjrzymy się nieco bliżej AdGuard'owi i zobaczymy czy można z niego zrobić jakiś większy użytek.

Od dłuższego już czasu na swoich routerach WiFi wykorzystuję firmware OpenWRT. W przypadku mojego domowego routera TP-Link Archer C7 v2 zarządzanie jego oprogramowaniem sprowadza się w zasadzie do przeprowadzania aktualizacji raz na kilka tygodni czy miesięcy. Z reguły nie jest to jakoś czasochłonne zadanie, bo wystarczy pobrać stosowny obraz z serwera eko.one.pl i wrzucić go na router czy to przez interfejs LuCI, czy też przez sysupgrade . No tak tylko, że po wgraniu OpenWRT na flash routera trzeba zwykle też dograć szereg pakietów, których nie ma w standardzie, przynajmniej jeśli chodzi akurat o ten mój router bezprzewodowy. Podobnie sprawa ma się z odtwarzaniem konfiguracji, której pewne elementy pozostają niezmienne nawet po aktualizacji ze starszego wydania OpenWRT do nowszego. Postanowiłem zatem zgłębić nieco proces kompilacji źródeł i budowy obrazu z firmware OpenWRT, tak by nieco zautomatyzować sobie (czy też wręcz wyeliminować) chociaż część z kroków, które zwykle przeprowadzam chwilę po wgraniu obrazu na router. Cały ten proces budowy obrazu zostanie opisany przy wykorzystaniu dystrybucji Debian linux.

Przeniesienie mojego Debiana z laptopa mającego konfigurację BIOS i tablicę partycji MBR/MS-DOS do maszyny wyposażonej w firmware EFI/UEFI nie było jakoś stosunkowo trudnym zadaniem. Nawet kwestia włączenia Secure Boot okazała się o wiele mniej skomplikowana niż w rzeczywistości mogłoby się człowiekowi wydawać. Problem jednak pojawił się w przypadku płytek czy pendrive z systemami live. Nie chodzi przy tym o uruchamianie nośników z dopiero co wypalonymi obrazami ISO/IMG, bo te również nie sprawiają kłopotów. Chodzi bardziej o rozwiązanie multiboot, które oferuje wgranie wielu obrazów live na jedno urządzenie i odpalanie tego systemu, który sobie użytkownik w danym momencie zażyczy. Do tej pory korzystałem z projektu GLIM i może on posiada wsparcie dla EFI/UEFI ale już wsparcia dla Secure Boot mu zabrakło. W efekcie w konfiguracji EFI/UEFI + Secure Boot, GLIM stał się bezużyteczny i trzeba było rozejrzeć się za nieco innym rozwiązaniem. Okazało się, że nie trzeba daleko szukać, bo rEFInd jest w stanie natywnie uruchomić system z obrazu ISO praktycznie każdej dystrybucji linux'a (Ubuntu/Debian/Mint/GParted/CloneZilla) i w zasadzie trzeba tylko nieco inaczej przygotować nośnik, by móc na nowo cieszyć się korzyściami jakie oferuje pendrive multiboot.

W środowiskach linux'owych Secure Boot nie jest zbyt mile widziany i raczej postrzegany jako źródło wszelkiego zła na świecie. Sporo użytkowników linux'a dopatruje się w Secure Boot zamachu na wolność decydowania o swoim sprzęcie, który ma być serwowany przez Microsoft. Niemniej jednak, odsądzanie tego mechanizmu od czci i wiary jest moim zdaniem lekko nie na miejscu. Niewielu użytkowników linux'a zdaje sobie sprawę, że od prawie dekady istnieje taki wynalazek jak shim (no i jest też PreLoader), który umożliwia dystrybucjom linux'a (jak i ich końcowym użytkownikom) zaimplementowanie Secure Boot we własnym zakresie. Niemniej jednak, można całkowicie się obejść bez tych dodatków usuwając wbudowane w firmware EFI/UEFI certyfikaty i dodając na ich miejsce własnoręcznie wygenerowane klucze kryptograficzne. Takie podejście sprawia, że kod podpisany tylko i wyłącznie przez nas będzie mógł zostać uruchomiony przez firmware komputera w trybie Secure Boot, co może ździebko poprawić bezpieczeństwo naszego systemu. Poniższy artykuł ma na celu pokazać w jaki sposób zastąpić wbudowane w firmware EFI/UEFI klucze swoimi własnymi przy wykorzystaniu dystrybucji Debiana.

Czy zastanawialiście się może dlaczego baterie w laptopach zużywają się mimo, że w pewnych przypadkach nie są one praktycznie wykorzystywane? Rozważmy sobie ideę używania laptopa w roli przeciętnego komputera stacjonarnego. W takiej sytuacji do laptopa ciągle jest podpięty przewód zasilający, przez co bateria powinna być używana jedynie w momencie braku zasilania z sieci energetycznej. Zatem niby pobieramy prąd z gniazdka ale bateria i tak się nam zużyje po pewnym czasie. Niektórzy radzą, by wyciągnąć akumulator z laptopa i używać takiego komputera bez baterii. Takie postępowanie ma w moim odczuciu jednak same wady i postanowiłem poszukać jakiegoś bardziej cywilizowanego rozwiązania wzorowanego na aplikacji Battery Charge Limit spotykanego w smartfonach z Androidem. Gdyby udało się ustalić limit ładowania akumulatora w moim ThinkPad T430 na max 40%, to wydłużyłoby dość znacznie żywotność jego baterii. Niekiedy oprogramowanie na windows umożliwia tego typu funkcjonalność ale co w przypadku linux'a? Czy da radę pod linux powstrzymać laptopa od degradowania baterii za sprawą ładowania jej ciągle do 100%?

W moim laptopie Lenovo ThinkPad T430 jest obecny bluetooth Broadcom Corp. BCM20702 Bluetooth 4.0 o vid/pid 0a5c:21e6 . Niestety to urządzenie nie działa za dobrze na Debianie z powodu braku odpowiedniego firmware (plik BCM20702A1-0a5c-21e6.hcd ), którego jak na złość nie ma w repozytorium tej dystrybucji. Przydałoby się coś na to poradzić, by zmusić tę kartę/adapter do pracy pod linux.