Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
ono těch problémků bude víc že došlo na rychlou "gilotinu" řiditele Intelu, architektuře Core se prodlužovala životnost na úkor bezpečnosti. Osobně mě těší že jsem se při výběru sestavy nakonec rozhodl pro Ryzen ikdyž 8600K byl tak lákavý....
Mě teda nejvíc vadí ten pokles výkonu u NVME ssdček po záplatě spectre a meltdown. AMD nyní vypadá jako celkově lepší volba, sice taky není úplně bez chyb a potencíálních "brzd" jako latence pamětí apod., ale 20-30% pokles na Intelu u výkonu NVME je neomluvitelný. Začínám silně uvažovat, že příště pořídím ThreadRipper platformu, pokud se Intel nevzpamatuje a nenasadí konkurence schopné ceny. Dokud nemá Intel tady ty bugy opravené na novém hardwaru/nové architektuře , tak snad ani nemá cenu nad koupí intelu pro nové high-end pc na editaci videa a hraní uvažovat...
Při upgradu před dvěma měsíci jsem pořídil NVMe. Bios se záplatama jsem do desky nenahrával a že bych si z rychlosti NVMe ustříkával do textilu? Proti SATA SSD nevidím reálně žádný rozdíl. Měl jsem si raději za stejnou cenu koupit dvojnásobnou kapacitu SATA SSD, klidně do M.2 abych ušetřil kabely. 250GB SSD prostoru navíc by mi šiklo, mít 1.7T nebo 2TB je rozdíl
A edituješ 15GB 4k video soubory apod? Ale i tak, když si kupuješ NVME tak nechceš aby ti nějaká záplata architektury brala 20-30% výkonu.
1: kolik uživatelů edituje videa, natož 4k....
2: kolik domácích uživatelů má pro práci s videem rychlé NVMe disky? Sotva to mají na systém.
3: většinu uživatelů bude při editaci videa brzdit CPU a GPU.
4: reálný dopad je max pár procent, 20-30% výkonu můžná v nějakém cherry pick benchmarku
5: bios rozhodně nemá auto update jako Win, stejně tak když už přijde deska s novým biosem, lze nahrát starší.
6: profesionálové typicky pracují s videem ze sítě, kde je jednak zajištěná replikace a zálohování a následný encoding neprobíhá na stanici ale serveru.
Pro mě NVMe nemělo naprosto žádný přínos a úplně stejně je to pro drtivou vetšinu uživatelů počítače, při nenáročné činnosti, ale třeba i při hraní her ultrarychlé NVMe není takový přínos, který by opodstatnil vyšší cenu.
1. Slyšel jsi někdy o youtube? Statisíce uživatelů editují videa, tisíce 4k
2. NVME je pořád relativně drahá novinka, můj SATA 1TB Sandisk SSD stál 5500 Kč, pořídil jsem ho v akci na Amazonu asi před rokem a něco. 1TB Samsungu EVO 970 NVME stojí teď na Amazonu 10 litrů, což je pro mě přijatelná cena. Před pár dny byl v akci za 9. Adopce se bude jedině zvyšovat.
3. Právě že ne, dle analýzy Anandtechu je reálný dopad 20-30% "On the whole, we see that the patches for Meltdown and Spectre affect real-world application benchmarks, but, synthetic ones are largely unaffected. The common factor among most of these benchmarks in turn is storage and I/O; the greater the number of operations, the more likely a program will feel the impact of the patches. Conversely, a compute-intensive workload that does little in the way of I/O is more or less unfazed by the changes. Though there is a certain irony to the fact that taken to its logical conclusion, patching a CPU instead renders storage performance slower, with the most impacted systems having the fastest storage."
4. Ty zmiňuješ domácí uživatele a potom po nich chceš aby downgrodavali bios. Domácí uživatel se nechce s ničím srát a zabývat. Ten chce aby mu sytém jel na 100% a chce ho jenom používat, né se v něm hrabat, navíc bios vetšinou přináší i jiné kritické opravy tak downgradovat většinou nechceš. Celkově je tohle zvrácená logika. Přece si nebudu kupovat nový systém s vědomím abych si sám musel optimalizovat výkon úkony jako downgrade biosu.
500GB NVMe je cenově už velice přijatelné.
5. Já se bavím o svojich potřebách a je mi úplně jedno co kdo jiný dělá a chce.
6. Uznej, že se taky někdy můžeš hluboce mýlit... Já se taky kolikrát mylim, ale teď zrovna ne ty vole, to ti jako garantuji.
7. Přestaňme používat body a pojďme se bavit jako normální lidé :-D
Jirka a mylit se? To je obcas standard :))
Jinak souhlasim, ze NVMe disky jsou fajn vec. System se na tom chova pocitove svizneji, a kdo to vyuzije i jinak, tak proc ne.
Nicméně, jak jsem se teď dozvěděl, tak převaha Intelu u AVX výkonu by mohla celou balanci zase mírně převážit na stranu Intelu. Skylake X HEDT není zase o tolik dražší platforma než ThreadRipper, ba naopak, s některými CPU levnější a jde "vylosovat" intel HEDT, který se nechá taktnout na 4.8Ghz... Ale počkám až na 7nm Zen a 10nm Intel.
hmm,tak kolik by mělo umět m.2 ssd aby jste začal stříkat do textilu? Já mám čtení 3400 Mb/s a 2000 MB/s zápis a myslím že to stačí ale počítám že ssd sata bude s rychlostí podobně,více už dochází dech 4 pcie linkám a
Intel sklízí kyselé ovoce honění výkonu bez ohledu na cokoliv jiného, bezpečnost v to. Sice častokrát se i přes nejlepší záměry autorů objeví nějaká třeba i hloupá skulinka ale u firmy s obratem desítek miliard $ za čtvrtletí, dodávající i lidem, kteří na bezpečnost náramně hrají bych spíš věřil že hlediska národní bezpečnosti budou brát v úvahu...
Samozřejmě kromě totálního selhání připadá v úvahu i záměr, protože profi kryptovací SW je dnes tak dobrý, že se obsah rozumně nedá rozluštit pokud tedy neznáte klíč... Myslím že AMD bude mít brzy žně v oblasti IT krypto a Intel tu ztratí odhadem 100% trhu. Je otázka zda to pomůže když AMD je také firma ze stejné země ale aspoň si nenechali vyvinout architekturu v Izraeli :-)).
Umysl to není určitě. Kdyby byl, nefunguje to obecně, ale až po nějaké sekvenci instrukcí a dat.
Dva krát yacitujem článok
>Podle univerzitního týmu se na
>Skylake Core i7-6700K podařilo klíč získat s 99,8% úspěšností,
>na Broadwell Xeon E5-2620v4 s 98,2% úspěšností
>a na procesoru z generace Coffee Lake s 99,8%.
>takto koncipovaný hack mohl fungovat i na procesory AMD architektury Zen, neboť obdobu HT
>(SMT) podporují. Výzkumníci ale podobnou slabinu na Zenu najít nedokázali a podle
>pozdějšího vyjádření mluvčího AMD se ani specialistům ve společnost nepodařilo dosud zjistit,
>že by útok popsaný výzkumníky bylo možné na produktech AMD úspěšně použít.
V súvislosti s iným článkom na tému sú jasné dve veci. Najskôr citácia
"Gras také předpokládá, že nové procesory AMD budou mít úplně stejný problém. Používají totiž velmi podobný mechanismus umožňující běh více nezávislých vláken na jednom jádře. To také komplikuje ochranu aplikací před tímto typem útoku, protože správně napsaný program může odolávat na jedné architektuře, ale mírně odlišná architektura (i stejného výrobce) může znamenat problém."
https://www.root.cz/clanky/utok-tlbleed-na-procesory-intel-ohrozuje-sifr...
AMD to má podobné, ale dostatočne iné riešenie, a Intel-y samé majú dosť iné riešenia.
Mňa (ako Realtime-istu) zaujímajú neštandardné správania sa CPU a ich incidencia a tá lieta zaujímavo. Neštandardné správanie sa je, keď útok nefunguje na desktop CPU je o 0,2% (100-99,8) a na server CPU 1,8% (100-98,2), čo je ale 9x viac pri CPU pre server-e, kde by mala byť security first oproti desktopovým CPU, kde by mal byť performance first...
To ale znamená, že sa rizikom HT niekto v Inteli zaobera...
Nie nemusi sa zaoberat a mozno sa ani nezaobera. Tvoja uvaha ma slabinu. To ze serverovske CPU su na tuto zranitelnost nachylke 9x menej vobec nemusi znamenat ze sa tym v Inteli niekto zaobera.
Uvedom si ake ma Intel bezne desktopove CPU/APU, najcastejsie maju 4 fyzicke jadra (uz strasne dlhe roky) cim Intel pokryva vsetko od 2C2T az po 4C8T. Iba tot nedavno prislo 6 fyzickych jadier (novy kremikovy monolyt) a pride 8 fyzickych jadier (chudacik, donulita ho k tomu po dekade konkurencia).
Naproti tomu server bol rieseny 18-jadrovym monolytom pre vsetko 12-14-16-18C a po novom uz iba 28-jadrovym monolytom pre vsetko 20-22-24-26-28C.
To su tak odlisne kusky kremika, ze je tam rozna cache (latencie, sirka pristupu ...) a 20 inych veci, ktorymi sa Intel NIJAKO SPECIALNE ohldadom TLBleed nijako nemuel zaoberat. Je trocha rozdiel 4C8T a 28C56T procesor, v tom druhom je predsa len troska viac "rusenia" ked vlakno moze preskakovat z virtualneho jadra 0,1,2,3 .. az na 55. No a vo vysledku to nahodou hentak vydalo. Ze na tych zlozitejsich 28-jadrovych monolytoch (ktore mozu ma 0-2-4-6-8 jadier deaktivovanych) sa to dari 9x menej.
Počítače nefungují na principu náhody. Ani počítačem generovaná náhodná čísla nejsou ve skutečnosti náhodná. Jakmile existuje postup jak ukrást data sousednímu procesu (vláknu), tak je to jedno kolik máte jader - upravíte zákeřný program a maximálně to potrvá o něco dýl, ale ty požadovaný data dostanete. A to nemluvím o tom, že není těžké zjistit na kterém jádru běží proces, na který je třeba zaútočit.
Vezměme jako analogii útok heartbleed - útočníkovi se vátí pár kilobajtů a nevíte přesně odkud z paměti. Myslíte, že přidáním několika GB ram změní to, že vám útočník ukradne SSL certifikát?
Ale ty procesory se přece neliší jen v počtu jader....
Je to 9x 00 nic čili pořád nepodstatný rozdíl.
Práveže je to e veľa 9x. Lebo na porovnanie odlišnosti nie je základ podstatný
Ale prdlačky. Je rozdíl mezi 50% a 99% oproti 98% a 99%. V prvním případě je vidět že v první variantě je významný rozdíl ve druhá není rozdíl prakticky řádný. Na základu samozřejmě setsakra záleží.
Tým který by "zlepšil" výsledek podle té druhé varianty by dostal padáka sofort...
> Na základu samozřejmě setsakra záleží.
Podľa toho, čo meriate resp. , čo Vás zaujíma.
Ak bežná činnosť, tak medz 99 a 98% významný rozdiel nie je. Ak hľadáte neštandardné stavy, musíte ich navodiť, a ak je 98% práce štandardnej, tak oveľa ľahšie navodíte neštandardný stav. ako pri 99% času štandardného stavu.
Na základu prostě záleží vždy... Zbytek jsou jen výhovorky.
Krásně je to vidět právě u toho demagogického nesmyslu kdy o 1,6% lapší výsledek je vydáván za 9x lepší výsledek..
Já bych v tom demagogii neviděl. Pokud např ČR chce uzavřít smlouvu na informační systém (např. elektronické zdravotní karty), tak je důležité stanovit dostupnost systému. 99%=88 hodin v roce nemusí být služba dostupná, 99,9%=8,8h, 99,99%=53minut.
88 hodin nedostupnosti by někoho mohlo zabít, tedy základ 99% prostě není uvažován. Do smlouvy se dá požadavek na 99,9% a když uchazeč nabídne 99,95%, tak je to 4.4h nedostupnosti, čili 2x vyšší spolehlivost a uchazeč má plus.
Pokud je řeč o procesorech a ne o dokonalosti škrabání brambor, tak je základ 99,xy% rozumný.
Ale to není pravda, to že systém v průměru teoreticky může být ofline 2x kratší dobu neznamená že má 2x větší spolehlivost. Je to přesně to čachrování s čísly kdy si vyberu za základ zcela nesmyslně co chci a nazvu to něčím co má základ zcela jinde.
Spolehlivost je zde prakticky stejná liší se v setinách procenta co se liší je naopak možná "poruchovost". U těch karet je to navíc zcela mimo protože je to papírová hodnota vycucaná z prstu.
A u toho procesoru takové hodnocení postrádá smyslu, protože je mi šumafuk jestli mi ukradnou heslo na 98 nebo 99 procent ....
Ok, poruchovost je tady přesnější termín než spolehlivost. Papírovou hodnotu lze ale podepřít smluvní pokutou, takže dodavatel nadimenzuje systém tak, že je velká naděje na splnění.
Riziko ukradení hesla - souhlasím. Reagoval jsem obecně na procenta.
Ale já nepsal nic o procentech jako takových, ale hlavně o tom že setsakza záleží z jakého základu je počítám a když si vyberu nesmyslný základ tak jen oblbuju lidi nesmysly/demagogií...
A mimochodem vytvořit nějakou databázi či systém a dimenzovat ho na nějakou chybovost prakticky nelze. Je to otázka statistiky a tu lze stanovit vždy až poté co něco vytvořím a odzkouším. Například mohu nakoupit 1000 disků do serveru a počítat že mi do roka z nich průměrně 20 odejde protože předcházející disky ze stejné série prostě měli takovou poruchovost po nějaké době provozu, ale nemohu vytořit novou věc s určitou poruchovostí. Ta smlouva s dodavatelem jen a pouze zajišťuje odběratele proti ztrátám v příípadě nějakých neplánovaných problémů nic víc.
Su to proste ine kremiky, preto tie rozdiely. Ale ine nie preto, lebo sa v Inteli niekto pred dlhymi rokmi snazil znizit dopady dnesneho LTBleed. Ine su preto, lebo: malinkate monolyty pre desktop a giganticke monolyty pre server.
Minimálne mikrokód majú desktop a server CPU iný výkon optimalizovaný na iný typ úloh. U AMD to bol pri K8 jediný rozdiel. Aj Intel robil rovnaký kremík pre všetky typu CPU a podľa spoľahlivosti, dopytu deaktivoval časti a nahrával mikrokód.
Su to proste ine kremiky (aj ked je mikroarchitektura ta ista), preto tie rozdiely. Ale ine nie preto, lebo sa v Inteli niekto pred dlhymi rokmi snazil znizit dopady dnesneho LTBleed. Ine su preto, lebo: malinkate monolyty pre desktop a giganticke monolyty pre server.
To by clovek nerek ze 28 jader zabere vetsi plochu nez 4 jadra :). Ty jednotlivy jadra sou ale porad stejny (+- nektery ficury) a i ten hyperthreading a pristup do cache bude fungovat uplne stejne. Cili neni duvod si myslet, ze u Xeonu bude ten problem mensi...
No a won nefunguje uuuuuuuuplne stejne, je tam rozdiel cca 2% (1/50), vidne hausnumera 99,8 a 98 ci jak to bolo (nepamatam z hlavy a clanok som cital pred obedom).
Ako napr. Bulldozer a Steamroller: http://cdn.wccftech.com/wp-content/uploads/2013/07/AMD-Steamroller-vs-Bu...
Bulldozer a Pilledriver az taky rozdiel nebol, Pilledriver bol v podstate Bulldozer+ (asi ako Zen a Zen+) a Steamloller priniesol vacsie zmeny (napr. narast IPC o 5%) a Steamroller bol nieco ako buduci Zen2 v 2019. No a Exavator zasa priniesol zmeny a bol to v podstate Zen3 z roku 2020.
Ten rozdil je tech necelych 2% je ale mezi Broadwellem a Skylakem. To jsou dost rozdilny jadra. To nevypovida nic o rozdilu mezi Xeonem a Core i
Třeba ty serverové kousky statisticky o něco častěji jen vyčistí cache a kde nic není ani TLBleed nic nebere :-)
Treba. A treba je to naopak :).
Naopak? Jako že kde nic není, bere TLBleed všechno? :-)
:) Ne, naopak jako ze treba ty Xeony cache necisti tak casto ;). Nezalezi tohle spis na aplikaci nez na procesoru?
Mě začíná připadat, že to je vlastně jenom o tom, že ta architektura je stará a tudíž byl čas na ty chyby přijít a začít je zneužívat, a proto se musí záplatovat a je potřeba nové architektury. Jen aby potom strojové AI learning nenašlo způsob jak prolomit cokoliv :-) Vypadá to, že jak AMD tak Intel se už jaksi na dnešních výrobních procesech vyřádily a nějaké ty procenta výkonu navíc se už jen těžko hledají, takže se snaží více paralelizovat a každých 100MHz+ taky není na škodu. Asi to pomalu už začíná chtít něco jiného než křemík...
určitě, vždyť kdy přišlo první Core, že. A to vychází z Pentia M. Podle mě to Haswellem měli zabalit, dál už to bylo tvrdé vaření z vody.
Asi musím souhlasit :)
No těch 20% v serverech u AMD vypadá čím dál tím víc reálnější. Takhle se dá celkem rychle ztratit důvěra. A to se ještě neví co vyplave na povrch příště. Zajímalo by mě jak je na tom VIA, kde je Tralalák?
https://www.youtube.com/watch?v=gosY-UrpHcA
Intel je v nezávideniahodnej situácii. Ak bude aj naďalej odďalovať bezpečnostné opravy, bude postupne strácať dôveru svojich zákazníkov. Pokiaľ ale realizuje tieto opravy, výkon ich procesorov
rapídne klesne takže je to ako z blata do kaluže.
Neni ten utok dost nepravdepodobny? Musim donutit OS aby spustil kod utoku na stejnem "ht paru" jinak nezafunguje. To budto muzu udelat a pak mam i prava na ptrace a nemusim se zatezovat necim takovym. Nevo prava nemam a musim spolehat na stesti pricemz linux obsazuje threadem jineho procesu druhe jadro v paru az kdyz neni jina moznost
Tak já tomu tak hluboce nerozumím, ale myslím, že inženýři u Intelu nejsou úplní pitomci a proto bych si nevyložil to, že to Intel nehodlá opravovat, jako zase nějakou sviňárnu, ale jako to na co narážíš. Že oproti spektře a meltdownu to není tak akutní a proto se s tím nebudou srát. Něco jako když se nedávno snažil někdo potopit AMD, že má taky prý obrovskou díru, ale musel bys do desky nahrát custom bios aby si ji mohl exploitnout.
Problém je,že to je ľahko riešiteľné tak ako STIBP
35:20-37:42
https://www.youtube.com/watch?v=rwbs-PN0Vpw&feature=youtu.be
Ono stačí zdvojiť TLB, tak ako má AMD zdvojený branch predictor pre SMT, tak tu stači zdvojiť TLB alebo TLB tagovať a máme po tomto probléme.
Problém je, ak máme strašne veľa CPu na sklade, alebo strašne málo na sklade, lebo prvé CPU so zmenou môže Intel dodávať najskôr 130 dní (40 dní výroba a 90 dní testovanie) po začiatku výroby opravených. Súčasnou dodávkou opravených a neopravených čipov, by si Intel poškodil povesť viac, ako dodávakou len neopravených čipov...
Intel poškodit pověst? To ještě jde?
https://stackoverflow.com/questions/4886886/assigning-a-thread-to-specif...
Vynucení si běhu na konkrétní CPU není jediný způsob. Všiml jsem si, že OS obvykle přehazuje vlákna rovnoměrně přes jádra CPU. Vážně si myslíte, že je to tak složité dostat se na konkrétní jádro?
Už mě napadá pár dalších způsobů....
Chapem ze dnes uz nejak nieje cas na detail, a ze clanky su v zasade prelozene vycucy zo zahranicnych sprav, ale pre boha nech to ma hlavu a patu.V clanku sa pise o uspesnom precitani bezpecnostneho kluca. Ale akosi komplet vypadli suvislosti. Takto clovek ani nevie akeho kluca, odkial, a iba nejaky magicky 256bitovy kluc sa tak da precitat ? Zdrojove clanky to popisuju zmysluplnejsie. Toto tu nieje ani google translate..
A není to v populární formě jedno? Existuje způsob jak se dostat k šifrovacím klíčům v paměti, ke kterým by se dát dostat nemělo. Hotovo. Pro většinu neprogramátorů to je informace až až dostatečná. Kdo chce zkusit exploit, nebo zabezpečit server, najde si detaily.
No ono je popravdě dost rozdíl, jestli ta metoda umožňuje skutečně krást hesla útočníkovi bez oprávnění a nebo je to jen nějaký akademický příklad k jehož realizaci je potřeba naplnit takové podmínky, kdy by člověk ani žádné heslo lámat nemusel.
Není to akademický příklad. Proof koncepty exploitů existují a jsou veřejně dostupné. Jejich zneužití pak nic nebrání. Tedy brání správně opatchované jádro, jehož hlavní zbraní proti zneužití díry je úprava chování plánovače.
Jde o to že abych mohl nějaké heslo přečístt tak ho zrovna musí nějaký proces používat a zároveň musím mít možnost jiným procesem ty data přečíst a někam poslat ne?
Tak nerad bych se mýlil, nejsem na tohle odporník, ale když je otevřené nějaké šifrované prostředí nebo spojení, tak je šifrovací klíč trvale v paměti (a cache), protože je potřeba v operacích nutných pro dešifrování, ne? Takže, že se to potká na stejném jádře bude šance docela vysoká.
Zdá sa, že nešlo iba o teoreticky útok: "Pomocou toho TLBleed vzhľadom na známy spôsob fungovania sledovaného algoritmu dokáže spoľahlivo zistiť privátny EdDSA kľúč, ktorý využíva druhý proces bežiaci na rovnakom jadre na kryptografický podpis pomocou knižnice libgcrypt."
Viac tu: http://www.dsl.sk/article.php?article=21277&title=
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.