Názory k článku Chyba PortSmash umožňuje krást klíče přes Hyper-Threading
-
Hdjjd (neregistrovaný)
Uz nekdo z vas u vsech tehle "preslechovych" utoku videl praktickou ukazku jak nekdo nekomu neco realneho odposlech?
Nebo je to zatim "za presne teploty v laborce, kdyz presne posleme do jednoho tasku tyhle instrukce a kdyz se korelace na 50. pokus zdari aspon na 0.3 a kdyz nikdo nekejchne, tak prohlasime, ze se takhke da odposlouchavat...
-
Petr M (neregistrovaný)
Mějme šatnu, kde se odděleně v kabinkách převlíkají muž i a ženy. Pokud není zástěna pevná od podlahy ke stropu, jak zabráníš chlapovi, aby načuhoval vedle, když klíčky od kabinek přiděluje automat, který neví, kdo je šmírák?
Procesor v tomto případě není jenom tupá krabička, ale má vlastní "inteligenci" - rozhodování, co natáhnout do CACHE. Prediktor skoků. Mikrokód. A další blbiny kolem. U x86 se CISC instrukce emulují na RISC jádře a instrukce x86 je program pro interní procesor. Někdy trvá pět instrukcí, jindy třeba osm. Prostě vidíš, co se tam děje, když sdílíš železo. Někdo ignoruje, co se za přepážkou děje, ale obecně se tím nemusí řídit všichni.
Btw, CISC instrukce obecně trvají různě dlouho, vem si jenom načtení opkódu u hloupé Z80 - použij index registr a místo 8b má instrukce 16b. Instrukce s prefixem to samý. V základní sadě RET načítá 1B, CALL 3B, ADD 1 nebo 2B podle toho, jestli přičítáš registr nebo konstantu. Jedna instrukce 4 takty, jiná 7 taktů. Tam to ale moc nevadilo, tam neběželo další vlákno s monitoringem. Ale když stejný jádro dělá dvě různý věci, tak se prostě vzájemně vidí a když e jedna z těchvěcí rozhodne šmírovat, operační systém (automat vydávající klíče před vchodem) to neovlivní.
-
LDASCZ (neregistrovaný)
Je mnoho lidí co mají vysokou odbornost, ale třeba moc krasopisně/správně psát neumí (ovšem třeba v IT umí věci/zná věci, které by nenapadli ti co psát úžasně umí). Takže ten kdo moc neumí jazyk tak by jsme ho měli ignorovat?
Je to zhovadilost, již v minulosti bylo mnoho osobností, kteří neuměli skoro mluvit či vykoktat ze sebe nějakou větu, ovšem vytvořili/vymysleli tolik unikátních věcí.
-
SB (neregistrovaný)
Neokecávejte to. Opožděných lidí a lidí s poruchami zas tak moc není, většina Čechů je schopna se naučit na vysoké úrovni svůj jazyk a používat jej, ale je na to prostě líná. Naopak se nabízí otázka, zda se ta jejich lenost a lemplování nepromítá (nejen) i do profese. Moje zkušenost říká, že ano.
Takže pro mě je úroveň jazyku hodnotným ukazatelem úrovně člověka. Výmluv jsem slyšel za posledních 20 let 3 pr-dele. -
LDASCZ (neregistrovaný)
Vaši aroganci bych chtěl mít. Divím se, že vám za toto ještě někdo nedal pěstí.
Doufám, že až půjde k vám nějaké řemeslo domů a bude umět plyně anglicky něco zmrví. "Má zkušenost říká, že ano"
Ano jsou líní lidé (netáhla), ale určovat inteligenci na základě umění říct jiným jazykem je někde na pomezí 16-17 století. Už v té době todle rychle zanevřeli a drželi se těch co to opravdu umí. Těch lidí co nakecají jak tomu rozumí byť cizím jazykem znám na všech deseti.
A abych vás nasral, tak já určuji inteligenci na základě vyjadřování a jazykové obratnosti (nepočítám pravopis, sám jsem sadista v tomto ohledu). Z vašeho jazykového skládání, tipuji že jste ze střední školy či vysoké a na řemeslnou práci jste v životě nesáh. A člověk, kterej toho nakecá z definic je mnoho a prakticky tyto lidé jsou v životě/profesích nepoužitelní.
-
j (neregistrovaný)
Az na to, ze ten klicnik u dveri vydava klice k jedny kabince, a nekomu vadit nemusi, ze tem budou zensky i muzsky pokupe, kdyz mu to ale vadit bude, tak ten klicnik naprosto vpohode muze nejdriv dovnitr pustit 10 zenskych a az je vsechny vykopne ven, tak teprve pak tam pusti ty muzsky.
Podotykam, ze spolecny satny jsou naprosto bezna vec na spouste mistech. Kupodivu z naprosto stejnyho duvodu proc se pouziva spolecnej CPU - lepsi vyuziti zdroju (skrinek).
Tahle "chyba" mi prijde asi tak stejne objevna jako ze kdyz vylezes v desti pred barak, tak ze zmoknes.
-
SB (neregistrovaný)
Podepsané být nemusejí, to stačí zařídit jako informaci z repozitářů, které podepsané jsou. Jinak řečeno by mělo stačit mít možnost označit procesy jako citlivé, kterým by pak i za cenu zpomalení nebylo umožněno využívat některé prostředky procesoru jako např. onen hyperthreading.
-
jdsulin2 (neregistrovaný)
Nebo tak, to co rikas by i vyresilo dalsi chyby procesoru. Nakonec bychom meli 3 rezimy:
1) Basic- OS nevi nic o programu, tzn. tento program je bezpecnostni riziko, takze nemuze sdilet procesor s necim jinym (i kdyz do doby nez prisla tahle chyba jsem mel za to, ze sdilet HT jadro lze pouze v ramci jednoho procesu ruznymi vlakny). Zaroven se u tohoto procesu nenamapuje jadro, coz pomuze vyresit predchozi chyby. Takova to uprava bude mit samozrejme dopad na vykon.
2) Hardened - Aplikace pozaduje takove prostredi, aby se na stejne jadro nikdy nedostal cizi proces. Namapovani jadra nevadi, protoze tento proces povazujeme za verohodny. Vykon klesne pouze v pripade, ze bude spusteny jiny proces a neklesne vubec, pokud proces vyuziva sudy pocet pracujicich vlaken. Na stejny procesor bych pustil jedine stejny proces v jinem vlakne nebo druhou instanci stejneho procesu (napr. worker procesy http serveru).
3) Permissive - Tento proces povazujeme take za verohodny, ale nevadi nam, kdyz bude jeho data cist jiny proces. U takoveho procesu neklesne vykon. -
MasoxCZ (neregistrovaný)
A nebude ti vadit, když malware nahodí režim hardened a sejde se na jádře se kernelem? Protože přesně tak to v tebou předpokládaném případě 2) dopadne.
Rovnou to můžeš zredukovat na režimy dva:
1) jsem malware / je mi jedno když se s ním sejdu vs.
2) jsem jádro / privacy-aware aplikace a požaduji být na jádře jen sám se sebou. -
Petr M (neregistrovaný)
Právě naopak, aplikace si musí říct:
1) Je mi to jedno, jak pojedu
2) Chci výkon i za cenu ztráty soukromí
3) Chci soukromí i za cenu ztráty výkonuPokud si aplikace sama nastavuje, jestli je útočník nebo ne, tak se nezmění vůbec nic. Prostě útočník nastaví jeden bit a je vysmátý.
Pokud si ale řekne, že chce ochranu, tak jádro ví, že se k tomu má chovat jinak. Při útoku jinýho procesu ten jiný proces nemá páky na to, aby se vetřel na stejný jádro, nebo jel hned po kritické aplikaci bez přemazání cache a branch prediktoru. Pokud proces řekne, že chce hlavně výkon, tak se holt nemaže cache a potká se s kýmkoliv v HT. To je ale volba toho vlákna nebo procesu.
-
j (neregistrovaný)
A ted zapremejslej nad tim, jak neco takovyho zaridis ve virualnim prostredi, kde ti pod systemem bezi jinej system, o kterym ten virtualizovanej vlastne vubec nevi, a ve skutecnosti ti klidne muze nabizet trebas 30jader, i kdyz jich fyzicky ma 10. A zkus si predstavit, ze by ten backend hodlal tvoje prani splnit, tudiz by z CPU vykop vsechny ostatni virtualy ... a cely by se to pekne slozilo.
Paradni navod na dokonalej DOS.
-
Petr M (neregistrovaný)
x86 je prostě děravý šrot. Ono to ani, vzhledem k jeho vývoji, jinak být nemůže.
To se takhle vezme CISC s různě dlouhýma a pomalýma instrukcema, a začne se zrychlovat. Až se narazí na nějaký limit a dál to nejde. No a co uděláme? Rychlý RISC a instrukce je vlastně různě dlouhý podprogram.
Jenomže ono to nejde jako u klasickýho RISCu udělat tak, že stejná ALU mimo svou práci inkrementuje PC a připočítává offsety. Nene. My tady máme oddělený program counter od registrů (ze základní architektury) a chceme zrychlit, tak mu dáme vlastní ALU. A takhle to nasekáme, aby se to nehádalo. A pak najednou zjistíme, že se hlavní ALU 2/3 času fláká. No a co s tím? Sdílet ji budeme, ušetří to plochu čipu a dovolí vyšší rychlost.
No a že se tam na fyzické úrovni míchají data, který se nemají potkat, že se sdílí i překlad adres, prediktor skoků a další věci okolo? Že se potkává cache? Že je vidět, kolik která instrukce vykoná instrukcí v mikrokódu? Že někde zůstane nějaký flag nebo mezivýsledek mikrokódu ve skrytým registru? Že je tam plno dalších podobných průšvihů? Who cares?
Spíš než do HT měli jít do vyhození prediktoru skoků a ten výkon použít na to, že se vykonávají spekulativně instrukce z obou větví jednoho vlákna a po podmíněným skoku se polovina práce, vykonaná od načtení instrukce, zahodí. Sice to nezvýší výkon tak razantně, ale bezpečnost to zvýší drasticky.
Anebo hodit bobek na x86, ušetřit si paměti mikrokódu a infrastrukturu kolem, místo toho tam nasekat víc čistě RISCových jader s vyšším výkonem a hotovo. Každej svou L1 cache, aby nebylo podle přístupu ke sběrnicím vidět, čím se aktuálně zabývá a je to vyřešeno.
-
unicode (neregistrovaný)
1. To vůbec není CISC vs RISC problém.
2. I v RISC architektuře můžou mít instrukce různou délku a časování (např. Thumb, RISC-V).
3. Oddělěný PC (program counter) je výhoda a např. ARM64 i RISC-V to má taky tak. U ARM32 je dnes vidět, že považovat PC za obyčejný registr byla chyba v návrhu.
4. Jednotku pro počítání adres (AGU) mají snad všechny procesory a není to problém.Zbytek nestojí za komentář. Takže pár mýtů jsem dnes vyvrátil a můžu jít pracovat :)
-
Z principu, jakákoliv technologie, která se snaží využít jeden prostředek (společná pipeline, společná cache, predikce) bude vždy jednomu procesu dávat indicii o tom, jak probíhá proces druhý. To vždy bude představovat určité riziko, nejen na serverech, ale i na běžných pracovních počítačích. Teď jde jen o to, kolik kritických procesů dokážeme odizolovat (např. nastavením afinity) od těch uživatelských, jak důkladně takové odizolování bude vypadat a jestli přínosy technologie převýší riziko.
Ani ve výše zmíněné šatně nelze zabránit, aby v tenké stěně někdo nevyvrtal šmírovací díru. Nebo by bylo potřeba postavit stěnu železobetonovou a každé dva týdny posílat inspektora ověřit stav zdí. V případě šaten dají lidé, jsem přesvědčený, přednost sádrokartonové příčce a levnějšímu vstupnému.
Problém izolace procesů je o mnoho větší za použití virtualizace. Zatímco samotný OS může do jisté míry kritické procesy chránit a ostatní procesy izolovat, tak při virtualizaci tuto výhodu ztratí. Pak už je možné jen všechny tyto technologie, které zefektivňují běh, povypínat a běžet na hrubém, neoptimalizovaném výkonu a v taktu procesoru - tak, jak tomu bylo do éry Pentia 4.
-
unicode (neregistrovaný)
Celkem souhlas až na tu izolaci. Praxe nám ukazuje, že jediná izolace bude vypnout HT úplně, protože když to neuděláme, tak si útočník tu cestu vždycky najde a objeví nové chyby. To co se teď děje bude mít vliv na budoucí generace CPU a řekl bych, že HT půjde do důchodu. Možná se dočkáma na X86 něčeho typu Big-Little kdy bude procesor kombinace různých jader a při powersave bude využívat ty slabší. Otázka ale je, jestli by to vůbec mělo smysl.
-
j (neregistrovaný)
Vypnout HT ti vubec nepomuze, protoze jednotlivy CPU toho sdilej daleko vic. Jediny reseni by bylo abys nejak (nejlip na urovni HW) zaridil, ze nikdy nepovezi vic nez jedina uloha ... jo aha, to je presne ten duvod, proc se delaj viceprocesorovy stroje. A dokonce bys ani nemel dovolit beh vice threadu jedne ulohy, protoze ani ty by nemely mit moznost ziskat data o jinym threadu.
-
V tomto ohledu by stačilo, aby stejné fyzické jádro (ale klidně více HT vláken) sdílel ten samý kritický proces. Např. volání jádra nejsou sama vůči sobě považována za nebezpečná. Nebo ten samý proces s více thready není nezbytně nutné považovat za nebezpečný vůči sobě (pochopitelně antiteze neplatí: ne každý proces s více thready je možné považovat za bezpečný vůči sobě - např. webserver).
-
VLM (neregistrovaný)
Když se po desíti letech vypustí mezi běžnou IT veřejnost záludnosti návrhu x86 architektůry tak jsou všichni moudří jak je všechno špatně. Při návrhu jde pokaždé o kompromisy a neočekávalo se že se najdou skupiny které budou takt po taktu celý návrh podrobovat zkoumání. Navíc řádově za tu dobu narostlý možnosti si nějaké polovodičové struktury emulovat.
-
Karel (neregistrovaný)
Ono je to důsledkem jednoho zlomu v uvažování. O těhle vlastnostech se prostě roky ví. Spekulativní vykonávání instrukcí, HT apod. se vše používalo s tím, že tam jsou jistá rizika. Ta se ovšem naprosto bezchybně technicky vyřešila a vše mělo být bezpečné. V duchu "nevadí, že spekulativně čteme z paměti, kam nesmíme mít přístup, protože se to pak stejně zahodí a proces ta data nikdy nedostane".
Ta změna v uvažování by se dala nazvat souhrnným názvem "postranní kanál". To je něco, o čem jsme prostě neuvažovali. Drtivá většina lidí žila v domění, že když ta data nedostanu do svého registru nebo do své přístupné paměti, tak se k nim prostě nedostanu. Ale najednou nám někdo ukázal, že i když se k těm datům nedostanu, tak je vlastně dokážu uhodnout pomocí naprosto nesouvisející technologie jako je například cache a měření rychlosti přístupu do RAM.
Teď, když víme, že postranní kanály existují a jdou využít, tak najednou vidíme i ty mraky pastí, co jsme do procesorů za ty roky nasekali. Proto je najednou tolik moudrých, kteří vidí, jak je všechno špatně. Prostě jsme si mysleli, že když jsou mezi dvěma procesy mříže, tak nic neprojde. Letos už ale víme, že se řada věcí dá dostat i skrz tu mříž. A najednou se děsíme, kde všude jsme ty mříže postavili a spoléhali se na ně. Proto nemine měsíc, aby někdo nepřišel se zprávou typu "já se byl podívat v kuchyni ve druhém patře a představte si, že mezi prostorem kuchyně a jídelnou pro veřejnost jsme také dali jen mříž!"
-
Tom (neregistrovaný)
tahle záplava zranitelností CPU v posledních měsících je opravdu v důsledku toho, že jsme doteď opojíjely postranní kanály a schopnosti statistiky. Zranitelnosti se netýkají pouze Intelu, má obrovské zastoupení a poměrně dost mikrotoptimalizaci, takže je nejvíce na ráně, problém má celé odvětví CPU.
Tohle se nedá záplatovat, musí vzniknout výrazně upravená architektura procesorů (ne nikoliv instrukční sady).
-
Petr M (neregistrovaný)
Bylo.
x86/64 jádro je komplikovaný, velký a rozežraný. Fyzicky se na jeho místo dá narvat několik menších jader jiné architektury (protože odpadne řada věcí - paměť mikrokódu, nějaký stavový automaty pro vykonávání instrukcí,...) .
Jestli pro čtyři virtuály máš jedno jádro, nebo pro každý z nich extra jádro s 1/4 výkonu je z pohledu plochy čipu, spotřeby a výpočetního výkonu celkem jedno. Co není jedno je, že oddělený jádra můžou mít dedikovaný FSB a řadiče pamětí, takže se zvýší propustnost pamětí. A že si virtuály nevidí pod pracky.
A hodně blbý na architektuře x86 je, čím si prošla a s čím vším drží (částečnou) kompatibilitu.
- Od osmibitu (8088)
- Na 16b s obskurním segmentovým 20b adresováním,
- Pak na 32b s 16b sběrnicí,
- Následovaný 32b s memory managementem,
- s vestavěním FPU (původně extra brouk x87)
- Překlopený interně na RISC, doplněný o hafo řezů a opičáren jako branch prediktory.
- Překopaný z von Neumanna (sdílení paměti programu a dat) na maketu von Neumanna z harvardem uvnitř a přilepením I cache a D cache
- Následně přebouchaný na 64b AMD64
- a to celý okořeněním sdílením jednoho jádra mezi dva procesy
- a s několikrát překopanou a rozšířenou instrukční sadou (MMX, SSE, SSE2, ...)
- rozšířený na mutiprocesorový monstra
- navíc s několika úrovněma CACHE, všelijak pochybně sdílenýma
V tom už se ani jeho výrobce nevyzná. -
jm (neregistrovaný)
* miliardy USD na vývoj CPU s jinou architekturou výkonnostně porovnatelných se současnou x86
* biliony USD na portování stávajících aplikací na novou architekturu, včetně řešení chyb, které vzniknou takovou portací.Výsledek? Možná to bude bezpečnější a jednodušší. Teda pokud nová architektura nebude ve výsledku stejně zabugovaná jako x86.
-
agent (neregistrovaný)
Současné CPU rozpůlit, půlku nechat v současném stavu kvůli kompatibilitě 16 a 32 bitových aplikací (s vypnutými nebezpečnými features) a drůhou půlku navrhnout moderně bez zpětné kompatibility pro nevé aplikace. A vzajemnou velikost těch "půlek" postupně s dalšími modely měnit.
Nebo dvě patice na CPU vedle sebe (klidně pod jedním chladičem) a uživatel si rozhodne co a s jakým výkonem potřebuje. -
Petr M (neregistrovaný)
Prdlajs.
1) Nepotřebuješ miliardy na jinou architekturu. Ty miliardy šly do litografie, ne do zapojení čipu. Je úplně jedno, jestli do 10nm technologie hodíš x86, nebo něco jinýho.
2) Frekvenci jádra budeš mít pro stejnou technologii stejnou. Pokud v dané technologii x86 dá 3GHz, hádej, kolik dá jiný jádro? Rozdíl výkonu je v mikroarchitektuře.
3) Správně napsané aplikaci je na 99% jedno, pro jakou architekturu ji zbuilduješ, pokud se optimalizace kompilátoru chovají podobně. Nejede totiž na železe, ale nad OS, popřípadě nad VM který zůstanou stejný. Takže třeba Java, JavaScript, C# a další prostě pojedou, pokud bude stejný runtime a stejný API. Mega částky půjdou maximálně do aplikací, kde se obchází systém - a to je většinou kvůli neznalosti vývojářů. Takový soft je už teď zprasený a neudržovatelný a může se rozbít při jakékoliv aktualizaci. Měli jsme embedded SW, který běžel na ARM9EJ-S. Ty samý zdrojáky v C jsme buildovali i pro x86 pro ůčely dema a testování, jediný požadavek byl oddělení HAL.
4) K přepisu bude část ovladačů. Ony totiž periferky většinou jedou už nad nějakou abstrakcí (PCIe stack, USB stack0, platí to, co pro aplikace. Nezměníš-li interface, řádek se změní na jinou řadu jedniček a nul, ale dělá to samý.
5) Takže co se změní nejvíc, je HAL vrstva kernelu a ovladače věcí přímo v procesoru. A s vzdáleností od jádra úsilí na portaci exponenciálně klesá. -
jm (neregistrovaný)
Krásná teorie, ovšem praxe říká něco jiného. Když je to tak jednoduché, proč tedy Microsoft pracně vyvíjel nové Windows na telefony a první Surface, když mohl prostě jenom portovat svoje x86 Windows prakticky s celým ekosystémem na Lumie a kompletně smazat všechny ostatní hráče na trhu s telefony? Vždyť přece stačilo jenom vybrat jinou cílovou platformu a zmáčknout F7.
-
Petr M (neregistrovaný)
Tak napřed si ze "všech aplikací, co běží na Windows" odpočítej
- aplikace v Javě, ty jedou na fitkivním SW stroji a stejný bytecode spustíš na jakékoliv platformě, náklady 0
- multiplatformní aplikace, kde je interakce se systémem skrytá v knihovnách ( Qt, ... )
- aplikace, který jedou nad skriptovacím nebo interpretovaným jazykem (na vedlejším monitoru mám zrovna něco v Tcl/Tk, ale i Python se počítá).No a pak uvidíš, že tahle "migrace" se už jednou povedla - z WinAPI na .NET. Pravda, ještě pár věcí jede nad WinAPI, ale už je to minorita.
A jeden přímo nesouvisející detail - problémy se side kanály jsou nejhorší na serverech (virtualizace pro několik zákazníků). Tam je těch aplikací podstatně míň, než BFU "nutně potřebuje". Systém, hypervizor, ssh daemon, SQL, PHP, web server, mail server a pár dalších. Pokud to nová architektura vezme přes servery a pak přeteče i do spotřebky...
-
jm (neregistrovaný)
První co mě napadne jsou drivery třetích stran které se budou muset překopat, na většinu driverů, které stále ve Windows fungují už ani není podpora ze strany výrobců, takže se spousta zařízení prostě vyhodí a když uvážíme kolik lidí křičelo když jim pod novým Windows 10 nefungoval skener nebo tiskárna, tak po kompletní migraci na jinou procesorovou platformu by to byla všeobecná hysterie na úrovni Francouzské revoluce.
Navíc jak krasně funguje portování mezi jednotlivými architekturami je možné vidět když se hra z PC portuje pro konzoli a naopak. Ty hry jsou na takovou akci většinou navržené a i přesto, pokud se hra pořádně neotestuje a neopraví se chyby vzniklé portací, výsledek je velice špatný. -
Durill (neregistrovaný)
On už tady jeden pokus byl, Intel IA64 pro servery a byly i k tomu příslušné OS a ze strany MS i další serverové aplikace. Bylo to drahé a celé nové. A pak přišlo AMD s "namontováním" 64bit architektury na 32bit procesor a instrukční sadu a trh rozhodl, že se půjde touto cestou, protože ta zpětná kompatibilita měla obrovskou hodnotu. (A CPU byly levnější.) Takže po této zkušenosti a slepé uličce se jen tak někomu do pokusu o migraci hlavní platformy chtít nebude.
-
j (neregistrovaný)
2Durill: Mno ono to hlavne taky bylo celkove vykonejsi a min zravy a ... pro IA neexistovaly naprosto zadny aplikace, a ti kteri je potencielne chteli napsat, zjistili, ze k tomu neexistuej ani zadna poradna dokumentace a ze na tom vlastne vubec nic nefunguje.
AMDcko udelalo proste to, ze stavajici instrukcni sadu jen rozsirilo na 64bit. Zadny zmeny funkcionality.
-
Petr M (neregistrovaný)
To nepochybňuju. Jde o to, že pokud řekněme za 1E9$ vyvinu komplet procesor i s technologií (litografie, leptání, zmenšování masek, ...) a se stavbou nové fabriky, můžu vyvinutý zařízení opakovaně použít a pro další čip už dám třeba 1E7$. A jak získám zkušenosti s vývojem v dané technologii, bude potřeba míň prototypových koleček, odladím výtěžnost a dostanu se ještě níž,...
-
petr@acrux.cz (neregistrovaný)
Nikdo to nezaplatí. Peníze, které by to stálo, resp. ktré by stály nové čipy oproti stávajícím, a to ještě s tím, že nebude zpětná kompatibilita a pravděpodobně by byl min. za začátku i výrazně nižší výkon (viz. ARM stahy v HPC).
Prostě se to bude lepit dále. ADost možná další desítky let, protože ta investice je nenávratná. Kde o to opravdy jde, jsou už dávno zavedená opatření - systémy jsou např. fyzicky izolované od internetu.... -
ml (neregistrovaný)
HT lze vypnout linuxu bez problémů, ovšem pro windows to není tak jednoduché. Pokud změníte některá nastavení, mezi která patří třeba i použití nebo nepoužití HT, systému windows, tak vám oznámí, že jste ho ukradli (respektive nic neoznámí, bude furt dokola restartovat), protože pro něj to je rázem jiný počítač, než na který byl aktivován.
-
Terorist (neregistrovaný)
Mám zkušenosti, že je možné vyměnit celý počítač (přehodit disk jinám) a reaktivace je možná (vyzkoušeno na Win XP a Win 7). Jenomže jiné Win 7 (OEM - klíč získám stejně jako u předchozích) po přehození disku odmítají naběhnout. Pořád se objevuje tabulka, že změny se projeví až po restartu...
Jinak když jsem vypnul HT, tak Windows si toho ani nevšiml.
-
Hyperthreading je rozbitý již 13 let (neregistrovaný)
Je smutné, že se 13 let od prvního útoku na hyperthreading stále nacházejí nové časové postranní kanály.
CVE-2005-0109
http://www.daemonology.net/hyperthreading-considered-harmful/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0109(jestli máte někdo odkaz na starší, tak ho sem prosím vložte)
-
mfrd (neregistrovaný)
To, že ty postranní kanály tam jsou a budou, je jasné z principu sdílení. Smutné je, že se tomu po 13 letech divíme.
Možná, pokud bychom si někde přečetly první dokumentaci k HT od Intelu, tak by jsme se dozvěděli pro co je to vhodné atp. (Tím netvrdím, že intel něco takového zveřejnil, ale je to dost možné).Za další každý CPU obsahuje tzv. nedokumentované instrukce, ty vznikají náhodně resp. jejich vytvoření nebylo v návrhu a zjistili se třeba až testováním čipu. Při změně technologie či uvedením nového čipu mohly vymizet nebo se chovat jinak.
Tedy principiálně vždy existuje možnost, že existuje cesta, která dokáže prolomit či zhroutit žádanou fci CPU.
Složitost CPU je již tak vysoká, že ani není možné reálně otestovat všechny možné stavy. Opravy nefunkčních částí se řeší např. nahráním mikrokódu do CPU. Viz https://downloadcenter.intel.com/download/28087/Linux-Processor-Microcode-Data-File
Četnost nových mikrokódů není nízká....
Pokud chcete vysokou bezpečnost, je potřeba návrh systému včetně všech HW a SW komponent takto designovat. -
Terorist (neregistrovaný)
HT mě přijde jako zbytečnost pro notebookové procesory. S prvními generacemi core mě nepřišlo, že by HT nějak výrazně pomohlo. Když jsem HT vypnul, tak notebook byl podobně rychlý a o větráčcích jsem pomalu nevěděl. Jasně v obchodě zní lépe čtyř jádro než dvou jádro. U stolního, kde je lepší chlazení, tam to smysl může mít. Případně ještě některé hry mají omezení na minimální počet jader, takže tam se ten HT taky hodí, když chce člověk ušetřit (i když myslím, že dříve byl HT v dražších CPU)
Jinak ti kteří si stěžují na architekturu x86, tak teď se již používá AMD64. Ale změnou architektury se nic nezmění. Pokud se najde vhodná bezpečná architektura, tak za pár let se tam stejně nějaký bug. Nepomůže ani RISC-V. V software jsou také bugy, které tam jsou desítky let, viz https://www.root.cz/clanky/dira-v-bashi-ktere-si-20-let-nikdo-nevsiml/ a to se bugy v hardware hledají hůř.
