Kategoria: Linux

Opublikowane w

Entropia w Linuksie – HOWTO

Dawno temu pojawił się mit, że źródłem prawdziwej entropii w Linuksie jest /dev/random jest, /dev/urandom jest gorszy. Pokutuje on do dziś i część softu za źródło danych przyjmuje właśnie /dev/random, niezależnie od realnych potrzeb. Ilość losowych danych w systemie nie jest nieskończona i zależy od dostępnych źródeł i zdarzeń zewnętrznych. Dopóki komputery były głównie fizyczne, często obsługiwane przez ludzi, problem był nieco mniejszy. W epoce wirtualek systemy i ruch są coraz bardziej powtarzalne, więc z „prawdziwą” entropią są problemy. A entropia w systemie Linux nadal jest w systemach aplikacjom potrzebna – słusznie lub nie, chyba nawet bardziej niż kiedyś, bo szyfrowanie wszystkiego jest coraz bardziej popularne i wykorzystywane są coraz silniejsze algorytmy.

Od pewnego czasu (okolice wersji 3.7) kernel Linuksa potrafi co prawda korzystać ze sprzętowych modułów (TPM) zapewniających źródła losowych danych, o ile takie są obecne. Nie każdy sprzęt jest jednak w to wyposażony, nie każda wirtualka posiada dostęp do danych z hypervisora i obecność modułu nie oznacza jeszcze, że dane będą dostępne dla programów, więc problem nadal pozostaje.

Entropia w systemie Linux – sprawdzenie dostępności

Jeśli nie wiemy, czy faktycznie system ma problem z dostępną entropią, możemy to w prosty sposób sprawdzić. Aktualną ilość można odczytać przez wydanie polecenia:

cat /proc/sys/kernel/random/entropy_avail

Oczywiście jest to wartość chwilowa, zmieniająca się w czasie, żeby z całą pewnością stwierdzić, jak system stoi z entropią, trzeba by poobserwować w dłuższym czasie, a najlepiej monitorować ją, np. przy pomocy Zabbiksa. Wartość powyżej 1000 oznacza, że na pewno problemu nie ma, wartości poniżej 300 oznaczają, że prawie na pewno są niedobory, mogące wpływać na pracę usług.

rngd

Istnieją dwa rozwiązania, które pomogą zwiększyć ilość dostępnych danych losowych w systemie. Pierwsze z nich, to rngd z pakietu rng-tools. Jego zadanie jest proste – dostarczać dane do napełniania /dev/random korzystając ze wskazanego źródła.

Jeśli platforma posiada sprzętowy moduł dostarczający dane losowe, rngd warto skonfigurować, by z niego korzystał. W tym celu w pliku

/etc/default/rng-tools

należy umieścić linię

HRNGDEVICE=/dev/hwrng

Natomiast w przypadku braku takiego modułu, sugerowane jest dodanie linii

HRNGDEVICE=/dev/urandom

Kontrowersje korzystania z /dev/urandom

Korzystanie z /dev/urandom jako źródła danych dla /dev/random powoduje kontrowersje. Główne zarzuty to niegwarantowana losowość danych w /dev/urandom (ale patrz mit), oraz powstawanie sprzężenia zwrotnego, co łącznie może powodować okresowość, a zatem teoretyczną możliwość przewidzenia stanu generatora liczb pseudolosowych. Podkreślam, że jest to możliwość czysto teoretyczna, nie wykazana w praktyce.

Alternatywa dla rngd

Istnieje drugie popularne rozwiązanie programowe, które pozwala na zwiększenie dostępnej w systemie entropii w systemie Linux. Jest to demon haveged z pakietu o tej samej nazwie. Korzysta on z faktu, że czas wykonania kodu przez procesor jest mało powtarzalny i zależy od wielu czynników. Jest to rozwiązanie obecne w dystrybucjach od wielu lat, proste w użyciu.

Wybór rozwiązania

