KAISER - błąd w układach Intela, ARM i AMD podatny na ataki Meltdown i Spectre

[bluszcz]

Jeśli chodzi o wydajność to wątpliwym jest, by taki pozew przeszedł. Procesor nie zmniejszył wydajności, a jedynie system i aplikacje wykonują dodatkowe działania związane z obchodzeniem błędów w procesorze.
Sensowniejszą argumentacją byłoby, że procesor nie działa tak, jak zostało to udokumentowane przez producenta i nie chodzi tu o wydajność. Jak Theo powiedział (jeden z głównych deweloperów jednego z systemów z rodziny BSD):

Kod:

https://www.itwire.com/security/81338-handling-of-cpu-bug-disclosure-incredibly-bad-openbsd-s-de-raadt.html

To skandal i powinniśmy dostać poprawione procesory za darmo. Nie obchodzi mnie to, że będą 30% wolniejsze, ważne by działały zgodnie z dokumentacją.

[wwd]

Wiemy że MS łata okienka, a jak się sprawa z linuksami?
Czy ktoś się tym zajmuje?
Jest przecież tyle dystrybucji...

[buri]

Kernele już połatane. Ciekawiej sprawa wygląda z biosami do płyt głównych, bo tu może być słabo.
Nvidia dzisiaj wydała sterowniki z łatką.

[Lex]

Sensowniejszą argumentacją byłoby, że procesor nie działa tak, jak zostało to udokumentowane przez producenta i nie chodzi tu o wydajność.

Zwróć proszę jeszcze raz uwagę na to co napisałem w poprzednim poście cytując warunki sprzedaży:

"Produkt jest zasadniczo zgodny z publicznie dostępnymi specyfikacjami firmy Intel"

Stwierdzenie "zasadniczo zgodny" to dla mnie nie jest to samo co "zgodny w stu procentach" - bardziej "zgodny co do ogólnych założeń". Być może czepiam się słówek, ale wydaje mi się, że właśnie taka interpretacja tego stwierdzenia (którą na pewno podnieśliby prawnicy Intela) może wystarczyć by oddalić pozew opierający się na "różnicach w dokumentacji".

[bluszcz]

Sensowniejszą argumentacją byłoby, że procesor nie działa tak, jak zostało to udokumentowane przez producenta i nie chodzi tu o wydajność.

Zwróć proszę jeszcze raz uwagę na to co napisałem w poprzednim poście cytując warunki sprzedaży:

"Produkt jest zasadniczo zgodny z publicznie dostępnymi specyfikacjami firmy Intel"

Stwierdzenie "zasadniczo zgodny" to dla mnie nie jest to samo co "zgodny w stu procentach" - bardziej "zgodny co do ogólnych założeń". Być może czepiam się słówek, ale wydaje mi się, że właśnie taka interpretacja tego stwierdzenia (którą na pewno podnieśliby prawnicy Intela) może wystarczyć by oddalić pozew opierający się na "różnicach w dokumentacji".

Może i nie "zgodny w stu procentach", ale wydaje mi się, że w przypadku tak precyzyjnych spraw jak CPU to "zasadniczo zgodny" powinno oznaczać, że różnice między dokumentacją, a rzeczywistym działaniem CPU powinny ograniczać się do naprawdę błahych rzeczy, a nie bardzo poważnych błędów obchodzących MMU. Gdyby "zasadniczo zgodny" dawało prawo do zbyt luźnego podejścia przez producenta do tematu to by się nie dałoby się tworzyć systemów operacyjnych ani programów na procesory. Jądra Windowsa, Linuxa, MacOSa i w zasadzie wszystkich innych systemów na x86 zakładały zgodnie z dokumentacją, że MMU zapewni odgraniczenie pamięci jądra od pamięci zwykłych aplikacji, a tak nie jest.
Przynajmniej takie jest moje zdanie na bazie tego co przeczytałem, ale jestem zwykłym klepaczem kodu w językach wysokiego poziomu, więc można go nie brać jako zdania eksperta. IMHO właśnie jakiś biegły, który zna i rozumie dokumentacje procesorów oraz działanie podsystemów pamięci w systemach operacyjnych, powinien zostać powołany i jego opinia powinna być brana pod uwagę.

