Z ujawnionych dokumentów wynika, że firma Google planowała wprowadzenie kluczowej funkcji bezpieczeństwa w modelu Pixel 11 dla systemu GrapheneOS, a następnie zrezygnowała z niej

GrapheneOS, wzmocniona pod kątem prywatności wersja systemu Android, która od lat jest dostarczana wyłącznie na telefony Google Pixel, informuje, że nie jest w stanie zapewnić prawidłowej obsługi nowej serii Pixel 11. Po tygodniu prób wymuszenia portowania zespół odkrył, że w chipie Tensor G6 modelu Pixel 11 brakuje sprzętowej obsługi funkcji o nazwie Memory Tagging Extension (MTE) – funkcji bezpieczeństwa, w którą wyposażone są wszystkie chipy z serii Pixel od modelu Pixel 8 z 2023 roku.
Zasadniczo MTE działa w następujący sposób: pamięć Państwa telefonu stanowi ogromną siatkę małych komórek pamięci. Wiele exploitów działa poprzez nakłonienie aplikacji do odczytu lub zapisu w niewłaściwej komórce, do której nie powinna mieć dostępu. MTE zapobiega temu, umieszczając niewidzialną karteczkę samoprzylepną na każdym 16-bajtowym fragmencie pamięci oraz na każdym wskaźniku uprawnionym do dostępu do niego. Jeśli karteczki samoprzylepne nie są zgodne w momencie, gdy program próbuje odczytać lub zapisać dane, układ gwałtownie hamuje, przerywając proces zamiast po cichu przepuścić exploit. System GrapheneOS wykorzystuje technologię MTE w całym swoim systemie operacyjnym i twierdzi, że eliminuje ona całe kategorie prób zdalnego włamania, zanim jeszcze zdążą się one rozpocząć. Zespół twierdzi, że wygląda na to, iż firma Google usunęła technologię MTE z modelu Pixel 11 w celu obniżenia kosztów; firma Google nie skomentowała tej sprawy. GrapheneOS zaleca obecnie użytkownikom pominięcie modelu Pixel 11 i zakup modelu Pixel 8, 9 lub 10, jeśli chcą korzystać z systemu GrapheneOS.
Co faktycznie zyskuje Google dzięki usunięciu MTE
Artykuł naukowy autorstwa badaczy z UT Austin, UC Berkeley, Google oraz Ampere Computing (arXiv:2601.11786) daje nam wyobrażenie o kosztach wdrożenia technologii MTE w rzeczywistym sprzęcie, co pozwala również oszacować, ile firma oszczędza, rezygnując z jej zastosowania.
Same „notatki” są dość niewielkie: 4 bity na każde 16 bajtów pamięci, co stanowi około 3,125% obciążenia dodatkowego. Specyfikacja ARM nie określa, gdzie producenci układów scalonych muszą przechowywać te „notatki”, a jedynie stwierdza, że muszą one gdzieś istnieć. Dlatego firmy stosują różne rozwiązania. Własny projekt referencyjny firmy ARM rezerwuje dedykowany fragment pamięci RAM i w przypadku braku trafienia w pamięci podręcznej wykonuje dwa oddzielne pobrania danych z pamięci: jedno dla samych danych, a drugie dla notatki. Firma Ampere, produkująca układy do serwerów, zamiast tego umieszcza notatki na bitach zwykle wykorzystywanych do korekcji błędów i pobiera dane wraz z notatką w ramach jednego operacji. Żadne z tych podejść nie jest bardziej poprawne; firma ARM celowo wbudowała tę elastyczność.
Większym obciążeniem nie jest dodatkowe 3,125% pamięci potrzebnej w układzie, ale dodatkowa praca, jaką układ musi wykonać przy każdym dostępie do pamięci. Za każdym razem, gdy Państwa telefon korzysta z pamięci, musi sprawdzić ten mały znacznik, co wymaga dedykowanego obwodu porównawczego. Przypisywanie tagów w sposób losowy, tak aby osoby atakujące nie mogły ich przewidzieć, wymaga wbudowanego w układ generatora liczb losowych, a stworzenie szybkiego generatora o wystarczającej entropii jest trudne bez pójścia na skróty. Kilka specjalnych instrukcji służących do zapisywania tagów wymaga własnej ścieżki w układzie, zamiast ponownego wykorzystania zwykłej ścieżki.
Proszę wyobrazić sobie rdzeń procesora działający w trybie „out-of-order” jako kuchnię, w której kilku kucharzy pracuje jednocześnie nad różnymi elementami zamówienia, niekoniecznie w kolejności, w jakiej zamówienie zostało złożone, o ile nic nie zależy od elementu, który nie jest jeszcze gotowy. Właśnie w ten sposób nowoczesny rdzeń działający w trybie out-of-order zazwyczaj zachowuje wysoką szybkość: nie czeka bezczynnie, lecz wykonuje wszystkie możliwe operacje, podczas gdy wolniejsze etapy nadrabiają zaległości.
Ścisły tryb SYNC w MTE wprowadza zakłócenie do jednej z części tej „kuchni”: zapisu do pamięci. Zazwyczaj rdzeń może zapisywać dane do pamięci i kontynuować pracę nad kolejnymi instrukcjami, podczas gdy zapis ten jest kończony w tle. Jednak w trybie MTE SYNC każdy zapis wymaga najpierw sprawdzenia i potwierdzenia poprawności swojego małego znacznika, a dopóki ta kontrola nie zostanie zakończona pomyślnie, rdzeń nie może przejść do następnego zapisu. Nie oznacza to, że cała „kuchnia” całkowicie się zatrzymuje: „gotowanie” (odczyty, obliczenia, rozgałęzienia itp.) przebiega bez zakłóceń w trybie nieuporządkowanym. Chodzi konkretnie o etap „odstawiania gotowego talerza”, który musi teraz odbywać się pojedynczo, po kolei, przy czym za każdym razem konieczne jest oczekiwanie na sprawdzenie znacznika. Kod, który wielokrotnie zapisuje dane do pamięci w ciasnej pętli, odczuwa to nieustannie – właśnie dlatego niektóre testy wydajnościowe wykazały spowolnienie nawet do 6,64-krotnego. Kod, który głównie odczytuje, oblicza lub wykonuje rozgałęzienia, praktycznie tego nie zauważa, ponieważ część potoku, która uległa spowolnieniu, nie jest tą, na której się opiera.
Nawet w trybie lekkim MTE standardowy rdzeń typu „Big” nadal odnotowywał spowolnienia sięgające nawet 1,82-krotności, a jest to dokładnie ten tryb, z którego obecnie korzysta funkcja Advanced Protection firmy Google. Tymczasem zarówno układ serwerowy Ampere, jak i nowy układ M5 firmy Apple praktycznie nie odczuwały włączenia funkcji MTE, odnotowując średnio jedynie 2–3% obciążenia dodatkowego, przy spowolnieniu wynoszącym w najgorszym przypadku 10%. Ta różnica dowodzi, że spowolnienia te nie są nieuniknionym prawem fizyki; odzwierciedlają one, jak dobrze (lub źle) inżynierowie danego układu wdrożyli tę funkcję. A znając Tensor, nie oczekujemy od niego zbyt wiele.
Ktoś sprawdził program rozruchowy i rzeczywiście, zniknął.
Obecnie istnieją na to dowody wykraczające poza same zapewnienia firmy GrapheneOS. Programista znany pod pseudonimem Romashka, prowadzący również kanał Mystic Leaks na Telegramie, przeanalizował programy rozruchowe modeli Pixel 10 (wewnętrzna nazwa kodowa „deepspace”) oraz Pixel 11 („spacecraft”) za pomocą deasemblera – narzędzia, które przekształca skompilowany kod z powrotem w formę częściowo czytelna. W bootloaderze modelu Pixel 10 skrót MTE pojawia się wszędzie: w nazwach funkcji, takich jak „gs_mte_enable”, komunikatach debugowania, takich jak „MTE cmdline override ON”, a nawet w ukrytych poleceniach, takich jak „fastboot_oem_cmd_mte”.

