reklama

Linux wyleczył się z koszmarów i pozbył wsparcia dla zapomnianych procesorów

Strona główna Aktualności

O autorze

Hodowca maszyn wirtualnych i psów, poza tym stary linuksiarz, bonvivant i śmieszek. W 2012 roku napisał na DP o algorytmie haszowania Keccak i wciąż pamięta, jak on działa.

Linuksa 4.17 otrzymaliśmy zgodnie z terminem, po 63 dniach prac deweloperów. Niespodziewanie zmieniła się nazwa kodowa kernela, to już nie „Fearless Coyote”, lecz „Merciless Moray”. Spodziewanie za to Linus Torvalds nie zmienił wiodącego numerka wersji – na Linuksa 5.0 jeszcze troszkę poczekamy, mimo że warunek zmiany numeracji został spełniony: liczba obiektów w repozytorium kodu źródłowego przekroczyła właśnie sześć milionów. A co innowacyjnego w najważniejszym z kerneli tej planety? Zapraszamy do przeglądu nowości, jakie przynosi Linux 4.17.

Koniec sennych koszmarów

Nowa wersja kernela rozwiązuje problem z dziwnym zachowaniem rdzeni w procesorach Intela, które w stanie uśpienia nagle doświadczały nieuzasadnionych niczym wybudzeń. Odkryli to informatycy z Uniwersytetu Technicznego w Dreźnie, przypisując problem interakcjom między procesami działającymi w tle i zarządcą jałowego biegu. Doprowadziły one do błędnych przewidywań czasu usypiania rdzeni w trakcie wysokiego zużycia energii. Jeśli następująca po aktywności faza wybudzenia trwała dłużej, np. do 10 sekund, nie było jak skorygować decyzji w tym czasie.

Najlepszą strategią zaradzenia problemowi okazało się wprowadzenie swoistego „budzika”, który jest w stanie poprawić złą decyzję co do stanu uśpienia w krótkim czasie. Przykładowa implementacja została oddana linuksowej społeczności, a następnie trafiła do podsystemu zarządzania jałowym biegiem. Efekt jest taki, że system śpi teraz znacznie efektywniej, zmniejszając zużycie energii o około 10%. Co więcej, aplikacje o skróconych cyklach uśpienia korzystają z mniejszych opóźnień i co za tym idzie, wyższej wydajności.

Co ciekawe, ta zmiana ma też wpływ na procesory AMD – do tej pory usypiano je wywołaniem, które wpędzało w niezbyt głęboką drzemkę. Teraz kernel potrafi przełączyć procesory Ryzen i Epyc w znacznie głębszy stan uśpienia.

Lepsze sterowanie ładowaniem baterii

Wiele ciekawych rzeczy stało się możliwych w kwestii kontroli zasilania. Można m.in. zdefiniować poziomy naładowania baterii, od których firmware zacznie i przestanie je ładować. Takimi funkcjami dysponują niektóre notebooki, wykorzystując je do wydłużenia czasu życia baterii. Wcześniej jednak można było to ustawić tylko z poziomu UEFI/BIOS-u. Teraz na kompatybilnym sprzęcie (m.in. Thinkpadach) będzie można ustawić to z poziomu systemu operacyjnego.

Chronione treści w grafice Intela

Powszechnie dziś wykorzystywany do ochrony treści mechanizm High-bandwith Digital Content Protection (HDCP) uniemożliwia przesyłanie wideo wysokiej rozdzielczości w formie, która pozwalałaby na łatwe tworzenie ich kopii. Osoby zainteresowane oglądaniem chronionych przez DRM treści wideo nie miały łatwo na Linuksie. Jako że nie był on wspierany przez intelowe sterowniki, nie można było na Linuksie takich treści oglądać np. na zewnętrznym wyświetlaczu.

Teraz dzięki pracy deweloperów Chrome OS-a, sterowniki i915 są w stanie poprawnie odtworzyć wideo wysokiej rozdzielczości – na chromebookach możliwe jest już odtwarzanie tak chronionych treści. W teorii powinno być to możliwe także na innych linuksowych systemach – sprawdzimy to jak kernel 4.17 trafi w nasze ręce.

Nowy sterownik AMD dla prawie wszystkich

Ta nowa infrastruktura grafiki Display Core, którą AMD wprowadziło w Linuksie 4.15, aktywowana jest teraz automatycznie także dla starszych kart graficznych. Dzięki temu na opensource’owym sterowniku będą mogli korzystać z HDMI 2.0 oraz przekierowania dźwięku na HDMI i DisplayPort. Dodano też wsparcie dla nowych czipów Vega12, które powinny zadebiutować lada moment.