Fakt, wady nie da się fizycznie usunąć ale producenci łatają ją programowo, kosztem wydajności.
[..]
Wady są, ale zostaną zaaplikowane łatki umożliwiające obejście wad i procesor "nie przestanie działać".

Rozmawiamy o procesorze. Załóżmy, że kupiliśmy oddzielnie sam procesor, a nie cały laptop albo jednostkę centralną.
Intel, jako producent procesora, nie jest producentem żadnego systemu operacyjnego. Co najwyżej w przypadku Linuksa można by powiedzieć, że pomimo nie bycia producentem Linuksa to brał udział w dostarczaniu łat dla tego systemu. Stricte więc mówiąc, w większości przypadków to nie Intel tworzył łaty obchodzące problem. W zasadzie wielu projektów systemów operacyjnych nawet nie poinformował z wyprzedzeniem o błędzie.

Najciekawsze jest dla mnie, gdy ktoś jest programistą języka C i asemblera (niestety nie jestem :/), a nie tylko zwykłym użytkownikiem, i potrafi napisać patch na jądro systemu operacyjnego (nie związany z łataniem Meltdowna itp). Taki programista może brać udział w tworzeniu systemu operacyjnego, w szczególności systemów FOSS (wolna lub otwarta licencja). To nie musi zawsze oznaczać jakichś spektakularnych commitów - ot implementacje prostych funkcji. Raczej z punktu widzenia takiego programisty jest to już niezgodność towaru z umową i to, że w Linuksie i Windowsie błędy zostały ominięte nic nie znaczy dla takiego programisty, bo on używa i rozwija inny system. W szczególności jeśli system, jaki wybrał, ma bardziej priorytetowe podejście do bezpieczeństwa niż większość, a błąd właśnie w to bezpieczeństwo bezpośrednio uderza.

[Lex]

Przynajmniej takie jest moje zdanie na bazie tego co przeczytałem, ale jestem zwykłym klepaczem kodu w językach wysokiego poziomu, więc można go nie brać jako zdania eksperta. IMHO właśnie jakiś biegły, który zna i rozumie dokumentacje procesorów oraz działanie podsystemów pamięci w systemach operacyjnych, powinien zostać powołany i jego opinia powinna być brana pod uwagę.

Wiesz, ja też nie jestem ekpertem. Ja nie bronię Intela (być może tak się komuś wydaje) i, jak napisałem, cieszyłbym się, gdybym otrzymał nowy procesor "wolny od wad". Sęk w tym, że próbuję popatrzeć na sprawę racjonalnie i w/g mnie jest tu tyle niedomówień i furtek, że każdy dobry prawnik, który stanie w obronie Intela będzie spokojnie miał się za co złapać (szczególnie jeśli w grę wchodzą tak potężne pieniądze).

[Cascudo]

Koledzy, a może sprawę ugryźć od innej strony.
Intel nie określa dokładnie wydajności procka, nie tworzy systemów, ale może współtworzyć łatki bezpieczeństwa dla swoich procków ok, ale...
Wada/podatność o której mówimy jest znana x lat, intel o niej na pewno wiedział i mimo to nie zrobił nic na przestrzeni lat by poprawić stan faktyczny, czyli niejako celowo bądź świadomie wypuszczał na rynek produkt, który zawierał wadę sprzętową związaną z fizycznym procesorem niezależnie od systemu operacyjnego.
Czyli firma działała na szkodę zarówno sektora publicznego, prywatnego oraz producentów OS.
Wdaje mi się, że może od tej strony dałoby się podejść zwycięsko do tej sprawy, ale mogę się mylić.
Co o tym sądzicie?

[Tajny Współpracownik]

Polecam korzystać z Amigi i procków Motoroli, tam na pewno nie ma podatności , programów zbyt dużo też nie ma...

[Cascudo]

Polecam korzystać z Amigi i procków Motoroli, tam na pewno nie ma podatności , programów zbyt dużo też nie ma...

Gdybym miał Amigę to rzuciłbym wszystko i wyjechał w Bieszczady

[Lex]

