Wykryto bardzo poważną, sprzętową wadę wszystkich procesorów x86 Intela [ENG]

[LeBomB 2426]

No to przecież napisałem, że dopiero po zainstalowaniu aktualizacji systemowych + BIOS. Czytaj dokładniej proszę.

[tomcug 3971]

Pierwsze testy na 7350K i aktualizacji BIOS-u pod Spectre:

 

• Średnio -2,8%
  
• Maksymalna strata w zakresie 8-9% (Battlefield 4, Sniper: Ghost Warrior 3)
  

Mogło być gorzej, ciekawe jak Ryzenki po tym, gdy już AMD wyda obiecaną aktualizację mikrokodu .

[revcorey 0]

łohooh co to w centrach było

Mój link

ale widać chyba softwerowo coś działają

Mój link

Edytowane 19 Stycznia 2018 przez revcorey

[MarcoSimone 1754]

Pierwsze testy na 7350K i aktualizacji BIOS-u pod Spectre:

 

• Średnio -2,8%
  
• Maksymalna strata w zakresie 8-9% (Battlefield 4, Sniper: Ghost Warrior 3)
  

Mogło być gorzej, ciekawe jak Ryzenki po tym, gdy już AMD wyda obiecaną aktualizację mikrokodu .

 

Dzień przed wybuchem afery złożyłem synowi znajomej kompa na i3-8100 (taki był budżet).

 

W świetle Twoich testów, jest sens aktualizować Mu bios o te kody?

[sideband 8803]

Pierwsze testy na 7350K i aktualizacji BIOS-u pod Spectre:

 

• Średnio -2,8%
• Maksymalna strata w zakresie 8-9% (Battlefield 4, Sniper: Ghost Warrior 3)

Mogło być gorzej, ciekawe jak Ryzenki po tym, gdy już AMD wyda obiecaną aktualizację mikrokodu .

Sprawdzałeś snipera na 4/8?

 

Dzień przed wybuchem afery złożyłem synowi znajomej kompa na i3-8100 (taki był budżet).

 

W świetle Twoich testów, jest sens aktualizować Mu bios o te kody?

2/4 to nie to samo co 4/4, więc różnice mogą całkowicie niezauważalne.

[tomcug 3971]

Dzień przed wybuchem afery złożyłem synowi znajomej kompa na i3-8100 (taki był budżet).

 

W świetle Twoich testów, jest sens aktualizować Mu bios o te kody?

Tego jeszcze nie wiem, 6600K następny w kolejce. Mam też 7700K i sprawdzę na nim łatkę.

[MarcoSimone 1754]

@ 2xUP

 

Faktycznie. Pomyliło mi się. Nie wiedzieć czemu, myślałem że 7350k też ma 4/4

Edytowane 19 Stycznia 2018 przez MarcoSimone

[tomcug 3971]

Tak, wiem, że to mylące . Ten 7350K to w takim bardziej realistycznym scenariuszu odpowiednik G4560/4600 .

[Kowal 579]

Skąd Ty wziąłeś w ogóle tą padakę?

[tomcug 3971]

Na pewno nie kupiłem .

 

EDIT:

 

Drobny update odnośnie Battlefield 4:

 

• 7350K: -7,8%
  
• 6600K: -1,3%
  

Tak jak Side pisał wyżej, na 4/4 istotnie jest całkiem spoko. Te procenty to całkowity spadek, czyli po zainstalowaniu patcha i wgraniu nowego BIOS-u (pakiet Meltdown + Spectre).

 

EDIT2:

 

Jeszcze SGW3:

 

• 7350K: -8,8%
  
• 6600K: -2,7%
  

Czyli znowu na czterech rdzeniach strata w zupełności akceptowalna.

Edytowane 20 Stycznia 2018 przez tomcug

[MarcoSimone 1754]

Dzięki za testy Tomcug :thumbup:

 

To dzieciak z 8100, może spać spokojnie

[Camis 7934]

Twórca Linuksa o łatkach Intela na luki w procesorach: „To zwykłe śmieci!”

 

W niedzielę pojawić się miał finalny Linux 4.15, jednak się nie pojawił. Linus Torvalds zdecydował, że ze względu na to całe zamieszanie wokół luk Spectre i Meltdown trzeba jeszcze jednego wydania kandydackiego. Zamiast finalnego wydania, Linus napisał tymczasem maila na listę dyskusyjną deweloperów kernela, w której w końcu otwarcie napisał co myśli o działaniach Intela. Ktoś wciska nam kompletne śmieci z niejasnych powodów – napisał twórca Linuksa.

 

Linus Torvalds wziął udział w dyskusji z wieloletnim deweloperem linuksowego kernela i byłym inżynierem Intela (a obecnie Amazona), dotyczącej stworzenia makr sterujących działaniem mechanizmu Indirect Branch Restricted Speculation (IRBS), służącego do przewidywania rozgałęzień wykonywania kodu i w konsekwencji przyspieszenia przepływu potoku instrukcji. To właśnie nadużycie tego mechanizmu umożliwia jeden z ataków Spectre i pozyskanie informacji z innych procesów działających w systemie.

 