Możliwe jest już także wykorzystanie platformy obliczeniowej ROCm (RadeonOpen Compute) ze starszymi układami graficznymi. W kernelu 4.18 pojawić się ma wsparcie dla ROCm na współczesnych architekturach Polaris i Vega.

Kernel odszyfruje strumień danych TLS

Ciężka praca odszyfrowania danych z Transport Layer Security została przeniesiona na kernel. Już w Linuksie 4.13 moduł KTLS pozwalał na szyfrowanie danych wysyłanych po TLS, teraz potrafi jest także bezpośrednio odszyfrować. Przekłada się to na zwiększenie wydajności HTTPS i innych protokołów komunikacyjnych korzystających z TLS. Obsługa tego na poziomie kernela to mniej operacji na pamięci, a to pozwala na znacznie efektywniejsze przetwarzanie danych, zwiększa przepustowość i zmniejsza obciążenie systemu i opóźnienia. KTLS lepiej się także integruje z akceleratorami kryptograficznymi.

Oczywiście wciąż kwestie takie jak nawiązanie i konfiguracja połączenia są przetwarzanie przez biblioteki działające w przestrzeni użytkownika, takie jak OpenSSL.

Bezpieczniej i wydajniej w systemach plików

Podstawowy linuksowy system plików EXT4 został zabezpieczony przed uzłośliwionymi obrazami kontenerów, które najwyraźniej mogły linkować do systemu plików hosta, a następnie „wmówić mu”, że są jego częścią… np. podmieniając katalogi /sbin na swoje – i w ten sposób otwierając drogę do uruchomienia malware.

Opiekun systemu Ted Ts’o wciąż jednak podkreśla, że fanom kontenerów nie powinno się wydawać, że podpinanie obrazów systemów plików jak popadnie jest rozsądną rzeczą. Ostrzeżenie słuszne, biorąc pod uwagę rosnącą popularność paczek snap Canonicala.

Z kolei system plików XFS obsługuje opcję montowania lazytime, stosowaną od jakiegoś czasu właśnie w EXT4. Potrafi ona wyraźnie zwiększyć wydajność systemu plików, opóźniając zapisy wywołane potrzebą aktualizacji metadanych.

Na froncie walki z widmami…

Skoro już o bezpieczeństwie była mowa, nowa wersje kernela przynosi ulepszenia w zabezpieczeniach przed Spectre v1 i v3, uporządkowano też kod wywołań systemowych, aby chronić przed atakami korzystającymi ze spekulatywnego wykonywania kodu.

Zmniejszono też narzut generowany przez zabezpieczenia przed atakiem Meltdown na stare procesory, które nie obsługiwały mechanizmu PCID (Process Context Identifiers) – teraz takie systemy z aktywną łatką powinny być znacznie bardziej responsywne.

Oprócz tego kernel 4.17 dostał zabezpieczenie przed Spectre v4, niedawno odkrytą wersją ataku o nazwie Speculative Store Bypass. Łatka na większości systemów jednak nie działa, ponieważ zależy od nowych funkcji włączonych z poziomu mikrokodu Intela, a tego mikrokodu jeszcze nie udostępniono użytkownikom.

Z zupełnie innej beczki, framework bezpieczeństwa AppArmor dostał mechanizm mediacji z gniazdkami sieciowymi, będący warunkiem koniecznym dla lepszej izolacji aplikacji uruchamianych z kontenerów snap. Podsystem kryptograficzny oferuje zaś mechanizm Cipher FeedBack, przydatny w systemach korzystających z Trusted Platform Module 2, oraz lekki szyfr blokowy Speck, który świetnie się spisuje na systemach nie mających sprzętowej akceleracji szyfru AES.

Wiosenne porządki

Ilu z nas kojarzy takie architektury procesorowe jak Blackfin, Cris, Frv, M32r, Metag, Mn10300, Score i Tile? Pewnie niewielu. No cóż, działał na nich Linux, ale już działać nie będzie. Linus zdecydował o usunięciu ponad 465 tysięcy wierszy kodu, odpowiedzialnych za wsparcie tych zapomnianych przez świat architektur.

Między innymi za sprawą tych porządków, Linux 4.17 jest mniejszy od Linuksa 4.16 – ubyło mu łącznie około 180 tysięcy wierszy kodu. Bez obaw, następne wakacyjne wydanie będzie już tłustsze. Zaczekamy na nie do sierpnia. A wszyskich zainteresowanych dokładną listą zmian w linuksowym kernelu zapraszamy na Phoronixa. Niestety kernelnewbies zaprzestało publikować swoje podsumowania – ostatnie jest dla kernela 4.15.

© dobreprogramy
reklama

Komentarze

reklama