Wada/podatność o której mówimy jest znana x lat, intel o niej na pewno wiedział i mimo to nie zrobił nic na przestrzeni lat by poprawić stan faktyczny, czyli niejako celowo bądź świadomie wypuszczał na rynek produkt, który zawierał wadę sprzętową związaną z fizycznym procesorem niezależnie od systemu operacyjnego. (...)
Wdaje mi się, że może od tej strony dałoby się podejść zwycięsko do tej sprawy, ale mogę się mylić.
Co o tym sądzicie?

No niestety to tak nie zadziała, bo Intel przyznaje, że został poinformowany o wadzie dopiero w połowie zeszłego roku.

[Aby zobaczyć linki, zarejestruj się tutaj]

When did Intel learn about the issue?

The security researchers notified Intel and other companies about this issue in June 2017. Intel is committed to responsible disclosure. In this case, the security researchers presented their findings in confidence, and we and other companies worked together to verify their results, develop and validate firmware and operating system updates for impacted technologies, and make them widely available as rapidly as possible.

Nawet jeśli wiedział o niej wcześniej to bedzie to bardzo trudne do udowodnienia.

[bluszcz]

Intel raczej wiedział wewnętrznie wcześniej o tych podatnościach, albo chociaż podejrzewał. Pytanie czy da się to udowodnić?

Na jednej z konferencji w 1995 roku jedna z technik optymalizacji była przedstawiona jako zagrażająca bezpieczeństwu.

[Aby zobaczyć linki, zarejestruj się tutaj]

Speculative execution considered harmful in 1995: "Prefetching may fetch otherwise inaccesible instructions in Virtual 8086 mode."

[Aby zobaczyć linki, zarejestruj się tutaj]

A tutaj profesor/wykładowca mówi, że 6 lat temu był w siedzibie Intela i wygłosił prezentację o atakach side-channel.

[Aby zobaczyć linki, zarejestruj się tutaj]

Slide from a talk I gave at Intel (and many other places) 6 years back. The talk was on design time tools and techniques to detect and mitigate microarchitectural side channels (Side Channel Vulnerability Factor measurement and method, and the TimeWarp mitigation from ISCA12).

[Lex]

Pytanie czy da się to udowodnić?

No i o tym mówię. To że pojawia się jakiś artykuł nie zawsze oznacza, że wszyscy się nim wystarczjąco przejmują by uznać to za "początek".

[wredniak]

Jeżeli sprawa rozbija się o kwestie aktualizacji również biosu to temat przepadł. Do większości starszych płyt z Win7 i prockiem intela nie będzie żadnej aktualizacji.

Co do procesu, jeżeli wada została zgłoszona wcześniej i producent dalej sprzedawał swój produkt świadom problemów to jest to jak najbardziej do wygrania. Kwestia determinacji bo batalia będzie długa.

[ichito]

Nie wiem, czy już było, bo szczerze to straciłem już wątek w tym zamieszaniu i sam nie wiem, co ja na swoich laptokach (XP, Vista i W8.1) mam zrobić i czy coś w ogóle muszę W znalezionym na Z3S artykule "Meltdown i Spectre – poradnik łatacza, czyli co i jak naprawiać"

[Aby zobaczyć linki, zarejestruj się tutaj]

znalazłem info, że rzecz jest w "magicznym" wpisie w rejestrze

Key="HKEY_LOCAL_MACHINE"Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat"
Value Name="cadca5fe-87d3-4b96-b7fb-a231484277cc"
Type="REG_DWORD”
Data="0x00000000”

którego utworzenie/istnienie jest warunkiem poprawnego zadziałania zainstalowanych AV i możliwości instalowania dalszych poprawek.
Z artykułu podrzucam też link do aktualizowanej bazy AV, które już samodzielnie tworzą ten fragment i tym samym są kompatybilne (w założeniu)

[Aby zobaczyć linki, zarejestruj się tutaj]

[wredniak]

[Aby zobaczyć linki, zarejestruj się tutaj]

znalazłem info, że rzecz jest w "magicznym" wpisie w rejestrze

Każdy zaktualizowany Antywir sam ustawi sobie ten wpis. Oczywiście to mętne rozwiązanie, bo możesz potem zainstalować innego antywira, który nie wspiera tych poprawek i będzie d*pa zbita. Z tego co czytałem to BSODy mogą szaleć.

Odnośnie przeglądarek, to wersja Firefox 52 ESR ma otrzymać stosowne łaty 23 stycznia. Ciekawe czy Adobe wyda łatki do Flasha .

