Dziura z procesorach Intela pozwala na kradzież danych z L1
W procesorach Intela odkryto kolejną lukę. Dziura nazwana CacheOut to luka typu side-channel, czyli błąd pozwalający na wykorzystanie pewnych szczegółów, często prawidłowej, implementacji.
Dziura odkryta przez naukowców z University of Michigan i University of Adelaide występuje we wszystkich procesorach od architektury SkyLake po Coffee Lake powstałych przed rokiem 2019. Wiadomo, że nie występuje ona w procesorach AMD, ale badacze nie wykluczają, że jest obecna w układach IBM-a i ARM.
Jak zauważyli eksperci gdy dane są pobierane z cache'u L1 często trafiają do buforów, z których mogą zostać wykradzione przez napastnika. Bardzo atrakcyjnym elementem CacheOut jest fakt, że napastnik może zdecydować, które dane z L1 zostaną umieszczone w buforze, skąd dokona kradzieży. Specjaliści wykazali, że możliwy jest wyciek danych mimo wielu różnych zabezpieczeń. w tym zabezpieczeń pomiędzy wątkami, procesami, wirtualnymi maszynami, przestrzenią użytkownika a jądrem systemu.
Intel, który o problemie został poinformowany już w ubiegłym roku, sklasyfikował lukę L1D Eviction Sampling/CVE-2020-0549/INTEL-SA-00329 jako średnio poważną i przygotował odpowiednie poprawki. Odpowiedni mikrokod zostanie upubliczniony a nwjbliższym czasie. Tymczasowym obejściem problemu jest wyłączenie wielowątkowości lub wyłączenie rozszerzenia TSX.
Komentarze (11)
wilk, 29 stycznia 2020, 14:44
Skutecznym rozwiązaniem jest zaprzestanie używania dziurawych procesorów.
Który to już spadek wydajności ich procesorów?
tempik, 29 stycznia 2020, 16:12
No niestety, większość ich łatek (przynajmniej programowych) to robienie kroku w tył jeśli chodzi o wydajność
cyjanobakteria, 29 stycznia 2020, 18:44
Implementacja w sofcie jest prawie zawsze mniej wydajna, ale za to tańsza i to jedyne wyjście, dopóki nie zaprojektują nowych układów. Od stycznie 2018 nic nie jest już takie same w bezpieczeństwie CPU
Cieszę się, że AMD się odbił i wyszedł na prowadzenie w wydajność jak i bezpieczeństwo nowych układów. Mam sentyment do ich CPU, ale głównie dlatego, że monopol nikomu nie służy... No może z wyjątkiem chipzilli ![:) :)](https://forum.kopalniawiedzy.pl/uploads/emoticons/default_smile.png)
efdhih, 29 stycznia 2020, 20:02
Czyli kolejny spadek IPC w Intelu, w AMD już jest wyższy. Intel to taka gigantyczna nokia z dużą ilością kasy i olbrzymią bezwładnością, ale jak przekroczą pewną granicę to też upadną.
cyjanobakteria, 30 stycznia 2020, 22:15
Bez przesady, dla użytkownika końcowego różnica praktycznie nie będzie zauważalna. Na pewno Intel od tego nie upadnie, chociaż powinien zejść z ceny. Dobrze więc, że AMD jest tak blisko, parafrazując klasyka![:) :)](https://forum.kopalniawiedzy.pl/uploads/emoticons/default_smile.png)
Pamiętam, że w przypadku ataków Meltdown i Spectre z 2018, softwarewe poprawki pod Linuksem spowodowały wyraźny spadek wydajności tylko w określonych i dosyć rzadkich zastosowaniach. Na przykład agresywny zapis na dysku, benchmark Postgresql symulujący wysokie obciążenie serwera bazodanowego. Generalnie wszystko, co wymagało wywoływań systemowych (syscall). Więc to nie jest typowe zastosowanie dla komputera domowego.
wilk, 31 stycznia 2020, 07:37
Wyłączenie (tymczasowe) wielowątkowości będzie niezauważalne? No to ktoś nie pogra jak dawniej.
cyjanobakteria, 31 stycznia 2020, 13:54
To jest HT (hyper-threading) a nie multi-threading, co nie jest to sprecyzowane w przetłumaczonym artykule. HT to jest żonglowanie schedulera w fizycznym rdzeniu procesora w celu optymalizacji wykonywania kodu, więc nie ma aż tak drastycznego wpływu na wydajność. Można też wyłączyć TSX.
Mi chodziło o spadek wydajności po zaaplikowaniu łaty firmware (microcode). Lepiej jest poczekać na aktualizację, zwłaszcza, że podatność jest lokalna, czyli trzeba zainstalować złośliwe oprogramowanie, ewentualnie przyjąć update do już zainstalowanego programu, który wprowadza backdoora.
peceed, 31 stycznia 2020, 15:15
Hyper-threading to nazwa marketingowa dla SMT u intela i jest to jak najbardziej wielowątkowość na poziomie procesora, nie da się wyłączyć tej na poziomie systemu operacyjnego bo komputer przestałby być używalny.
Ma dramatyczny wpływ na wydajność, SMT to średnio +25% wydajności. Pewne aplikacje nawet więcej.
HT to jednoczesne wykonywanie dwóch wątków obliczeniowych (niezależnych strumieni instrukcji), co z jednej strony lepiej pozwala wykorzystać jednostki wykonawcze gdyż często brakuje niezależnych instrukcji do wykonania w ROB (reorder buffer) aby wykorzystać wszystkie dostępne zasoby, a z drugiej strony pozwala błyskawicznie amortyzować brak danych w cache i konieczność oczekiwania na dostęp do pamięci co zajmuje nawet kilkaset cykli, w tym czasie procesor ma prawie zawsze drugi wątek do wykorzystania.
Ciężko aby wyłączenie spekulacji na dostępie do pamięci nie powodowało spadku wydajności, to był główny powód przewagi Intela nad AMD (ryzyko było znane od początku, ewentualne wyłączenie funkcjonalności musiało być planowane).
To nie był "bug", tylko "feature". Nie ma prostego rozwiązania. Trzeba by używać do spekulacji dodatkowych niezależnych zasobów najlepiej wydzielonych dla każdego wątku, jest to bardzo trudne do wykonania, wymaga przeprojektowania podstaw architektury, trzeba stworzyć specjalne bufory tylko na potrzeby spekulatywnego wykonania, każda spekulacyjnie ściągnięta linia pamięci powinna lądować w buforze pośrednim i dopiero po zaakceptowaniu spekulacji być przenoszona do cache (a slot w hierarchii niżej zwalniany).
Zostanie to zrobione, bo zyski ze spekulacji są za duże a innych metod podnoszenia wydajności nie ma. Ale na efekty będzie trzeba poczekać kilka lat, bo zaprojektowanie architektury od podstaw to co najmniej 5 lat. 2023 to najwcześniejsza możliwa data, chyba że zaczęli dłubać wcześniej niż publikacja luki. Być może jakieś półśrodki zmniejszające stratę do AMD (po wszystkich łatach są już w tyle) pojawią się wcześniej.
cyjanobakteria, 31 stycznia 2020, 17:02
Niedoszacowałem wpływu wyłączenia HT na wydajność. Zakładałem około 10%, ale przejrzałem kilka benchmarków i faktycznie w najgorszym wypadku to około 35%, ale w innych zastosowaniach jest mniejsze. W grach, w zależności od konfiguracji sprzętowej, ustawień i samej gry, od 0% do 30%. Starszy i tańszy sprzęt wypada gorzej pod tym względem.
Dodam jeszcze, że w ciągu roku po publikacji łat softwarowych dla Meltdown i Spectre, deweloperzy poprawili wydajność kernela Linuksa i powrócili do stanu sprzed M&S.
peceed, 31 stycznia 2020, 17:18
To zależy od tego, czy procesor jest wąskim gardłem przetwarzania. Jeśli i tak karta grafiki nie wyrabia, to będzie 0%.
Prawidłowo zrobione testy powinny zmniejszać rozdzielczość do minimum, jeśli chcemy wiedzieć o ile zwalnia kod gier.
Do tego gra powinna mieć odpowiednią ilość wątków z czym jest problem. Jeśli wyłączymy SMT a gra dostanie 4 pełne rdzenie mając 4 wątki, to możemy nawet zobaczyć przyspieszenie.
Co jest oczywiste jeśli pamięta się o wątkach i wąskich gardłach w systemie (na starszym/tańszym sprzęcie jest mniej zasobów).
W sumie z punktu widzenia użytkowników objawia się tam, gdzie boli najbardziej.
cyjanobakteria, 31 stycznia 2020, 18:54
Tak właśnie jest. W przypadku dobrze dobranego sprzętu, może to się wahać w zależności od tego ile NPC jest w okolicy, tryby gry, itd. Przesadziłem trochę z tym niezauważalnym spadkiem wydajności, ale pozostaje przy twierdzeniu, że przy ogromnej liczbie konfiguracji sprzętowych oraz obciążeń i zadań, typowy użytkownik nie odnotuje dużego spadku. Ja teraz mam obciążenie rzędu kilku procent, sporadycznie do 20-30%, co oczywiście nie jest reprezentatywne. Nawet jak ZIP/RAR będzie się kompresował o minutę dłużej, to nie ma to znaczenia. Co oczywiście nie oznacza, że bym był zadowolony, jakbym był zmuszony zaakceptować spadek nawet do 30% albo musiał dalej kupować procesory Intela w zawyżonej cenie, gdyby nie było konkurencji.
Nie wygląda na to, żeby typowy użytkownik musiał wyłączać HT, ale już dział infosec w Lockheed Martin na pewno ma inne zdanie na ten temat. Wszystko zależy od modelu zagrożeń.