- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
Hirdetés
-
Dragon Ball: Sparking! Zero - Mester és tanítvány
gp Egyelőre még mindig nem kaptunk megjelenési dátumot a játékhoz.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
Új Beats fej- és fülhallgatók jelentek meg
ma Frissítette a Solo termékcsaládot az Apple házi audiomárkája.
Új hozzászólás Aktív témák
-
őstag
Szerintem félreérted, ott csak a komment változott egy struktúra méretével kapcsolatban.
A bug javításra létrehozott featúrát eleve kikapcsolhatóra fejlesztették. Valószínű blacklist/whitelist alapú lesz a végleges megoldás a hiba detektálására, ami még nem készült el. Kernel paraméterrel már most kikapcsolható azonban. Lényeg a lényeg, ez a bug nem érinti az AMD-t.
-
őstag
válasz soulknight #258 üzenetére
Nemsokára el is adom, de előbb megvárom a következő processzor generációt. Viszont a 8700K ezzel ki is lett lőve részemről.
-
őstag
Ahogy az eredményeket nézem, leginkább a torrentezést fogja lassítani, ami az otthoni felhasználást illeti. Amire kíváncsi vagyok az a multis játékok szereplése a hálózat kezelés miatt, ott lehetnek még kellemetlen meglepetések. Valószínű az összes monitorozó, háttérben futó program több CPU-t fog enni, a rendszerhívások miatt. Mondjuk ha meg lehet úszni ennyivel, az jó lenne.
-
őstag
Szerintem ezt nem lehet most megmondani pontosan. Meg kell várni a hivatalos bejelentést, utána meg végig kell nézni a sok mérési eredményt. Mivel ez egy hardware hiba, érintett a Linux, Windows, MacOS, minden, amin Intel proci van. A memória védelem kezelése lassabb lesz, ez leginkább akkor fog megérződni, ha a program sok rendszerhívást hív futása során.
-
őstag
-
őstag
Az 5% az LWN.net-ről van, a 30% meg mérési szélsőértékek.
The current state of kernel page-table isolation
By Jonathan Corbet
December 20, 2017[...]
Finally, while all existing x86 processors are seemingly affected by information-disclosure vulnerabilities, future processors may not be. KPTI comes with a measurable run-time cost, estimated at about 5%. That is a cost that some users may not want to pay, especially once they get newer processors that lack these problems. There will be a nopti command-line option to disable this mechanism at boot time. The patch series also adds a new "feature" flag (X86_BUG_CPU_INSECURE) to indicate vulnerable CPUs; it is set on all x86 CPUs currently, but might not be on future hardware. In the absence of this feature flag, page-table isolation will automatically be turned off.
[ Szerkesztve ]
-
őstag
válasz Németh Péter #316 üzenetére
Jobban utánajárva, az 5-30% innen jön:
KAISER: hiding the kernel from user space
By Jonathan Corbet
November 15, 2017[...]
KAISER will affect performance for anything that does system calls or interrupts: everything. Just the new instructions (CR3 manipulation) add a few hundred cycles to a syscall or interrupt. Most workloads that we have run show single-digit regressions. 5% is a good round number for what is typical. The worst we have seen is a roughly 30% regression on a loopback networking test that did a ton of syscalls and context switches.
[ Szerkesztve ]
-
őstag
-
őstag
-
őstag
Ez érdekes valóban. Mivel mindenki titkolózik, nehéz kideríteni mi a helyzet.
a AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.Az AMD álláspontját max ebből a commit-ból ismerhetjük ugye. Ez alapján az Intel processzorban van egy hiba. Az Intel most ezzel ellentéteset állít vagy valami eddig nem ismert új részletre hivatkozik. Na, popcornt elő...
-
őstag
Jobban megnézve a szöveget, tulajdonképpen nem mondanak ellent a mostani ismereteknek.
"Intel believes these exploits do not have the potential to corrupt, modify or delete data."
Ez lehet, hogy igaz, de hiányzik a read, tehát nem cáfolják azt, hogy kernel adatokhoz lehet hozzáférni.
"Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. "
Ez is igaz, érintett az ARM is.
"Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings"
Itt hivatkozik az AMD-re, de csak annyit állít, hogy együtt dolgoznak velük a hiba kijavításán.
-
őstag
-
őstag
Most úgy néz ki, hogy CPU limites helyzetekben átlag 3-5% visszaesés lesz a jövő keddi Windows patch után játékoknál. Rendszerhívásokat többször használó programoknál nagyobb, egyéb esetben kisebb visszaesés várható.
[ Szerkesztve ]
-
őstag
Igen, de azt eredetileg az ASLR side channel attack ellen próbálták használni. Habár elsőrangú információim nincsenek, nekem úgy tűnik, hogy a kapkodás csak valamikor novemberben kezdődött.
Exploiting side-channel attacks with ASLR cache vulnerabilities (AnC)
This entry was posted on Monday, March 13th, 2017. -
őstag
-
őstag
-
őstag
Na, úgy látszik a Google áll az egész mögött. Kétfajta támadásról is szó van, van neki honlapja is.
Hát elég komplikált a helyzet. Kell pár előfeltétel ezekhez a támadásokhoz. Nem is tudom lehet-e ezeket CPU hibáknak hívni. Végülis a processzor beépített belső időmérőjével kimérik a processzor belső állapotát és abból következtetnek memória tartalomra. Hűűű...Erre aludni kell párat.
Meltdown:
6.4 Limitations on ARM and AMD
We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.
Spectre:
1.3 Targeted Hardware and Current Status
Hardware. We have empirically verified the vulnerability of several Intel processors to Spectre attacks, including Ivy Bridge, Haswell and Skylake based processors. We have also verified the attack’s applicability to AMD Ryzen CPUs. Finally, we have also successfully mounted Spectre attacks on several Samsung and Qualcomm processors (which use an ARM architecture) found in popular mobile phones.
Current Status. Using the practice of responsible disclosure, we have disclosed a preliminary version of our results to Intel, AMD, ARM, Qualcomm as well as to other CPU vendors. We have also contacted other companies including Amazon, Apple, Microsoft, Google and others. The Spectre family of attacks is documented under CVE-2017-5753 and CVE-2017-5715.
-
őstag
válasz jaffa 2843 #378 üzenetére
Már volt, 329-től olvasd vissza.
-
őstag
-
őstag
Az AMD is válaszolt erre a problémakörre:
-
őstag
Nem tudom miért vagy ilyen optimista. Ez egy új támadási mód és sokféle alkalmazása lehetséges. Egyik esetben előjött egy Intel bug is, amikor a cacheben otthagyja a védett memóriacím tartalmát. A memóriacímek szoftveres szétválasztása mindenképp lassítani fog a rendszeren. Hogy mennyit, azt még mindig nem tudjuk pontosan, de mondjuk tényleg úgy tűnik elviselhető mértékben, de pl DayZ esetén 13% FPS csökkenés is adódott. Nem kell félvállról sem venni ezt.
https://www.reddit.com/r/pcgaming/comments/7o2ctw/benchmarked_intel_security_patch_impact_on/
-
őstag
6 órás a link, amit beraktam és játékok FPS értékeit tartalmazza a Windows frissítése után és előtt. Mint kiderült hónapok óta dolgoznak ezen, más megoldás nem látszik egyelőre. Nem szabad úgy kezelni, mintha mi sem történt volna. Úgy látszik az átlag felhasználó megússza pár százalék teljesítmény csökkenéssel, de érdemes körüljárni a dolgot és alaposan kivesézni, mert lehetnek még itt meglepetések.
-
őstag
-
őstag
válasz BladePocok #589 üzenetére
Egyelőre nem várható.
-
őstag
-
őstag
-
őstag
Átrágtam magam a két sebezhetőségen, de nem értem miért adtak neki két nevet is. Igazából különböző utasításokkal érik el ugyanazt. Az Intel sebezhetősége kimerül annyiban, hogy túl későn validálja a memóriacímeket. Mire kiderül, hogy ahhoz az adathoz nincs is hozzáférés, már végzett vele műveletet. Habár annak összes eredményét eldobja, de a művelet hatására megváltozik a cache tartalma és az a beépített nannosec-es az órával kimérhető.
Szóval mindkét támadás alapja az, hogy kijelölnek egy memóriaterületet és a címhez tartozó cache területet ürítik. Ezután vagy a párhuzamos feldolgozást (out of order hogy van magyarul?), vagy az elágazás előrejelzést manipulálva elérik, hogy egy olyan utasítás fusson le, ami kiolvas egy védett memóriatartalmat és annak értékével megcímez egy korábban kijelölt memóriaterületet. Ennek hatására egy olyan memóriacím kerül a cache-be, aminek az értéke direktben összefügg a védett memóriatartalom értékével. Ezután már csak végigmennek újra a kijelölt memóriaterületen és megpróbálják kiolvasni. Ha gyorsan (80 nanosec mondjuk, nyilván proci függő az érték) ki lehet olvasni azt a címet, akkor a cím benne van a cache-ben. Mivel a memóriacím és a védett memóriatartalom között direkt matematikai összefüggés van, egyszerűen kimatekozható, hogy mi a védett memóriatartalom. Az AMD-nél annyi van, hogy a feldolgozás korábbi szakaszában validálja a címeket állítólag, így nem lesz kimutatható hatása a cachre sem.
-
őstag
Nagyon optimista vagy, lehet igazad is lesz, de most még javában zajlanak az események. A Meltdown bugra jött javítás eddig, de az elágazásbecslős hibára még nem. Javítás, amit eddig találtak az elég lehangoló. Amúgy úgy tűnik, hogy az AMD az elágazás becslős hibára is immunis.
-
őstag
Mindegyik mostani hiba védett adathoz enged hozzáférést. A támadási felület otthoni felhasználónál nyilván a böngésző, meg a letöltött programok. Böngészőnél a szélsőséges eset az lehet, hogyha megvan nyitva egy támadóoldal, akkor az hozzáfér az összes megnyitott többi oldalhoz is. Ugyanakkor ez egy elméleti lehetőség jelenleg. Rámenni a gépedre nem tud ezzel a módszerrel. A trójai programok, kamu plugin-ek juthatnak több információhoz ezzel. Mivel az ARM procik is érintettek, lehet a mobilokon fog nagyobb gázt okozni, ha egy ártatlannak tűnő ingyenes játék hozzáfér a banki SMS-ekhez, mindenféle jogosultság nélkül. Így akár a kétfaktoros azonosítás is kijátszható lehet. Habár lesz nyoma a támadásnak, mert megkapod a belépési SMS-t, szóval inkább célzott támadásra lehet majd inkább használni. Hirtelen ezek a vészforgató könyvek jutnak eszembe, átlagfelhasználónak szerintem elég most frissítgetni.
-
őstag
Igazából egyik sebezhetőség sem hiba. Az összes regiszter és memóriatartalom jó értéket fog mutatni. Amit ki lehet használni az az, hogy egyes memóriaterületek elérési ideje megváltozhat, mert bekerülhetnek a cache-be.
Az indirekt jumpos történetnél az egyik program elágazás becslése hatással lehet egy másik programéra. Ez viszont már tényleg hülyeség és váratlan, még ha eddig nem is okozott bajt.
-
őstag
Attól függ, hogy honnan nézzük. Ha vissza lehet állítani a cache tartalmát úgy, hogy az csak azt mutassa, amikor rendes kód futott le, akkor végülis nem hiba egyik megoldás sem. Valami olyasmi megoldás kellene, hogy lenne egy tranziens cache, amibe minden becsült memóriacím belekerülhet, de csak az kerülne át onnan a normál cache részbe, amin a tényleges kód hajtódott végre. És a tranziens cache törlődne context switch után. Vagy a cache-t bejegyzéseket kellene kiegészíteni "becsült" és "tényleges" infókkal. Mindenesetre megoldható problémáról van szó. Nem kis probléma, de nem is óriási megvalósítás szemszögéből.
-
őstag
-
őstag
Azokat még BIOS frissítés nélkül mérték. Van újabb is, de szerencsére nincs nagy romlás, csak kicsi játékoknál.
https://www.techspot.com/article/1556-meltdown-and-spectre-cpu-performance-windows/page2.html
-
őstag
-
őstag
válasz #41133696 #829 üzenetére
Az elágazásbecslős Spectre és a user módból kernelt olvasó Meltdown hibára immunis az AMD. Azok hibajavítása komoly teljesítmény vesztést okoz bizonyos esetekben, ezzel mondjuk lehetne indokolni egy ilyen cserét. A tömbtúlírós kernel módú Spectre javítása mondjuk nem tudom hogy áll. Egyelőre szerintem érdemes kivárni, hogy miként alakulnak a dolgok, még tisztulni kell a képnek.
-
őstag
-
őstag
-
őstag
-
őstag
Nem hiszem, hogy van, de jó lenne látni méréseket is erről. Maga a Microsoft beszél érezhető lassulásról, az nem tudom hány százalék.
Performance
One of the questions for all these fixes is the impact they could have on the performance of both PCs and servers. It is important to note that many of the benchmarks published so far do not include both OS and silicon updates. We’re performing our own sets of benchmarks and will publish them when complete, but I also want to note that we are simultaneously working on further refining our work to tune performance. In general, our experience is that Variant 1 and Variant 3 mitigations have minimal performance impact, while Variant 2 remediation, including OS and microcode, has a performance impact.Here is the summary of what we have found so far:
- With Windows 10 on newer silicon (2016-era PCs with Skylake, Kabylake or newer CPU), benchmarks show single-digit slowdowns, but we don’t expect most users to notice a change because these percentages are reflected in milliseconds.
- With Windows 10 on older silicon (2015-era PCs with Haswell or older CPU), some benchmarks show more significant slowdowns, and we expect that some users will notice a decrease in system performance.
- With Windows 8 and Windows 7 on older silicon (2015-era PCs with Haswell or older CPU), we expect most users to notice a decrease in system performance.
- Windows Server on any silicon, especially in any IO-intensive application, shows a more significant performance impact when you enable the mitigations to isolate untrusted code within a Windows Server instance. This is why you want to be careful to evaluate the risk of untrusted code for each Windows Server instance, and balance the security versus performance tradeoff for your environment.
For context, on newer CPUs such as on Skylake and beyond, Intel has refined the instructions used to disable branch speculation to be more specific to indirect branches, reducing the overall performance penalty of the Spectre mitigation. Older versions of Windows have a larger performance impact because Windows 7 and Windows 8 have more user-kernel transitions because of legacy design decisions, such as all font rendering taking place in the kernel. We will publish data on benchmark performance in the weeks ahead.
Új hozzászólás Aktív témák
- Beszámítás! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- PROFESSZIONÁLIS Delid / Relid AMD Ryzen Processzorokhoz, garantált minőségben! (CSAK AM5!)
- Garanciális Intel Core i5-13600K
- A legolcsóbb! Új bontatlan, dobozos, számlás, garanciális i9 13900K CPU akció!
- Beszámítás! Intel Core i5 6500 4 mag 4 szál processzor garanciával hibátlan működéssel