02.09.2018 | 18:58

Adam Kostrzewa

Bezpieczeństwo czy wydajność? Jakie decyzje podejmą producenci procesorów

Ostatni rok obfitował w informacje o wykryciu nowych luk związanych z architekturą procesorów. W większości przypadków są one trudne do usunięcia bez straty wydajności. Jak z tymi problemami chcą sobie poradzić najwięksi producenci układów scalonych?

Dnia 21 sierpnia tego roku zakończyła się trzydziesta edycja konferencji Hot Chips, na której czołowi producenci sprzętu, np. Intel, Nvidia, AMD i ARM, przedstawiali swoje nowe architektury i produkty. Jednym z głównych tematów były mechanizmy zapobiegania Spectre i Meltdown. Ataki kanałami bocznymi są znane i praktykowane od lat siedemdziesiątych. Istnieje jednak istotna różnica pomiędzy Spectre i Meltdown a wcześniejszymi zagrożeniami — w przeszłości celem większości tego typu ataków była warstwa aplikacji, czyli oprogramowanie. Teraz obiektem zainteresowania stała się platforma sprzętowa, na której kod jest wykonywany. Luki sprzętowe można łatać (przynajmniej częściowo) za pomocą oprogramowania, czego dowodzą najnowsze wyniki związane ze Spectre i Meltdown. Jest to jednak czasochłonne, kosztowne, a także odbywa się przy znaczącym spadku wydajności.

„Aby uniknąć luk, należy albo dodać dodatkowe zapytania do architektury procesora albo zapobiec spekulacyjnemu wykonywaniu kodu”, powiedział podczas konferencji John L. Hennessy, rektor (prezydent) Uniwersytetu Stanforda, znany autor książek z dziedziny architektury komputerów, jak i ojciec architektury RISC obecnie stosowanej w 99% nowych układów scalonych (za co w zeszłym roku otrzymał nagrodę Turinga). Obie metody mają wady. Zmiana mechanizmów sprzętowych wymaga wymiany sprzętu w całej organizacji. Jest to drogie, a często wiąże ze sobą problemy z kompatybilnością wsteczną i samym transferem danych, jak również nie wyklucza spadku wydajności o 15–20 procent. Wyłączenie spekulacyjnego wykonania kodu wiąże się ze zdecydowanym spadkiem wydajności w wielu aplikacjach, często o ponad 30 procent. Ten spadek jest nie do zaakceptowania dla większości użytkowników.

Czy nie ma zatem żadnych pozytywnych wiadomości? Na szczęście są. Po pierwsze, wyciek danych w atakach przeprowadzony za pomocą tych luk jest w większości scenariuszy czasochłonny. Na przykład NetSpectre, atak zdalny bazujący na podatności Spectre, prowadzi do wycieku danych z serwerów ze średnią prędkością ok. 1 bitu na minutę (wartość zależy od konkretnej realizacji). Z drugiej strony, średni czas pomiędzy penetracją serwera a wykryciem włamania wynosi obecnie 100 dni. Wyniki są efektem najnowszych badań Johna Hennessego.

Po drugie, wyniki Google Project Zero przedstawione przez Paula Turnera uspokajają i wskazują na to, że siła ataku była znacznie przeceniona – szczególnie bezpośrednio po prezentacji luk dla szerszej publiczności. Przez ostatnie miesiące wszystkie opublikowane modele wykorzystania luk ograniczają się do wycieku danych z pamięci. Ataki, które manipulują danymi w pamięci albo wprowadzają złośliwy kod do wykonania, pozostają wciąż w sferze teorii i spekulacji. Miejmy nadzieję, że tak pozostanie.

