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.
Po přečtení nadpisu jsem se fakt hlasitě zasmál, takže LOL. Zatímco u Microsoftu se můžeme spolehnout, že každá velká aktualizace někomu roze*ere systém, u Intelu se můžeme spolehnout na pravidelnou dávku dalších a dalších bezpečnostních zranitelností. Mám strach, že si lidi zvyknou a toto všechno se bude brát jako norma.
To je určitě fejk jak bejk, Každý přece ví, že síto díry nemá !!!
Pohádka o 1000 a jedné díře.
Pohádky o 1024 dírách by byly trefnější... ;)
MEME:BOYS WE DID IT, INTEL IS NO MORE
plundervolt....thunderbolt....???? foneticka nahoda :D
Začínám si více vážit svých Piledriverů FX-8300 a FX-6300 koupených ve výprodeji. Skylake je dnes fakt koupě z hladu nebo pod vlivem.
Mně to skoro připadá, že někdo ty díry v těch Inteláckejch procesorech hledá za každou cenu, i kdyby je tam měl sám navrtat. Že někdo přijde na to, jak zrovna takovouhle funkci zneužít k útoku na data, to by mě ani ve snu nenapadlo. Si to představte: máte třeba pevný disk s hardwarovým šifrováním a půjdete po tom, jestli by se z něj nedal šifrovací klíč vytáhnout přes funkce správy napájení. Prostě bizár hárdkór.
Mě spíš zaráží, že ty chyby nikdo nenachází na procesorech AMD. Není možné, aby byl Intel tak děravý a u AMD na tohle všechno mysleli a měli to ošetřené a neprůstřelné.
linux je taky bezpečnější než windows i z toho důvodu, že je to minoritní platforma :)
Minoritní na 88 % chytrých telefonů?
sem si nevšiml že android je považovaný za nejlepší linuxový projekt jaký kdy tady byl, protože úspěch androidu je enormní a pro linux udělal úplně nejvíc
Ja si myslim, ze jde o popularitu tech "vyzkumniku". Tedy tusi chyby na Intelu, tak stouraji tak dlouho nez na neco prijdou.
U AMD, ktere neni tak provarene a ani nema takovy impakt, tak hledani chyb neni tak moc zajimave jako prave u Intelu.
Je take velkou otazkou, jestli pojem CHYBA je spravne oznaceni. Naprosta vetsina dnesnich "chyb" na procesorech jsou ve skutecnosti zamerne implantovane funkce, ktere k necemu slouzi, at uz je to uspora energie nebo navyseni vykonu. V dobe, kdy ty funkce byly navrzene nikoho nenapadlo, ze jednou nekoho napadne ty funkce zneuzit.
Osobne a zcela konkretne mi u Intelu vadi jedna vec, ze kdyz uz to nekoho napadlo, jak to zneuzit, tak Intel dal pokracoval ve vyvoji procesoru s temito zneuzitelnymi funkcemi, tudiz minimalne rada Coffee Lake a cast rady Coffee Lake Refresh nemela vubec spatrit svetlo sveta.
Jo to by mě taky zajímalo, tohle bude spíš záležitost fyziky než architektury. Ale mám pocit, že AMD SGX nepodporuje (ale třeba do toho servisního ARMu by se takhle možná takhle prolomit dalo taky).
na akademické půdě asi nic úplně nenormálního, těch "magorů" a hračičků je tolik že zkouší všechno možný, aby si nahonili ego :)
Naopak anomálie napájení je věc se kterou se nejspíš setkalo skoro každý dítě v 90. letech. Do týhle věci https://www.youtube.com/watch?v=ZhC16-e_gSs stačilo strčit slabý AA wonderky, zapnout zvuk a interní paměť kódu se zhroutila. Pak třeba fungoval had, kterýmu se nemazal ocas nebo různé grafické glitche.
Jinak manipulace s napájením je dost častý v prolamování kódů, u některých zamknutých MCU je šlo tímhle odemknout a i pri obyčejných podtaktování se taky sleduje zda budou náročné operace stabilní (= nebude přeskakovat bit).
Podle mě to zase tak moc chyba není. Když deterministický systém vystrčíš mimo jeho pracovní parametry, tak začne dělat koniny.
Samozřejmě to platí i pro nedeterministické. Některé ženy vyžadují při sexu škrcení protože nedostatek kyslíku v mozku způsobí intenzivnější orgazmus. To jsem ale odbočil, tak trochu.
Myslím si, že jde z většiny o důsledek příliš dlouhé existence jedné architektury na trhu. Dříve se taky objevovaly zprávy o různých dírách (byť méně často), ale většinou se to týkalo architektury, která už nebyla na trhu, takže to bylo většině lidí prakticky jedno. Deriváty Skylake jsou tu už velmi dlouho (Haswell a Broadwell se navíc příliš nelišily) a za tu dobu se zkrátka slabiny najdou. Navíc bych řekl, že čím víc je na to téma publikováno, tím je známo více objevů, na kterých lze stavět při dalším výzkumu, nebo kterými se lze inspirovat.
Druhá věc je, že si Intel pod sebou možná podřízl větev, když (ještě v pre-Spectre/Meltdown) době začal za nalezení díry nabízet peníze. Lidem z univerzit zaplatí grant univerzita nebo jiný grantový subjekt, když to odpublikují, mají impakty, za které jsou často finančně hodnocení a ještě dostanou kapesné od Intelu.
>Inteláckejch procesorech hledá za každou cenu
ani nie, ono sa spájajú veci ako napr.
BPF and the realtime patch set
October 23, 2019
The thread started with a patch posted by Sebastian Andrzej Siewior to the BPF mailing list. The patch mentioned three problems with BPF running when realtime is enabled and added Kconfig directives to only allow BPF to be configured into kernels that did not have PREEMPT_RT:
Disable BPF on PREEMPT_RT because
it allocates and frees memory in atomic context
it uses up_read_non_owner()
BPF_PROG_RUN() expects to be invoked in non-preemptible context
#1) BPF disables preemption unconditionally with no way to do a proper RT substitution like most other infrastructure in the kernel provides via spinlocks or other locking primitives.
#2) BPF does allocations in atomic contexts, which is a dubious decision even for non RT. That's related to #1
#3) BPF uses the up_read_non_owner() hackery which was only invented to deal with already existing horrors and not meant to be proliferated.
For now, users of BPF will not be able to use the realtime patches and vice versa.
https://lwn.net/Articles/802884/
To je ale paradoxné, lebo dnes sa v Realtime riadení používajú sieťové riadiace systémy a na bezpečnosť siete sa používa Berkley Packet Filter (BPF).-..
A tak sa prišlo aj na Spectre/Melrdown a celú triedu chýb.
1. V Realtime je problémom neurčitosť latencie (jitter) a tá je spôsobená činnosťou prediktorov a teda sa manipulovalo prediktormi
2. Aby bol realtime, rýchly správne dáta musia byť v cache . A ako zistiť, či boli dáta v cache? Na to prišli
Spojením vznikol Spectre v1 a už sa len menili body 1 a 2.
Může to být lavinový efekt. Jakmile se objevili první zprávy, tak lidi z IT akademické sféry zjistili, že se na tom dá docela zkoumat/publikovat. Docela to tak funguje u všeho nového co se dobře "prodá".
Další generace na 14nm+++++++++ bude Sieve Lake.
vypocul som si podcasty zo server prostredia, ono to fakt u ludi bubla jak svin. kto mohol, zmigroval na epyc. (nie kazdy ma tie moznosti, naplanovanie-validacia-migracia, radove az roky.)
niektore zaplaty nemaju brutal efekt na desktope, ale servery "idu dolu".
co urobis ak si limitovany priestorom a infrastrukturou, a zaplaty vzali ~50% perf..? dalsie servery uz nemozes dokupit
zaplaty foreshadow, ridl, zombieload, fallout je vykonnostne najhorsi.
vypnut intel smt, a througput ide do prd**. dalsi problem ma suvis s iommu (direct caching), cize pcie karty,diskove prenosy sposobuju perf lag. dokonca nie je mozne pouzivat gpu na vypocty.)
----------------------
mozno to vypada ze amd dotuje hladacov dier, ale su to najma univerzity, komunita co nasli problemy... ak si pamatate, tak univerzitu chcel intel uplatit aby sa to nedostalo von... kde je pravda?
ze vraj amd validuje a testuje jednotlivo "entity" -stavebne bloky v cpu, maju ich prepojene ako siet.
asi to je dovod, preco amd tieto sracky nema. naviac epyc dokaze sifrovat vsetkych 8ch ddram ..
amd nesli na speculative execution (a ine rizikove ficuriny), intel isiel..
proste max vykon za kazdu cenu...
v poslednej dobe epyc ma slajdy plne "security, safety, atd". to je symfonia pre server adminov.
Kdo ti řekl, že AMD nepoužívá speculative execution?
Rozdíl je, že u Intelu se spekulativně provádí úplně všechno jak utržené ze řetězu bez ohledu na přístupová práva k paměti, oprávnění procesu (CPL), atd. a kontroly se provádí až před sekvenčním zápisem výsledků instrukcí zpět do registrů. Pokud se spekulativně prováděný úsek kódu nakonec nemůže dokončit (např. kvůli chybně předpovězenému podmíněnému skoku nebo chybnému přístupu do paměti), tak se výsledky zahodí a jede se dál jako by nic. Bohužel ne všechno se dá obnovit do původního stavu, a tak jakékoliv spekulativně provedené změny v cache, prediktoru skoků a dalších 'transparentních' subsystémech se zachovají. Pak už stačí jen chytře spekulativně provádět kus kódu 'za hranici kontrol' a pomocí časování přístupu do paměti se podívat jestli se cache změnila nebo ne (=Spectre). Já osobně to nepovažuji za klasickou chybu jako FDIV, ale za velmi promyšlenou metodu zneužití konkrétní implementace architektury procesoru. Podobně je tomu i u zneužití branch prediktoru, různých paměťových bufferů, apod. Ale naprosto souhlasím, že Intel s tím měl při návrhu počítat a vyvarovat se většině slabin. Teď jsou na pár let v loji než dají dohromady a kompletně odladí novou a výrazně předělanou implementaci, která bude poskytovat stejný výkon a přitom bude bezpečná. Nezávidím jim jejich pozici...
V AMD byli opatrnější a zjevně implementovali kontrolu oprávnění i do spekulativního provádění instrukcí, takže se neprovádí za "zákaz vjezdu". Je to náročnější, pravděpodobně o něco pomalejší (musí se čekat na přístupy k tabulkám stránek do paměti), ale zjevně bezpečnější.
Snad kromě Atomu a nějakých malých SoC chipů se speculative execution používá prakticky všude, i na ARM architektuře v mobilech...
Pomalejší to být vždy nemusí, pokud předem zahodí zakázanou větev, že.
A jak dopředu poznáte, která to bude?
To jsem řekl blbě, resp. je to blbost. Nemusí to být větev, ale kus nezakázanýho kódu (všechno je větev), kterej ovšem končí/obsahuje dotaz do zakázané oblasti (cache). AMD to zřejmě nějak koherentně hlídá (nějakým příznakem) a je pravda, že jestli to AMD stojí nějaký výkon (tahat s sebou ten flag), to samozřejmě nemohu vědět, ale je možný, že ne (jsou i jiný flagy resp. přístupy k oddělení kódu). Ale urychlilo by se to minimálně zahozením větve toho spectre útoku (u Intelu spíš vyhozením modré exception).
Vše vyřčené v kontextu nějakých bezpečnostních mechanismů translation lookaside buffer a register flush/purge (probíhá někdy? jak často?) a podobných. Whitepaper jsem nečetl.
Obávám se, že intelí backdoors se otevírají i při normální voltáži. No co, kdo si "hraje", nezlobí a není pro psychopatické elitáře nebezpečný. Ještě necelé dva roky...
Obávám se, že intelí backdoors se otevírají i při normální voltáži. No co, kdo si "hraje", nezlobí a není pro psychopatické elitáře nebezpečný. Ještě necelé dva roky...
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.