Jeśli poszukają Państwo tych samych elementów w bootloaderze modelu Pixel 11, nie znajdą Państwo niczego. Ani śladu. To dość znacząca różnica: gdyby firma Google po prostu przełączyła przełącznik, aby wyłączyć MTE, nadal należałoby oczekiwać, że te nazwy funkcji i komunikaty pozostaną w kodzie, choćby jako nieużywane. Ich całkowity brak sugeruje, że kod został całkowicie usunięty, a nie tylko wyłączony. Potwierdza to dokładnie to, co stwierdził GrapheneOS po rezygnacji z portowania.
Z ujawnionych dokumentów wewnętrznych wynika, że technologia MTE miała zostać zastosowana w procesorze Tensor G6, ale ostatecznie zrezygnowano z tego pomysłu
Liczne ujawnione dokumenty wewnętrzne zespołu Google zajmującego się układami scalonymi, znanego wewnętrznie jako gChips, pochodzące sprzed kilku lat, wskazują, że technologia MTE została uwzględniona na wczesnym etapie, a następnie celowo usunięta.
Bardzo stara slajdowa prezentacja planu rozwoju „Malibu” – wewnętrznej nazwy kodowej procesora G6 – wymienia technologię MTE jako część podstawowej specyfikacji procesora, przedstawiając ją jako „Hela (własny system połączeń rdzeni Google) + MTE w SLC”. Wskazuje to na inny ujawniony slajd zatytułowany „Specyfikacja architektury pamięci podręcznej na poziomie systemu Google (GSLC)”, którego historia zmian sięga maja 2022 roku. W ramach listy „Funkcje P0” – oznaczającej najwyższy priorytet – dokument wymienia „obsługę MTE” jako drugą pozycję, przekreśloną na czerwono. Nie wiemy, kiedy dodano to przekreślenie, ale wiemy, że firma Google planowała inną implementację MTE dla G6 i dopracowywała ją, zanim z nieznanych powodów zrezygnowała z tego rozwiązania.
Odpowiedź firmy Motorola ma swoją nazwę: Wukong
Z kolei firma GrapheneOS finalizuje umowę z Motorolą, mającą na celu po raz pierwszy wprowadzenie tego systemu operacyjnego do telefonu innego niż Pixel, podczas gdy Qualcomm rozpoczęła dodawanie obsługi MTE do swoich najnowszych układów, w tym do Snapdragon 8 Elite Gen 5.
Serwis NotebookCheck dowiedział się, że firma Motorola pracuje nad flagowym telefonem o wewnętrznej nazwie kodowej „Wukong”, opartym na kolejnym flagowym układzie firmy Qualcomm – Snapdragon 8 Elite Extreme Gen 6 (SM8975) – który ma zostać w pełni zaprezentowany podczas konferencji Snapdragon Summit 22 września. Na chwilę obecną jest to jedyne urządzenie Motoroli planowane z wykorzystaniem tego procesora. Jeśli „Wukong” okaże się telefonem, na którym Motorola wprowadzi system GrapheneOS, będzie to pierwszy telefon łączący pełną obsługę MTE, flagowy układ Qualcomm oraz obsługę GrapheneOS – coś, czego obecnie nie można uzyskać w modelu Pixel 11, niezależnie od tego, ile się za niego zapłaci.
Należy jednak pamiętać o standardowym zastrzeżeniu: na tak wczesnym etapie rozwoju specyfikacje, a nawet nazwa kodowa „Wukong”, pochodzą z materiałów wewnętrznych i mogą ulec zmianie, zanim informacje te zostaną oficjalnie potwierdzone. Firma Motorola nie potwierdziła jeszcze istnienia tego telefonu.
I ostatnia, ale nie mniej ważna kwestia: czy MTE rzeczywiście ma duże znaczenie dla większości osób?
Dla przeciętnego nabywcy modelu Pixel 11 utrata funkcji MTE nie stanowi, moim zdaniem, takiej katastrofy, jak mogłoby to wynikać z treści tego artykułu.
Funkcja MTE opiera się na prawdopodobieństwie, a nie stanowi twardej gwarancji. Istnieje 1 szansa na 16, że dany dostęp poza zakresem całkowicie ominie kontrolę tagu, a badania przytoczone w tym samym artykule (TikTag) ujawniły poufność tagów na rzeczywistym sprzęcie Pixel przy użyciu wykonywania spekulatywnego, co oznacza, że nawet oferowana przez tę funkcję ochrona nie jest w praktyce tak niezawodna, jak sugeruje stosunek „15/16”. Co więcej, co ma kluczowe znaczenie, prawie żadne z zagrożeń, o które przeciętny właściciel telefonu faktycznie powinien się martwić, nie dotyczy w ogóle błędów związanych z bezpieczeństwem pamięci. Phishing, złośliwe uprawnienia aplikacji, podmiana karty SIM, oprogramowanie szpiegujące oraz przejęcia kont – żadna z tych zagrożeń nie wchodzi w zakres ochrony zapewnianej przez MTE. Nawet sam GrapheneOS przyznaje, że ochrona aplikacji innych producentów jest opcjonalna i rzadko wykorzystywana; aplikacja Signal nie włącza tej funkcji.
MTE naprawdę sprawdza się w modelu zagrożeń, dla którego stworzono sam system GrapheneOS: kosztowne, oparte na niezawodności łańcuchy exploitów typu „zero-click”, sprzedawane za miliony dolarów i wykorzystywane niemal wyłącznie przeciwko dziennikarzom, dysydentom oraz celom rządowym, a nie przeciętnemu konsumentowi. To rzeczywisty i istotny przypadek zastosowania. Jest on po prostu wąski. Telefon, który ulega awarii zamiast zostać po cichu przejęty, ma naprawdę ogromne znaczenie, jeśli jest Pan/Pani celem wysokiego ryzyka, nad którym czuwa podmiot państwowy. Ma to znacznie mniejsze znaczenie, jeśli rzeczywistym zagrożeniem jest zgubienie telefonu w barze lub kliknięcie złośliwego linku w wiadomości tekstowej. Stosowanie dobrych praktyk OPSEC, używanie unikalnych haseł, unikanie przypadkowych kodów QR oraz nierozpowszechnianie swoich danych osobowych na każdej stronie internetowej, która o nie prosi, zapewnia większą ochronę w rzeczywistości dla większości osób niż jakakolwiek funkcja bezpieczeństwa pamięci na poziomie układu scalonego kiedykolwiek zapewni.
Żadna z tych kwestii nie sprawia jednak, że regresja układu scalonego w modelu Pixel 11 przestaje być ważnym tematem. Grono użytkowników GrapheneOS to właśnie ta grupa, dla której ma to największe znaczenie, a utrata wsparcia dla całej generacji urządzeń Pixel stanowi poważny cios dla tego projektu. Warto jednak szczerze przyznać, że MTE wydaje się raczej być wysokowartościowym środkiem zabezpieczającym dla przedsiębiorstw lub użytkowników z grup wysokiego ryzyka, który przypadkowo trafił do układów scalonych przeznaczonych dla konsumentów, niż funkcją, której braku zauważyłaby przeciętna osoba kupująca Pixel 11. Istnieje też pewna ironia w tym, jak firma Google znalazła się w tej sytuacji: to właśnie ona jako pierwsza wprowadziła technologię MTE do głównego nurtu, wdrażając ją w procesorze Tensor niemal przed wszystkimi innymi producentami urządzeń z systemem Android, finansując badania nad nią oraz tworząc wokół niej cały tryb zabezpieczeń. Teraz jej własne dokumenty wewnętrzne sugerują, że wbudowała technologię MTE w swój kolejny układ, szczegółowo ją opisała, a następnie po cichu zrezygnowała z niej przed premierą. Nikt nie prześcignął Google’a pod tym względem. Firma sama pozbawiła się tej funkcji.