Z tego co zrozumieliśmy z dyskusji między deweloperami kernela, Intel zamierza wprowadzić do architektury swoich procesorów x86 mechanizm, poprzez który procesor będzie rozgłaszał, że może być bezpieczny. Uruchamiany na nim system operacyjny będzie mógł następnie ustawić bit kontrolny, poprzez który procesor stanie się zabezpieczony. Steruje tym wszystkim zbiór dość skomplikowanych makro. Rozwiązanie perfekcyjne – teraz to nie winą Intela, lecz deweloperów systemu operacyjnego będą marne wyniki w benchmarkach I/O, wybrali z jakiegoś powodu włączenie IRBS, a przecież wcale nie musieli.

 

David Woodhouse przyznał, że to brzydki hack, ale mamy trudną sytuację, cały świat płonie, a dzięki takim rozwiązaniom nie musimy wyłączać centrów danych i iść paść kozy, więc nie należy tak bardzo narzekać. Ale dla kogo to są rozwiązania? Linus Torvalds sugeruje, że to rozwiązania opracowane przez prawników, nie mające sensu z technicznego punktu widzenia, a służące nie zabezpieczeniu użytkowników, lecz ochronie Intela przed pozwem zbiorowym.

 

Zresztą nie ma co owijać w bawełnę. Linus wyjaśnia, że łatki powodują m.in., że rejestry kontrolne procesora zaczynają wypisywać śmieci na punkty wejścia/wyjścia kernela, generując przy tym spory narzut. Rzekomo po to, by chronić kernel, ale czy tak jest w rzeczywistości? Twórca Linuksa mówi: gdyby chodziło o oczyszczenie buforów rozgałęzień (BTB) przy aktualnych przełączeniach kontekstu między różnymi użytkownikami, to bym wam uwierzył. Ale łatki tego nie robią. W tej formie TO ZWYKŁE ŚMIECI. To szaleństwo, one robią rzeczy nie mające sensu. To czyni wszystkie twoje argumenty podejrzanymi – łatki robią rzeczy, które nie mają sensu.

 

Możemy się spodziewać, że słowa Linusa zostaną wykorzystane przed sądem w pozwie zbiorowym, jaki już wytoczono Intelowi. Łatki IRBS czynią bowiem całą sytuację jeszcze gorszą. Jeśli twórca Linuksa się nie myli (a kiedy ostatnio się mylił w kwestiach działania kernela?), Intel będzie mógł ogłosić, że załatał groźne luki, tymczasem praktycznie żadna dystrybucja nie będzie aktywowała mechanizmu bezpieczeństwa, ze względu na ogromny narzut na wydajność. W rezultacie w systemach pozostanie wielka luka w zabezpieczeniach, o której przeciętny menedżer IT w korporacji nic nie będzie wiedział – przecież Intel załatał luki.

 

Podobnie zresztą Intel rozgrywa sprawę na polu wydajności, odwracając naszą uwagę od tego, co istotne. Z przedstawionych przez dział Public Relation wynikach benchmarków po zastosowaniu łatek na Meltdown mogliśmy się na początku dowiedzieć, że właściwie to nic się nie dzieje, spadek wydajności jest na poziomie 0,01% – tylko że w obciążeniach roboczych nic nie mających wspólnego z operacjami I/O, gdzie nikt się żadnego spadku się nie spodziewał.

 

Myślę, że potrzebujemy czegoś lepszego niż te śmieci – kończy swój wywód twórca Linuksa.

 

 

Link

[VSS 93]

to może ktoś powie który system z dotychczas obecnych nie był podatny na wylew danych ?? , za czasów XP co chwila jakiś alert , jak nie zapora to witryny zainfekowane , dzis nawet jeżeli nieświadomie korzystaliśmy tyle lat z systemów które były podatne to i tak każdy dobiera sam wedle swoich potrzeb poziom ochrony danych ,

[Pentium D 1159]

U intela chyba robi Pan Wiesio z Blok Ekipy bo wszystko jest https://www.youtube.com/watch?v=7qzC4Fxsz58&feature=youtu.be&t=41s

[Camis 7934]

Intel: nie instalujcie dotychczasowych łatek dla Spectre i Meltdown

 

 

Sprawa zagrożeń wciąż w toku. Intel najpierw był krytykowany za błędy w wielu generacjach procesorów, przez które powstały zagrożenia znane jako Spectre i Meltdown tylko po to, aby wydając poprawki zmierzyć się z kolejną falą krytyki - tym razem za błędy w... poprawkach. Firma zaczęła udostępniać zaktualizowane mikrokody swoich procesorów, ale szybko okazało się, że powodują one nowe problemy. Teraz Intel prosi swoich partnerów (m.in. OEM-ów), aby ci zaprzestali wdrażania i dystrybuowania poprawek.

 

