Przestrzeń wymiany SWAP tylko na potrzebny hibernacji w Debian linux

W obecnych czasach, rola przestrzeni wymiany w zasadzie ograniczyła się z grubsza do umożliwienia nam przeprowadzenia procesu hibernacji. Inne aspekty pracy systemu, w których SWAP brał udział zostały albo zepchnięte na margines (bardzo stare maszyny z niewielką ilością RAM), albo zupełnie wyeliminowane za sprawą nowszych technologi lub/i posiadania większej ilości pamięci operacyjnej w takich systemach. Obecnie domowy komputer z 32 GiB pamięci RAM to nic niezwykłego i przestrzeń wymiany na takich maszynach nie jest już nam w zasadzie do niczego potrzebna, bo raczej jest mało prawdopodobne, że nam tej pamięci zabraknie przy codziennym użytkowaniu naszego linux'a. Niemniej jednak, hibernacja systemu jest czymś pozytywnym z perspektywy użytkownika, bo umożliwia mu zapisanie stanu pracy przed wyłączeniem komputera i odtworzenie tego stanu po ponownym uruchomieniu systemu. Jeśli chcielibyśmy się cieszyć urokami hibernacji, to bez konfiguracji SWAP'a się nie obejdzie. Problem jednak zaczyna się, gdy mamy dysk SSD i taka przestrzeń wymiany zostanie na nim skonfigurowana. Chodzi generalnie o pewne aplikacje, które są w stanie generować bardzo dużo cache w pamięci operacyjnej, czego efektem będzie przenoszenie danych z RAM do SWAP, a to może bardzo szybko wykończyć taki nośnik flash. Dlatego też przydałoby się nieco zabezpieczyć przestrzeń wymiany przed tego typu sytuacjami, tak by można było jej używać jedynie w przypadku hibernacji.

Trim/discard przy LUKS/LVM na dysku SSD pod Debian linux

Z okazji zbliżającego się końca roku, postanowiłem nieco ogarnąć swojego Debiana, tj. postawić go na nowo. Jakby nie patrzeć 4 lata korzystania z tego linux'a z włączonymi gałęziami unstable i experimental sprawiło, że trochę syfu się nazbierało. Nie chciałem też czyścić całego kontenera LUKS czy samej struktury LVM z systemowymi voluminami logicznymi na starym dysku HDD, bo zainstalowany tam system zawsze może się do czegoś przydać, np. do odratowania tego nowego linux'a. Dlatego też postanowiłem zakupić niedrogi dysk SSD (MLC, używany) i to na nim postawić świeżego Debiana z wykorzystaniem narzędzia debootstrap. Sama instalacja linux'a na dysku SSD nie różni się zbytnio od instalacji na dysku HDD, za wyjątkiem skonfigurowania w takim systemie mechanizmu trim/discard. Standardowi użytkownicy linux'a nie muszą zbytnio nic robić, aby ten mechanizm został poprawnie skonfigurowany. Sprawa się nieco komplikuje, gdy wykorzystywany jest device-mapper, który mapuje fizyczne bloki urządzenia na te wirtualne, np. przy szyfrowaniu dysku z wykorzystaniem LUKS/dm-crypt, czy korzystaniu z voluminów logicznych LVM. Dlatego też postanowiłem przyjrzeć się nieco bliżej zagadnieniu konfiguracji mechanizmu trim/discard na dysku SSD w przypadku zaszyfrowanego systemu na bazie LUKS+LVM.

Martwy smartfon Xiaomi Redmi 9 i jego odzysk via SP Flash Tool

Przeglądając ostatnio stronę xiaomifirmwareupdater.com zauważyłem, że jest tam dostępna nowsza wersja firmware dla mojego telefonu Xiaomi Redmi 9 (lancelot/galahad). Patrząc po numerkach V13.0.1.0.SJCEUXM (nowy dla Android 12) oraz V12.5.4.0.RJCEUXM (stary dla Android 11), miałem pewne wątpliwości czy wgrać sobie ten nowszy firmware. Niby na tym smartfonie mam wgrany ROM crDrdoid v8.9, który dostarcza Androida 12.1, więc aktualizacja firmware sposobem opisanym tutaj powinna przebiec bez żadnych problemów. No i przebiegła, tylko po zrestartowaniu telefonu, ten już się nie uruchomił. Działał mi jedynie tryb fastboot (normalny boot i tryb recovery były martwe). Postanowiłem przywrócić poprzedni firmware wydobywając obrazy ze starej paczki firmware i ręcznie przy pomocy narzędzia fastboot wgrać te obrazy na odpowiadające im partycje w telefonie z poziomu mojego Debiana. Tutaj jednak zostało poczynionych parę błędów (o tym później), które doprowadziły do całkowitego uwalenia telefonu (hard brick), gdzie nawet tryb fastboot zdechł. W efekcie telefon już nie reagował na żadne kombinacje przycisków, a ekran pozostawał czarny -- jednym słowem nie działał żaden tryb pracy telefonu i wyglądało na to, że mam w łapkach już tylko sam złom elektroniczny i tak by w istocie było, gdyby z pomocą nie przyszedł mi SP Flash Tool.

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

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.