Niestety przez ostatnie osiem miesięcy okazało się również, że przy opisie możliwych konsekwencji ataku opierano się często na fałszywych przesłankach. Zakładano, że spekulacyjne wykonywanie kodu nie pozostawia śladów, gdy prognoza jest błędna, ponieważ wyniki zostają odrzucone. To ostatnie twierdzenie jest prawdziwe tylko dla logiki programu – nie występują błędy obliczeniowe. Stany w procesorze są jednak inne niż w przypadku prawidłowej prognozy. Ponadto, dzięki stale zwiększającej się pojemności pamięci głównych, dane są często posortowane i bezpośrednio adresowalne – atakujący nie musi już pracować z oknami i zakresami obszarów pamięci. Oba czynniki znacznie ułatwiają przeprowadzanie ataków.

Zmiany paradygmatów w przyszłych architekturach sprzętowych

Dotychczas przedstawione rozwiązania dla problemów związanych z Spectre i Meltdown jednoznacznie wskazują na to, że dotychczasowe podejście – ścisły podział zadań pomiędzy sprzęt i oprogramowanie – staje się obecnie głównym źródłem problemów. Jak stwierdził Jon Masters z firmy Red Hat, myślenie w kategoriach „my” i „oni” w stosunku do twórców sprzętu i oprogramowania wydaje się w dłuższej perspektywie nie do utrzymania. Jest to związane z poziomem abstrakcji wpływającym na jakość mechanizmów bezpieczeństwa. Prawie cała poprawa wydajności współczesnego procesora wynika z agresywnych metod optymalizacji, takich jak wykonywanie poza kolejnością (ang. out-of-order execution) czy spekulacyjne wykonywanie kodu. Mimo że warstwa aplikacyjna ma wprowadzone mechanizmy bezpieczeństwa (np. prawa dostępu, kolejność wykonania), sprzęt je w dużej mierze ignoruje w procesie optymalizacji wykonania kodu. Prowadzi to do niwelowania działania programowych mechanizmów bezpieczeństwa i pojawiania się kolejnych luk. Ponadto agresywna optymalizacja jest trudna do kontroli dla programistów. Jest ona bowiem zaprzeczeniem sekwencyjnego przetwarzania kodu implementowanym przez większość kompilatorów kodów i modeli programowych. W rezultacie programiści języków wysokopoziomowych są często nieświadomi ograniczeń i właściwości platformy sprzętowej, na której pracują i tracą kontrolę nad wykonywanym kodem maszynowym. Jak wyjaśnił Mark Hill z Uniwersytetu Wisconsin, oddzielenie sprzętu i oprogramowania zapewniało w przeszłości praktyczną budowę modularną systemu zorientowaną wokół modelu programowego procesora ISA (od ang. instruction set architecture) z jasno określonym podziałem ról. Aplikacje były tworzone dla konkretnego zestawu instrukcji, a twórcy procesorów dbali o jak najszybsze wykonanie tych instrukcjiJednak rozwiązanie wyżej wymienionych problemów prowadzi do nowej architektury, w której sprzęt i oprogramowanie ponownie zbliżają się do siebie.

Jedną z popularnych koncepcji dla przyszłych architektur sprzętowych są dodatkowe tryby pracy procesora, np. rozróżnienie trybu szybkiego i bezpiecznego. W tym drugim przypadku, procesor używa buforowania i wykonania spekulacyjnego tylko w ograniczonym zakresie. Alternatywą jest wykorzystanie multi-procesorowych architektur heterogenicznych, w tym łączenie różnych rdzeni o różnych charakterystykach bezpieczeństwa. Na Hot Chips dyskutowano również o nowych modelach biznesowych, np. maszyny wirtualne na bezpiecznych, ale wolnych serwerach za dodatkową opłatą. Na koniec warto zauważyć, że przejście do otwartych architektur typu open source może wydarzyć się również dla sprzętu (nowe koncepcje bezpieczeństwa na procesorach RISC-V), przynosząc konkretną poprawę mechanizmów bezpieczeństwa – tak jak dzieje się to w przypadku oprogramowania.

Konkretne rozwiązania?