Intel zaleca OEM-om, dostawcom usług chmurowych, producentom komputerów oraz oprogramowania, a także odbiorcom końcowym wstrzymanie się z wdrażaniem aktualnych wersji poprawek, gdyż te mogą powodować częstsze niż zwykle restartowanie się urządzeń, a także inne, nieprzewidziane zachowania systemów. Neil Shenoy z firmy Intel zapewnił, że źródło problemów zostało namierzone, a nowe wersje poprawek są już dystrybuowane.

 

Firma teraz oczekuje od swoich partnerów, że ci przetestują poprawki dla procesorów Haswell i Broadwell, które zaczęli otrzymywać w miniony weekend, tak aby można było podjąć decyzję o ich ewentualnej dystrybucji na szeroką skalę. Warto podkreślić, że problemy z samoczynnym restartowaniem się komputerów z wdrożonymi wcześniejszymi poprawkami zgłaszali także użytkownicy platform z procesorami Ivy Bridge, Skylake, Kaby Lake oraz Coffee Lake. W ich sprawie Intel na razie nic nie mówi.

 

Wygląda na to, że problemy z restartami wywołuje forma implementacji poprawki dla zagrożenia Spectre (Wariant 2). Nowe wersje poprawek będą dostarczane wraz z aktualizacjami BIOS-ów i nie będą wpływać na poprawki związane z Wariantem 1 (Spectre) i Wariantem 3 (Meltdown).

 

Link

[Fancy 0]

No już pędzę i biorę się za odinstalowywanie.

[kochan4 801]

mi ta poprawka praktycznie w niczym nie przeszkadza, wypuszczą nową to mam nadzieję, ze ta się sama odinstaluje/zablokuje, jak do tej pory zero spadku wydajności i żadnych problemów z bsodami czy restartami

[LeBomB 2426]

Mnie też nie przeszkadza, ale to pewnie tylko dlatego, że na moją płytę z racji jej wieku nie wyszedł nowy BIOS, takie szczęście w nieszczęściu

[Aopolods 0]

A na mojego Asusa z170 pro gaming jeszcze nie ma biosu dlatego też mi nie przeszkadza.

[plmnb 22]

mi ta poprawka praktycznie w niczym nie przeszkadza, wypuszczą nową to mam nadzieję, ze ta się sama odinstaluje/zablokuje, jak do tej pory zero spadku wydajności i żadnych problemów z bsodami czy restartami

 

Bo spadki przy normalnym użytkowaniu są marginalne, łatwo je skompensować poprzez OC. Jazda się zaczyna przy SSD na SATA, SSD M.2 NVME, czyli tam gdzie przepustowość i ilość I/O jest wysoka.

O ile zwykły użytkownik tego nie zobaczy (Z wyjątkiem silnika UE3, bo tam jest dużo "streamowanych" tekstur ) to osoby renderujące, kompilujące dostaną po palcach.

Ja jeszcze nie przetestowałem swojego blaszaka ze względu na brak monitora i zrobię to jak tylko go dostanę.

Edytowane 24 Stycznia 2018 przez plmnb

[kochan4 801]

Bo spadki przy normalnym użytkowaniu są marginalne, łatwo je skompensować poprzez OC. Jazda się zaczyna przy SSD na SATA, SSD M.2 NVME, czyli tam gdzie przepustowość i ilość I/O jest wysoka.

O ile zwykły użytkownik tego nie zobaczy (Z wyjątkiem silnika UE3, bo tam jest dużo "streamowanych" tekstur ) to osoby renderujące, kompilujące dostaną po palcach.

Ja jeszcze nie przetestowałem swojego blaszaka ze względu na brak monitora i zrobię to jak tylko go dostanę.

mógłbys podac jakies gry co działają na silniku UE3? chętnie przetestuję z i bez łatki

co do ssd, nie zauważyłem też , żeby mi się jakoś system wolniej ładował czy coś w tym stylu (cięzko zauważyć, jak w 9 sekund startuje )

[eNeSik 88]

mógłbys podac jakies gry co działają na silniku UE3? chętnie przetestuję z i bez łatki

co do ssd, nie zauważyłem też , żeby mi się jakoś system wolniej ładował czy coś w tym stylu (cięzko zauważyć, jak w 9 sekund startuje )

 

https://pl.wikipedia.org/wiki/Lista_gier_wykorzystujących_silnik_Unreal

Edytowane 24 Stycznia 2018 przez eNeSik

[Sheenek 2466]

Ja czekam az u mnie w pracy chlopaki beda latac UCSy, kilkaset serverow na VM. Jak beda mieli wyniki spadku wydajnosci to sie podziele.

[kochan4 801]

dziś odpaliłem fantastyczny program inspectre i pomimo zainstalowanej łatki potwierdził mi że nie jestem chroniony

mógłby ktoś to sprawdzić? oczywiście ktoś z procem SB ewentualnie IB

[tomcug 3971]

Bo nie masz zaktualizowanego BIOS-u, więc jesteś chroniony przed Meltdown/Spectre v1. Przed Spectre v2 już nie.