Amazon bada alokację pamięci lokalnej MM, aby pomóc w obecnych/przyszłych atakach spekulacyjnych

W 2019 roku, po ujawnieniu kilku opartych na spekulacjach luk w zabezpieczeniach procesora, inżynierowie firmy Amazon zaproponowali alokację pamięci lokalnej dla procesu, aby ukryć tajemnice KVM. Dążyli do alternatywnego ograniczenia luk w zabezpieczeniach, takich jak L1TF, udostępniając niektóre obszary pamięci do alokacji jądra poza widokiem/dostępem z innego kodu jądra. Po pięciu latach ciągłych udoskonaleń jądra Linuksa inżynierowie firmy Amazon przygotowali w tym tygodniu nową propozycję dotyczącą alokacji lokalnej pamięci MM w celu radzenia sobie z obecnymi i przyszłymi atakami opartymi na spekulacjach.

Roman Kagan z Amazona wysłał w piątek „Prośbę o komentarz” w sprawie wprowadzenia alokacji pamięci lokalnej MM w jądrze Linuksa. To nowe podejście w ich zadaniu na rok 2019 wykorzystuje możliwości sekretów MEMFD i inne nowe funkcje jądra, aby łatwiej wdrożyć tę dodatkową funkcję bezpieczeństwa pamięci.

Wyjaśnił Roman Kagan Ciąg poprawki RFC:

„W wątku opublikowanym kilka lat temu zaproponowano, aby jądro mogło przydzielać pamięć lokalną do mm, a tym samym wypychać ją poza zasięg obecnych i przyszłych ataków międzyprocesowych. Nadal uważamy, że jest to fajne rzecz, którą warto mieć.

Jednakże od czasu tego wpisu Linux mm opracował sporo nowych funkcji, dlatego chcielibyśmy zbadać możliwości wdrożenia tej funkcjonalności przy mniejszym wysiłku i wykorzystaniu dostępnych obecnie udogodnień.

W szczególności jest to próba sprawdzenia koncepcji wdrożenia lokalnych dostosowań opartych na mm w memfd_secret(), przy użyciu zwykłych adresów użytkowników, ale przypinanie stron i odwracanie flagi użytkownika/administratora na danych PTE, aby były one bezpośrednio dostępne z jądra i zamknięcie VMA, aby uniemożliwić użytkownikowi przejęcie zakresu adresów. Takie podejście pozwoliło na przeniesienie wszystkich ciężkich prac – zarządzania adresami, interakcji z aktualną mapą i porządkowania mm – na istniejącą infrastrukturę i nie wymagało żadnego kodu specyficznego dla architektury.

W porównaniu z podejściem zastosowanym w oryginalnej serii, gdzie do lokalnego przydziału milimetrów wykorzystano dedykowany zakres adresów jądra, a tym samym dedykowaną PGD, zaproponowane tutaj podejście może mieć pewne wady, w szczególności

– Użycie adresów użytkowników z pamięci jądra może prowadzić do naruszenia założeń w różnych częściach kodu jądra, czego być może nie wyłapaliśmy z naszych testów dymnych

– Niestandardowe adresy mogą zostać odgadnięte przez strefę użytkownika (ATM jest widoczny w /proc/PID/maps, ale można to naprawić), co może osłabić bezpieczeństwo

Zawiera także prosty sterownik testowy i autotest do testowania dymu i demonstracji funkcji.

Kod jest PoC RFC i brakuje mu wielu procedur sprawdzania poprawności i obsługi specjalnych przypadków, ale oddaje sens. Jesteśmy wdzięczni za wszelkie opinie na temat tego, czy to podejście jest wykonalne, czy też lepiej je porzucić na rzecz podejścia, które ma niestandardowy zakres adresów PGD/jądro lub coś innego.

Ciekawie będzie zobaczyć, w jakim kierunku posuną się alokacje pamięci lokalnej MM, aby były bardziej odporne na ataki oparte na spekulacjach między procesami.