[M'cin]

To i ja swoje 5 centów dołożę.

Wymiana wszystkich procków 2 lata wstecz - nie wierzę. Produkt trzyma deklarowane na pudełku wartości zegara, a że systemy trzeba połatać - zdarza się. Nie ma produktu bez wad, a w przypadku zaawansowanych technologii ciężko nie trafić na jakąś lukę.

Jeśli jednak chodzi o procki produkowane już PO odkryciu luki, to Intel powinien wymieniać wszystko i jeszcze czekoladki z przeprosinami dorzucać - udowodnienie, że celowo sprzedawali wadliwy produkt nie powinno być trudne do udowodnienia.

[wredniak]

To i ja swoje 5 centów dołożę.

Wymiana wszystkich procków 2 lata wstecz - nie wierzę. Produkt trzyma deklarowane na pudełku wartości zegara, a że systemy trzeba połatać - zdarza się. Nie ma produktu bez wad, a w przypadku zaawansowanych technologii ciężko nie trafić na jakąś lukę.

Minimum to powinno być - te co są na gwarancji (jeżeli wlutowany to proces wymiany na koszt intela) oraz te wypuszczone po potwierdzeniu podatności.

Poza tym to nie jest kwestia trzymania wartości zegarów ani łatania systemu. Systemy nie potrzebowały żadnej łaty bo błąd nie jest po ich stronie. Łaty są próbą naprawienia luki występującej w sprzęcie, niestety kosztem wydajności. Dlatego uważam, że w kwestii bezpieczeństwa nie powinno być czegoś takiego jak koniec gwarancji. Patrz ostatnie problemy z Bluetooth czy WiFi. Takie sprawy nie powinny ulegać przedawnieniu gdyż godzą w bezpieczeństwo. To, że ktoś wypuścił gniota to co nas to obchodzi?
Może to idealistyczne i nierealne ale tak uważam.

[ichito]

Dla zainteresowanych artykuł-przewodnik na temat wprowadzania poprawek pod kątem Meltdown "How to deploy Meltdown patches - in Windows 7/8/10"

[Aby zobaczyć linki, zarejestruj się tutaj]

[Lex]

@ichito: Niestety obawiam się że to tak ładnie nie wygląda jak zostało opisane w podanym linku, a raczej powinienem napisać "nie będzie wyglądało". Dlaczego? Ponieważ osoba, która napisała ten artykuł, instalowała tylko aktualizacje MS, nigdzie nie ma wzmianek o aktualizacji BIOSów. To ma znaczenie, ponieważ z tego co czytam, to łatka na BIOS wprowadza najwięcej "zamieszania". Co więcej, spotykam się ze wpisami, z których wynika, że aktualizacje MS nie uaktywniają swoich własnych zabezpieczeń zanim nie rozpoznają właściwej łatki w BIOSie - ale nie jestem tak do końca przekonany co do tej drugiej teorii. Pierwsze stwierdzenie jest jednak uzasadnione i moim zdaniem bez aktualizacji BIOSów trudno o efektywne porównanie wydajności systemu "przed" i "po".

EDIT: Wiele mówiący cytat o terminach poprawek mikrokodów procesorów:

Skylake and above are ETA end of Jan 2018, Haswell and Boardwell are Feb 2018, Sandy Ivy Maybe late March 2018. Westmere and Nehalem May April 2018.

Trochę to więc jeszcze potrwa.

[bluszcz]

@Lex Chyba jest jeszcze bardziej skomplikowane z tymi łatkami, bo z tego co czytałem na Skylake i nowszych z łatkami UEFI (microcode dla CPU) modyfikowane jest przetwarzanie niektórych instrukcji przez procesor, a na starszych nie są i łatki na Windows inaczej mają działać na Skylake z aktualnym microcodem, a inaczej na Broadwellu i starszych z aktualnym microcodem.
Do sprawdzania stanu załatania (a raczej omijania) błedów warto użyć programu SpecuCheck.

---

Pomimo zagrożenia ja jednak na razie nie polecam aktualizować UEFI, bo podobno dużo osób ma problemy po aktualizacji systemu oraz UEFI (obu). Zamiast tego nie uruchamianie niezaufanych programów, w tym Javascriptu na stronach - czyli NoScript potrzebny.