Oblivious DoH (ODoH) z dnscrypt-proxy na Debian Linux

Parę miesięcy temu natrafiłem na taki oto artykuł na blogu Cloudflare, który poświęcony jest poprawie prywatności wykonywanych przez klientów zapytań DNS za sprawą wykorzystania mechanizmu zwanego Oblivious DoH (ODoH). Oczywiście postanowiłem już wtedy zbadać czym ten ODoH jest ale standardowe narzędzia dostępne w linux'ie (Debian/Ubuntu) jeszcze (przynajmniej wtedy) nie dojrzały do obsługi ODoH. Obecnie już jest trochę lepiej ale Oblivious DoH wciąż jest w fazie eksperymentów (RFC9230). Póki co, jedynym znanym mi narzędziem, które posiada wsparcie dla ODoH jest dnscrypt-proxy, którego instalację i konfigurację do współpracy z dnsmasq już jakiś czas temu opisywałem. Mając wsparcie dla ODoH w dnscrypt-proxy możemy pokusić się o wdrożenie Oblivious DoH w swoim systemie i sprawdzić czy faktycznie taki zabieg przyczyni się do poprawy prywatności wykonywanych przez nas zapytań DNS i właśnie temu zagadnieniu będzie poświęcony niniejszy wpis.

Jak zainstalować Magisk bez dostępu do TWRP/SHRP recovery

Parę dni temu na mój telefon Xiaomi Redmi 9 (lancelot/galahad/shiva/lava) została wypuszczona aktualizacja ROM'u crDroid, który bazuje na AOSP/LineageOS. Ten update nie tylko miał uwzględnione najnowsze poprawki bezpieczeństwa ale również podbijał wersję Androida z 11 na 12. Problem w tym, że TWRP/SHRP recovery ma problemy z obsługą sposobu szyfrowania partycji /data/ , który najwyraźniej uległ przeobrażeniu w Androidzie 12. Efektem braku wsparcia dla szyfrowania w TWRP/SHRP jest naturalnie brak możliwości wgrywania danych na partycję /data/ . Niestety niesie to za sobą przykre konsekwencje w postaci uniemożliwienia użytkownikowi przeprowadzenia procesu patch'owania obrazu partycji /boot/ z poziomu trybu recovery, czego efektem jest brak możliwości zainstalowania Magisk'a w systemie smartfona. Bez Magisk'a nie damy rady ukorzenić systemu, tj. uzyskać w nim praw administratora root. Na szczęście nie wszystko stracone. Magisk'a można zainstalować w telefonie ręcznie przy pomocy ADB oraz trybu bootloader'a (fastboot) eliminując tym samym potrzebę przełączenia się w tryb recovery. Niniejszy artykuł ma na celu pokazanie jak zainstalować Magisk'a bez odwoływania się do trybu TWRP/SHRP recovery.

Tryb bezczynności baterii (IDLE mode) w smartfonach z Androidem

Gdy zapytamy użytkowników smartfonów z Androidem o to, czy taki sprzęt jest w stanie pracować z pominięciem układu baterii, zapewne wiele z tych osób odpowiedziałoby, że nie ma takiej opcji, bo przecież w tych telefonach od lat baterii się już nie da wyciągnąć. Nawet w tych starszych modelach, po wyjęciu baterii i podłączeniu ładowarki, system w takim urządzeniu nie chciał się uruchomić. Okazuje się jednak, że nie trzeba wyjmować akumulatora ze smartfona, by to urządzenie było w stanie działać z pominięciem układu baterii, tj. w tzw. trybie bezczynności baterii (battery IDLE mode), coś na wzór rozwiązania stosowanego od dekad w laptopach. Niemniej jednak, takiej funkcjonalności zwykle nie uświadczymy w stock'owych Androidach. Możemy się jednak o nią postarać ale do tego celu niezbędne będzie nam uzyskanie praw administratora systemu root, choć lepiej wgrać sobie na smartfon ROM na bazie AOSP/LineageOS. Bez ukorzenionego Androida nie mamy nawet co podchodzić do implementacji tego mechanizmu. Dodatkowo będzie nam potrzebny zaawansowany kontroler ładowania baterii ACC (w postaci modułu do Magisk'a) i opcjonalnie też graficzna nakładka ACCA (do pobrania z F-Droid). W poniższym artykule postaramy się odpowiedzieć na pytanie czy takie rozwiązanie na bazie IDLE mode w przypadku baterii w smartfonach z Androidem ma w ogóle sens i czy może nam się ewentualnie do czegoś przydać.