Jak dyskusje projektantów i badaczy przekładają się na konkretne wdrożenia? Jako jeden z nielicznych, Intel w swojej prezentacji na konferencji przedstawił konkretne rozwiązania i mechanizmy. Trzeba jednak dodać, że miejsce i czas nie są przypadkowe. Wygląda na to, że prace nad obiecanymi na koniec 2018 roku architekturami odpornymi na ataki „spekulacyjne” prowadzone są bardzo intensywnie – chociaż nie można wykluczyć opóźnień. Pierwszą serią zawierającą tego typu rozwiązania powinna być rodzina procesorów Cascade Lake SP do implementacji serwerowych. Spekuluje się również o wprowadzeniu mechanizmów bezpieczeństwa do ośmiordzeniowego i-9000 (LGA1151v2) oraz chipów z rodziny „Whiskey-Lake” przeznaczonych do notebooków i laptopów.

Nazwa techniczna Nazwa zwyczajowa Umiejscowienie mechanizmu bezpieczeństwa dla platformy Cascade Lake
Spectre V1 Bounds Check Bypass System operacyjny / hypervisor
Spectre V2 Branch Target Injection (BTI) Mechanizm sprzętowy + system operacyjny / hypervisor
Meltdown (V3) Rogue Data Cache Load Mechanizm sprzętowy
Spectre V3a Rogue System Register Read Sterowniki
Spectre V4 Speculative Store Bypass Sterowniki + system operacyjny / hypervisor albo oprogramowanie
Spectre-NG L1 Terminal Faul (L1TF) Mechanizm sprzętowy

Rysunek 1. Umiejscowienie nowych mechanizmów bezpieczeństwa dla platformy Cascade Lake

W tabeli przedstawiono zestawienie mechanizmów, klasyfikując je na podstawie luki i wdrożenia (oprogramowanie, sprzęt lub oba). Mechanizmy wykonane w pełni sprzętowo zabezpieczają tylko przed Meltdown i niedawno wykrytym błędem L1 Terminal Fault (L1TF). W przypadku Spectre V2 (BTI) funkcje sprzętowe muszą współpracować z odpowiednimi łatkami systemu operacyjnego lub wirtualizacji oprogramowania nadzorcy (ang. hypervisor). Sprzętowych mechanizmów ochronnych nie przewidziano dla Spectre V1. W pozostałych przypadkach poprawki sterowników będą konieczne. Warto zauważyć też, że tylko jedną lukę z sześciu (Spectre V1) można usunąć w pełni programowo bez modyfikacji mechanizmów sprzętowych.

Rysunek 2. Spadki wydajności związane z nowymi mechanizmami bezpieczeństwa zaprezentowane przez firmę Intel, źródło: Intel

Wygląda też na to, że nie obędzie się bez spadków wydajności. Przedstawione wyniki – patrz Rysunek 2 – potwierdzają, że wyłączenie Hyper-Threadingu wymagane do zabezpieczenia przed L1TF znacząco zmniejsza wydajność procesorów Xeon w wielu aplikacjach (co było do przewidzenia). Spadki wydajności są największe w przypadku serwerów z wieloma maszynami wirtualnymi (ataków z użyciem złośliwych wirtualnych maszyn). Sprzętowe mechanizmy ochronne w większości wypadków zapewniają jednak zdecydowanie lepszą wydajność niż wcześniejsze poprawki, np. poprzez aktualizacje mikrokodów, udostępniane od początku roku.

Podsumowanie

Droga do rozwiązania problemów Spectre i Meltdown wydaje się długa, a cały proces kosztowny. Bez głębokich zmian w architekturze, wpływających na całe procesy produkcyjne, trzeba się liczyć ze stratami wydajności. Straty te są jednak w większości wypadków nie do zaakceptowania dla wielu obecnych klientów, np. dostawców usług internetowych. W związku z brakiem konkretnych rozwiązań dyskusje zaczynają być nie na rękę tak dla producentów sprzętu (drogie i ryzykowne inwestycje w nowe mechanizmy i rozwiązania), jak i oprogramowania (trzeba tłumaczyć klientom, dlaczego wirtualne maszyny nie spełniają wszystkich norm bezpieczeństwa bądź z dnia na dzień podnosić ceny). Dyskusje medialne stają się zatem bardziej wyważone i stonowane. Coraz rzadziej słyszy się żądania bezwarunkowej rezygnacji ze spekulacyjnego wykonywania kodu na maszynach serwerowych – czego żądano w styczniu tego roku.

