Vlákno názorů ke zprávičce GCC 8 přidalo záplaty proti Spectre od mhi - Prijde mi to uz silene jake konstrukty se...
-
mhi (neregistrovaný)
Pokud zamenime emulator za translator a presune se to tak, ze OS bude propojeny s tim translatorem (nejaka zakladni vrstva uzce spolupracujici s HW CPU/MMU/etc), tak to mozna nejak realizovatelne bude. Bez translace se zahodi vsechny ty chytre funkce CPU typu speculative execution :-).
U translatoru by se docela snadno dal resit problem vytahovani nepristupnych dat pres side channel tak, ze u mov rax,pole[rbx] by se v pripade ze nevime hodnotu rbx prelozilo jako:
and rbx,(1<<62)-1
mov rax,pole[rbx]a kernelu by potom stacilo hodit userland-nepristupne veci do stranek s adresou 1<<63
Nema smysl emulovat treba cele TLB x86 na jine architekture, to bude mit zasadni vliv na vykon.
-
Nema smysl emulovat treba cele TLB x86 na jine architekture, to bude mit zasadni vliv na vykon.
Tak ono cele x86/64 uz je nejaky ten patek emulovane. Intel je pry dneska nejaky RISC, ktery dela tu emulaci. Takovy pocitac v pocitaci + dalsi pocitac v pocitaci, na kterem jim bezi ten Minix. Bylo by zajimave vedet, jak rychle by to bylo rovnou na tom RISC, bez te emulace.
-
mhi (neregistrovaný)
Ackoliv o strevech intelich x86_64 toho az zase tak moc nevim, dovoluji si tvrdit, ze to RISC rozhodne neni, dokonce se ani nic "neemuluje" a rychlosti se dosahuje prave tim, ze vetsina nejbeznejsich instrukci bezi primo na kremiku, bez ucasti mikrokodu. Ostatne jinak by docela snadno sel problem Meltd/Spectre vyresit.
To co pisete byla transmeta, tam byla v SW translacni vrstva a plnohodnotny VLIW.
-
j (neregistrovaný)
"dovoluji si tvrdit, ze to RISC rozhodne neni"
Coz bude tim, ze o tom naprosto nic nevis ....
Zadnej HW x86 tu uz par (desitek) let neexistuje. Vse to je emulace na RISCovy architekture, ktera tomu prinasi mnohem vic, nez kolik se ztraci na ty emulaci. Pri klasicky koncepci bys navic musel kazdou jednu instrukci zadratovat do HW, coz by pri vsech rozsirenich x86 vedlo na gigantickej kremik.
To neznamena, ze zadna cast instrukcniho bloku neni "HW", ale bezna instrukcni sada vlastni obvody nema.
-
mhi (neregistrovaný)
Porad si stojim za svym :-). To ze se vnitrne v procesoru nageneruji mikrooperace (ktere uz mohou byt RISCove) je dalsi vec.
Hranice podle me je, zda v tom "RISC"u lze implementovat vse z dane ISA, pak bych mluvil o tom, ze interne to je RISC.
Takhle by se dalo rict, ze nejaky mini-CISC delany s 74XX logikou s 74LS ALU (nevim ted' presne oznaceni toho obvodu) je RISC.
-
Porad si stojim za svym :-)
http://sunnyeves.blogspot.be/2009/07/intel-x86-processors-cisc-or-risc-or.html
-
mhi (neregistrovaný)
I po precteni cisc-or-risc-or si stojim za svym. Popravde receno se mi nechce detailne oduvodnovat. Asi nejlepsi byla nejaka prezentace cloveka z Intelu, ktery popisoval jak vnitrne funguji nektere veci a to co popisoval rozhodne nebyl RISC.
I bez insider informaci - nekde jsou seznamy poctu micro-operaci pro jednotlive formaty instrukci a z toho mi vychazelo, ze RISCove to prilis neni.
-
I bez insider informaci - nekde jsou seznamy poctu micro-operaci pro jednotlive formaty instrukci a z toho mi vychazelo, ze RISCove to prilis neni.
Nevim, jestli spravne pochopuju sdeleni vaseho prispevku, ale mate-li na mysli, ze jedna CISC instrukce se prelozi az na cele hafo internich RISC instrukci, tak to mi nepripada nijak prekvapive, naopak je to presne to, co bych ocekaval a opak by me prekvapil.
-
mhi (neregistrovaný)
Prekvapive jsou ty, kde je tech upou prave malo, pripadne i takove, kde neni zadny nebo jen 1 uop a pritom to je pomerne slozita instrukce. Nelze toto meritko brat ale doslova, zrejme nikdo krome Intelu/AMD nezna presne detaily.
Abych to uzavrel, neumim udelat dukaz ve smyslu abych ukazal ktera konkretni cast Core mikroarch uvnitr nesplnuje intuitivni definici RISCu, zejmena protoze nemam dokumentaci ke strevum Core nebo predchozich architektur.
-
Sten (neregistrovaný)
Interně tam RISC je a všechny instrukce jdou přes translátor. (Intel v tom není sám, translátor mají i všechny nové ARMy, tam se dokonce překládá RISC do jiného RISC.)
Jak byste snadno řešil Spectre mikrokódem? Meltdown se Intel snaží alespoň částečně mikrokódem řešit, ale není to „snadno“ a stojí to hodně výkonu. On ten mikrokód má hodně omezené prostředky (je to přeci jen RISC) a s tímhle se zřejmě při návrhu té sady nepočítalo.
-
Ano, staci. Jako dalsi vrstva zabezpeceni by pak na tom jslinuxu sel spustit browser a v nem jslinux, kteryzto proces by bylo mozno opakovat podle pozadovaneho stupne zabezpeceni. Ale obavam se, ze propad vykonu by byl jeste vyraznejsi, nez ten, ktery je nasledkem oprav Intelu a zaplat v jadre. Navic by tento propad vykonu byl zhorsen propadem vykonu zpusobenym opravami Intelu a zaplatami v jadre. A netroufam si tvrdit, jak by dopadl propad vykonu v pripade, ze by na jslinuxu bezelo jadro zaplatvane proti Meltdown a Spectre.
-
MartinX (neregistrovaný)
Ta JavaScriptova simulacia x86 asi nebude mat implementovanu cache a spekulativne vykonavanie, teda patch na Spectre a Meltdown netreba.
Ale aj tak obdivujem autora, na to kolko vrstiev tam funguje (fyzicky HW, OS, Browser, JS Engine, simulacia HW, dalsi OS ) to na Ryzen 1700 a 16 GB RAM nabootuje v Chrome do grafickeho rozhrania Linuxu za asi 1 minutu a do Windows 2000 za asi 3 minuty.
ČLÁNKY DO MAILU