Rekalibracja baterii w laptopach Lenovo ThinkPad pod linux

Jakiś już czas temu opisywałem temat konfiguracji progów ładowania baterii w laptopie Lenovo ThinkPad T430, tak by przedłużyć parokrotnie jej żywotność. Niemniej jednak, ustawienie na dłuższy czas progów 30-40% nie pozostaje bez wpływu na pracę maszyny. Może i same baterie litowo-jonowe nie posiadają efektu pamięci ale elektronika, która tymi bateriami zarządza, już tę pamięć może posiadać. Chodzi generalnie o to, że brak pełnych cyklów baterii (rozładowanie do 0% i ładowanie do 100%) może powodować różne błędy w ocenie ile faktycznie tego ładunku w takim akumulatorze pozostało. Efektem tych błędów są wskazania sugerujące, że nasz laptop może jeszcze popracować, np. 20-30 minut dłużej, gdy stan faktyczny na to nie pozwala, co skończyć może się utratą niezapisanych danych w skutek nagłego odcięcia zasilania. Dlatego też jeśli wykorzystujemy jedynie pewien zakres pojemności baterii w laptopie, to co pewien czas (co 30-50 takich niepełnych cykli albo raz na 2 miesiące) przydałoby się przeprowadzić w laptopie proces rekalibracji baterii (a raczej rekalibrację jej kontrolera/elektroniki), tak by ewentualne straty pojemności zostały uwzględnione w szacunkach systemu. Zabieg rekalibracji baterii można bez większego problemu przeprowadzić z poziomu dowolnej dystrybucji linux'a, np. Debian/Ubuntu, i tym zagadnieniem się zajmiemy w niniejszym artykule.

Zmiana adresu MAC (BSSID) routera WiFi w OpenWRT

Pisząc ostatnio artykuł o tym jak uchronić nasz prywatny punkt dostępu do sieci WiFi przed zmapowaniem i umieszczeniem jego fizycznej lokalizacji w serwisach pokroju Wigle.net czy też w usługach Google/Mozilla, poruszony został temat ewentualnego usuwania wpisów z takich baz danych AP za sprawą dopisywania do nazwy sieci (ESSID) sufiksu _nomap . Nie wszystkie organizacje/firmy respektują naszą prywatność i raczej też nie będą tej końcówki w nazwie sieci honorować. Jako, że jednym z dwóch parametrów, na podstawie których takie mapowanie punktów dostępowych się odbywa, jest adres MAC interfejsu bezprzewodowego danego AP (BSSID), to możemy od czasu do czasu pokusić się o zmianę tego adresu. Jest to mniej więcej to samo rozwiązanie, co zastosowane przy klonowaniu adresu MAC dla portu WAN routera, które z reguły użytkownicy wykorzystują do obchodzenia zabezpieczeń tych bardziej wrednych ISP. Jako, że temat zmiany BSSID trochę się różni od zmiany adresu MAC dla portu WAN, to w niniejszym artykule postanowiłem opisać jak w routerze z wgranym firmware OpenWRT podejść do tego zadania.

Jak ukryć nazwę sieci WiFi (ESSID) przed Wigle.net/Google/Mozilla

Parę dni temu napisał do mnie megabajt z forum DUG z wiadomością, że nazwa mojego WiFi figuruje w bazie danych serwisu Wigle.net oraz, że lepiej nie zdradzać nazw swoich WiFi osobom trzecim, bo ktoś w oparciu o te dane może poznać nasze fizyczne położenie. Jak najbardziej istnieje taka możliwość, a sam serwis Wigle.net nie jest jedynym, który zbiera informacje o położeniach geograficznych punktów dostępowych WiFi, bo od lat robi to też Google i Mozilla. Niemniej jednak, podchodziłbym z pewną dozą ostrożności do danych zgromadzonych w serwisie Wigle.net (i tych pozostałych dwóch też), bo nie zawsze muszą one być akuratne. W zasadzie to nie zdziwiłem się zbytnio, że nazwa mojej sieci WiFi figuruje w bazie danych Wigle.net, bo sam ją tam umieściłem świadomie jakiś czas temu w ramach testów wykorzystując do tego celu aplikację WiGLE WiFi Wardriving, którą można wgrać przez F-Droid na każdy telefon z Androidem. Jako, że nadarzyła się okazja, to postanowiłem napisać parę słów na temat unikania bycia zmapowanym, tak by jakiś nieznany nam bliżej osobnik przez przypadek nie wrzucił lokalizacji naszych domowych/firmowych AP do bazy danych Google/Mozilla czy też wspomnianego wyżej serwisu Wigle.net, o ile oczywiście sobie tego nie życzymy.