Jeśli system posiada moduł sprzętowy, to bym z niego korzysał, za pośrednictwem rngd. Czy haveged jest lepszy od rngd zasilanego z /dev/urandom? Nie podejmuję się odpowiedzi na to pytanie. Oba zapewniają najważniejszą sprawę, czyli dostępność danych losowych. Oba rozwiązania spełniają proste testy badające losowość danych. Osobiście uważam, że w większości przypadków rozwiązanie korzystające z rngd jest wystarczające. Tam gdzie do losowości danych przykładamy dużą wagę, nie powinno być problemu z dostępem do sprzętowych generatorów, a niedobory entropii zawsze są bardziej szkodliwe, niż jej teoretycznie niższa jakość.

Linki

Na koniec zbiór linków dotyczących zagadnienia jakim jest entropia w systemie Linux; zarówno źródła jak i dalsza lektura, czyli ciekawe linki (kolejność losowa):

Opublikowane w

Debian skończył 24 lata; reproducible builds częścią polityki Debiana

Urodziny były parę dni temu. Rocznica jak rocznica i nie odnotowywałbym, ale szykuje się ważna zmiana w Debian Policy. Pakiety powinny być budowane w sposób powtarzalny. Pisałem o tym 2,5 roku temu i bardzo mnie cieszy, że jest to oficjalna wytyczna.

Przy okazji – problem został dostrzeżony szerzej w świecie otwartego oprogramowania. O powtarzalnym budowaniu więcej można przeczytać na stronie reproducible-builds.org.

Opublikowane w

Termometr na USB

Dawno temu byłem zafascynowany prostym układem DS18S20, który działa za pośrednictwem 1-wire i umożliwia dokładny odczyt temperatury przez komputer. Schematów podłączenia termometru przez USB wtedy nie było, za to opisów podłączenia przez RS-232 była masa, koszt układu niewielki. Jedyne co powstrzymywało mnie wtedy przed uruchomieniem to… brak realnej potrzeby.

Potem sytuacja się zmieniła – port szeregowy zaczął w komputerach zanikać. A mnie coraz bardziej interesowała temperatura z wbudowanych czujników (płyta główna, dyski), a nie temperatura otoczenia. Były co prawda schematy jak to podłączyć przez USB, ale w stosunku do pierwowzoru rósł i poziom skomplikowania, i koszt.

Niedawno pojawiła się potrzeba (no dobra, powiedzmy, że potrzeba, bardziej pretekst), więc odświeżyłem temat. Okazało się, że istnieją tanie moduły PL2303HX USB UART, a także nieco nowsza wersja cyfrowych termometrów, oznaczona symbolem DS18B20. Różnica między wersjami w sumie pomijalna, z perspektywy tego wpisu. Każda z tych rzeczy to ok. 6 zł z dostawą (Allegro), a podłączenie jest jeszcze prostsze i nie wymaga żadnych dodatkowych elementów, jak widać na schemacie.

Do odczytu temperatury z termometru na USB służy digitemp. Opis użycia (zaczerpnięty stąd).

Instalacja pakietu:

apt-get install digitemp

Skanowanie układów:

digitemp_DS9097 -i -s /dev/ttyUSB0

Odczyt wartości:

digitemp_DS9097 -a

Bardziej zależało mi na sprawdzeniu, czy taka prosta wersja faktycznie będzie działać – w wielu miejscach podawane są bardziej skomplikowane schematy. Faktycznie, działa. Rozwiązanie zlutowane na krótko, bez żadnego przewodu ma jednak tę wadę, że moduł PL2303HX grzeje się na tyle, że wpływa na odczyt temperatury. Myślę, że ok. 10 cm kabla załatwi temat, ale gdyby ktoś był zainteresowany to można pomyśleć od razu o kupnie nieznacznie droższej wersji wodoodpornej, z przewodem. Mi akurat zależało żeby kabel się nie pałętał, ale wersję z kablem można zawsze skrócić…

Oczywiście gdyby ktoś chciał całkiem nowocześnie, to teraz czujniki temperatury montuje się do ESP8266 i odczytuje po WiFi. Tyle, że w moim wypadku to byłoby niewygodne. Miałbym problem z zasilaniem, a dane i tak mają trafić do pełnoprawnego komputera, ew. do SoC z Linuksem.

Gdyby ktoś bał się, że blog skręca całkiem w tematy elektroniczne – bez obaw, będzie najwyżej parę wpisów. I raczej w ramach wspomnienia o czymś, niż jako podstawowa tematyka.