Artykuł opiera się na źródłach prasowych heise.de, eetimes, jak również na oficjalnych źródłach organizatorów konferencji. Na stronie konferencji można także znaleźć nagrania wideo z jej najciekawszych dyskusji.

O autorze

Adam Kostrzewa: Od ośmiu lat zajmuję się badaniami naukowymi i doradztwem przemysłowym w zakresie elektroniki motoryzacyjnej, a w szczególności systemów wbudowanych pracujących w czasie rzeczywistym do zastosowań mogących mieć krytyczne znaczenie dla bezpieczeństwa użytkowników. W wolnym czasie jestem entuzjastą bezpieczeństwa danych. Szczególnie interesujące są dla mnie sprzętowe aspekty implementacji obwodów elektrycznych i produkcji krzemu. Metody i narzędzia używane do tych zadań nie są aż tak dostępne i dokładnie przetestowane jak oprogramowanie, dlatego też stanowią interesującą dziedzinę do badań i eksperymentów.

Blog: adamkostrzewa.github.io

Twitter: twitter.com/systemWbudowany

Powrót

Komentarze

  • 2018.09.02 19:23 jozek

    Wydajność. Przecież to oczywiste. Wszystkie problemy z bezpieczeństwem procesorów, wymagają bezpośredniego dostępu do procesora, pamięci i jednocześnie do systemu. Nie ma sposobów „zdalnych”, a jak nie można zdalnie, to nie ma problemu. Dodatkowo klasa zaawansowania ataków na procesory czy inne mikrokontrolery jest na tyle duża, że zawęża popisy tylko do wysoce wyspecjalizowanych grup. Co więcej, były te problemy uwzględnione w systemach bezpieczeństwa (izolowanie dostępu, zagnieżdżenie software’owe, kontrola cykliczna, odświeżanie wartości etc. itd. itp.) na początku lat 90.

    Problem zabezpieczeń w systemach wbudowanych nie jest tożsamy z problemem zabezpieczeń w systemach multifunkcjonalnych. Zresztą, kto normalny przy projektowaniu systemu wbudowanego wykorzystuje procesor X86?

    Odpowiedz
    • 2018.09.03 14:06 Po Prostu Janusz

      3 lata temu wymieniłem moduł komunikacyjny do sterowników PLC (chyba Siemens albo Allen Bradley) oparty na 386. Do tej pory ich używamy w pracy.

      Odpowiedz
  • 2018.09.02 20:18 heneik

    AMD nie jest podatne na wymienione luki a tekst wprowadza w błąd

    Odpowiedz
    • 2018.09.03 03:59 Artur

      Na Meltdown nie są podatne. Na Spectre (a przynajmniej niektóre z odmian) niestety już tak.
      Mówię to jako osoba życząca AMD jak najlepiej.

      Odpowiedz
    • 2018.09.03 10:37 Adam Kostrzewa

      Nie ma błędu. Niestety tak jak napisał Artur AMD jest podatne na Spectre. Na oficjalnej stronie Google Project Zero możemy przeczytać ” In particular, we have verified Spectre on Intel, AMD, and ARM processors.” (https://meltdownattack.com/). Z Meltdown jest tak że AMD twierdzi że podatności nie ma a Google jeszcze nie zweryfikował, cytat „Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether AMD processors are also affected by Meltdown.” Zachęcam również do sięgnięcia do oficjalnych komunikatów prasowych firmy AMD https://www.amd.com/en/corporate/security-updates

      Odpowiedz
  • 2018.09.03 12:28 zakius

    wydajność
    niestety dzisiejsze szeroko pojęte oprogramowanie (wliczając webaplikacje, cudaki w electronie a nawet wiele teoretycznie prostych stron internetowych) są tak źle (leniwie?) pisane, że wbrew zachwytom blogerów nad netbookami z core u do komfortowego korzystania z nich potrzeba naprawdę potężnej maszyny

    Odpowiedz
  • 2018.09.03 20:21 Mariusz

    Odpowiedź na pytanie w tytule niniejszego artykułu brzmi: maksymalizacja zysku akcjonariuszy.

    Odpowiedz
  • 2018.09.04 01:30 Grzegorz

    W witrynie Phoronix pojawił się bardzo ciekawy artykuł porównujący wydajność różnych procesorów serwerowych przed i po włączeniu zabezpieczeń przed lukami w jądrze linuxa 4.19: https://www.phoronix.com/scan.php?page=article&item=linux-419-mitigations&num=1

    W określonych zastosowaniach spadek wydajności jest wyraźnie odczuwalny na procesorach od intela, AMD traci minimalnie.

    Ciekaw jestem jak spadek wydajności wpłynie na postrzeganie cen całych platform opartych o rozwiązania intela. Ich najbardziej zaawansowane procesory są bardzo drogie. Kupujemy platformę o wydajności X w cenie Y. Po wdrożeniu zabezpieczeń mamy wydajność 0,85X w tej samej wysokiej cenie, ale odpowiadający jej procesor można kupić znacznie taniej. Przy dużych wdrożeniach straty będą wyraźne. Kto kupującemu zwróci pieniądze?

    Odpowiedz
  • 2018.09.04 08:11 Gal

    Wiadomo iż rynek wymusi wydajność kosztem bezpieczeństwa. Jeżeli ktoś mi się wbije na serwer to i tak pozamiatane i tak pozamiatane. Głównym odbiorcom i zagrożeniem są po prostu rozwiązania chmurowe które nie są w stanie zapewnić bezpieczeństwa. Niestety firmy które poszły w chmury, a przetwarzają dane wrażliwe, muszą się zastanowić nad powrotem do własnych serwerowni. Ale może się stać jeszcze coś innego. Widzę tutaj duże pole do popisu dla IBM-a i ich platform Power oraz wirtualizacji LPAR. Do tej pory nie znalazłem informacji o tym iż procesory Power są podatne na Spectre i Meltdown. Tak więc na rynku jest od dawna platforma która jest wydajna i bezpieczna. Co do użycia x86 w systemach wbudowanych – niestety smutna prawda jest taka iż olbrzymia ilość sterowników PLC jest oparta o x86, do tego są całe sieci bankomatowe, biletomaty, sterowniki tramwajów – to wszystko są x86. Dlaczego? Bo po prostu łatwiej jest utrzymać stos technologiczny dla deweloperów. Deweloperka na windows, C#, bezpośredni dostęp do zdalnych obiektów przez DCOM – OPC które ułatwiają zbudowanie rozwiązania SCADA. Ciężko na rynku znaleźć alternatywę. ARM-y też są podatne ale fakt, coś się powoli rusza i zmienia w kierunku odejścia od platformy Windows i x86, głównie dlatego iż M$ ubił całą linię produktową Embedded pozostawiając tylko Windows 10 Embedded, który się kompletnie nie nadaje do takich rozwiązań.

    Odpowiedz
    • 2018.09.04 15:29 jozek

      Nie zgodzę się, za szybko się posłużyłeś dedykacją PLC do systemów wbudowanych. Systemy wbudowane głównie rozwijają się obecnie o CPLD, FPGA i nowej generacji PAL. Definicja systemów wbudowanych sama z siebie ZMUSZA układ do wykonywania sprecyzowanych operacji (nawet tylko jednej).

      Masz rację, że sterowniki robi się na PLC, ale właśnie – sterowniki, jakieś pomiary temperatur, sygnalizatory, BMSy, interfacy wymiany informacji/danych, czy tak jak wymieniłeś bankomaty itp. Ale to nie koniecznie są systemy wbudowane.

      Niestety, systemy wbudowane robi się głównie dla procesu produkcyjnego i tam PLCków się nie używa, chociażby dlatego, że układy oparte na PLC prawie nigdy nie są typu FT (fault tolerant), a przynajmniej zrobienie FT jest drogie i trudne.

      Oczywiście, nie mam nic przeciwko, jeżeli ktoś chce zbudować sobie system wbudowany na PLC, ale… no z mojej perspektywy, nie ma nic lepszego niż bramka AND/OR i sądzę, że wiele osób, które rozpoczynały swoją przygodę z IT w latach 90 się ze mną zgodzi :3

      Odpowiedz
      • 2018.09.05 22:53 Po Prostu Janusz

        @jozek
        To nie sterowniki robi się na PLC tylko PLC jest sterownikiem. Jak sama nazwa wskazuje: Programmable Logic Controller.
        To nie PLC jest dedykowane do systemów wbudowanych tylko PLC są systemem wbudowanym.
        Na produkcji używa się PLC na potęgę – mówię z doświadczenia na utrzymaniu ruchu.
        Systemy wbudowane przeszły długą drogę od lat ’90.

        Odpowiedz
        • 2018.09.10 19:16 jozek

          Rację masz. Nie chce mi się tłumaczyć mojej logiki, która doprowadziła mnie do błędnych wniosków i założeń.

          Odpowiedz
  • 2018.09.04 10:06 kaka

    Analizujac to jak powstanie procesor, co trzeba zrobic zeby go zaprojektowac a juz na pewno proces produkcji wafla. To ja nie wierze, ze to sa dziury. To sa celowe zabiegi, ktore po prostu wychodza teraz na jaw z jakiegos powodu.

    Odpowiedz
  • 2018.09.04 10:16 Pawel

    Mnie swego czasu zaciekawilo to jak naprawde zmienila sie wydajnosc procesorow przez ostatnie lata – i zaskoczylo ze w pewnych skrajnych przypadkiach skok w segmencie 'procesorow poopularnych’ wcale nie byl jakis oszalamiajacy. Pomierzylem to na swoim starym programiku matematycznym: https://pawelgorny.com/sparse-matrix-lu-decomposition-problem/

    Odpowiedz
    • 2018.09.04 15:03 Artur G.

      Ja bym raczej obstawiał, że nie używasz wielowątkowości w swoim programiku. Wyścig zbrojeń wśród CPU dotyczy teraz przede wszystkim liczby rdzeni i równoległego przetwarzania (stąd np w grach nadal lepsze bywają CPU z mniejszą liczbą rdzeni, ale szybszym taktowaniem, podczas gdy w przypadku zastosowań serwerowych jest zupełnie odwrotnie)

      Odpowiedz
      • 2018.09.04 15:19 jozek

        W zasadzie, nie wiele się myli. Przecież już od dawna nie obowiązuje prawo Moore’a, więc wydajność pojedynczego rdzenia nie rośnie, bo nie ma takiej fizycznej (tranzystorowej) możliwości.

        Masz racje, że firmy skupiają się na wielowątkowości i procesy wykorzystujące wielordzeniowość wykonują się znacznie szybciej, niż jeszcze 10 lat temu.

        Ale głównie, czym się zajmowali to optymalizacją instrukcji i rozkazów oraz układami tranzystorów w jednostkach.

        Wydajność pojedynczego rdzenia powinna wzrosnąć w przyszłym roku – 10nm proces technologiczny Intela, już w 2016 roku AMD zapowiadało proces 7nm, poprawa architektury i powinno być lepiej.

        Prawda jest jedna, różne procesory mają różne zastosowanie.

        Odpowiedz

Zostaw odpowiedź do kaka

Jeśli chcesz zwrócić uwagę na literówkę lub inny błąd techniczny, zapraszamy do formularza kontaktowego. Reagujemy równie szybko.

Bezpieczeństwo czy wydajność? Jakie decyzje podejmą producenci procesorów

Komentarze