Továbbfejleszti a Linux alatti CPU microcode frissítést az Intel

Intel

A CPU bugok korát éljük, így nem mindegy, hogy a vezető gyártók - Intel, AMD - milyen CPU javítási megoldásokat kínálnak. Az Intel mérnökei úgy gondolták, hogy van mit fejleszteni a Linux alatti CPU microcode frissítés módján, így az ezzel kapcsolatos munkák hamarosan bekerülnek a mainline Linux kernelbe. Részletek itt.

( trey | 2023. 08. 15., k – 12:07 )

Szerkesztve: 2023. 08. 15., k – 12:09

Ez is van már vagy 20 éves:

Microcode. WTF?

Lazán kapcsolódik:

Log started: 2023-08-14  10:05:30

[...]

Preparing to unpack .../3-intel-microcode_3.20230808.0ubuntu0.20.04.1_amd64.deb ...
Unpacking intel-microcode (3.20230808.0ubuntu0.20.04.1) over (3.20230214.0ubuntu0.20.04.1) ...
Setting up intel-microcode (3.20230808.0ubuntu0.20.04.1) ...
intel-microcode: microcode will be updated at next boot

  1. https://www.ubuntuupdates.org/package/core/focal/main/updates/intel-mic…
  2. https://downfall.page/
  3. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-40982

Kéne egy reboot ...

trey @ gépház

Úgy érted, a forráskódból, összenézve a CPU gyártók referenciáit nem derül ki, hogy hova tölti be? Ez esetben marad valóban a Gyakori kérdések.

Még mielőtt ... Én nem néztem meg a kódot, mert kibaszottul nem érdekel, hogy hova tölti be. Mindenesetre, ha engem érdekelne, ez lenne az első hely, ahonnan elindulnék. Egy microcode-ot betöltő, nyílt forráskódú operációs rendszer forráskód-tárolója.

trey @ gépház

Nem kell egymásnak ugrani, mint az óvodások. A kérdésem 19 éve pusztán csak annyi volt, hogy fizikailag, áramkörileg, "tranzisztorilag" hova kerül egy ilyen külső forrásból betöltött volatile "program"? A System RAM-ba biztosan nem. CPU SRAM-ba (másnéven "cache") biztosan nem. Az általános regiszterekben sem fér el. Akkor van egy csak erre fenntartott ucode SRAM terület a csipben valahol? (low level C/Assembly kódot nem értem, szóval azt olvasgatnom felesleges).

Azóta persze már kiderült, mielőtt aktív flém indulna el ;)

Valójában, én nem tudom mire vélni az ő felsőbbrendűségi nekem esésüket, nem látom, hogy mi az a nagy hülyeség, amit írtam.

Kíváncsian várom a választ. Nyilván én sem arra utaltam, hogy ott lesz egy fénykép a processzor belsejéről vagy chipterület megnevezés referenciaszámmal, hogy oda tölti be a microcode-ot :D :D :D

trey @ gépház

ROTFL

:D

Én a kódot sem néztem meg. Ugyanis nem érdekel. Azt mutattam meg, hogy ha érdekli a téma, akkor hol érdemes kezdenie. Ott. Kapálózhatsz, de hát ez van.

Ha pedig képek érdeklik, akkor Google képkereső, de azért ne a 486-ossal kezdje. :D

trey @ gépház

De a 486-on nem lehetett felülírni, úgyhogy e célból gondolom valamilyen EEPROM van az új procikban (mint a CPLD-ben).

Illetve...ha egyszer rátöltesz egy mikrokódot, az úgy marad? Mert az is lehet, hogy gyárilag ROM-ban van, patchelni meg SRAM-ba lehet.

Nem, nincs benne. Az EEPROM más más gyártástechnológia mint a CMOS, nem tudom mennyire házasítható (bár a Microchip megoldotta ~30 éve).

Mindenesetre az x86 vonalon a mikrokód volatile memóriában van, a proci minden indításnál az eredetivel indul, minden indulásnál az OS tölti be a frisset.

Régebben volt olyan proci próbálkozás, amikor plusz pénzért HT-t vagy nagyobb cachet beaktiválhattál. Gondolom azt megjegyezte. Lehet olyan megoldás, hogy valami egyszer írható jelzést "kiéget", amikor aktiválják. De az nem tárolásra való. A rom + ram lehet a megfejtés. A bios vagy az os tölthet be rá újabbat / patchet.

Most vagy követed a napi intel agyrákot, vagy csak ráéreztél, mert a kékek kitalálták nemrég a processzorban ugyanazt a módit, mint az autógyártók közül a Tesla: benne lesz minden extra fícsör tranzisztorszinten a processzorban a gyárból kigurulva. De! Aktiváló licenszhez kötik majd a használatát. Illetve lesz havi előfizetési díjas konstrukció is. Ha valamelyik hónapban elmarad a számla kifizetése, majd nem lesz floating pont matek a processzorban :-/

e-fuse meg már sok éve van használva a processzorokban. Elmúltak azok az idők, amikor összegrafitoztál 2 lábat, és volt +1 core vagy +fél mega L2 cache! Most átégeti a lézer az egyik vezetéket, vagy első programozáskor maga a processzor, és onnantól az életben nem csinálsz belőle más SKU-t, mint amilyennek az intel szánta a végén.

minden indulásnál az OS tölti be a frisset.

Mármint valaki betölti a frisset. FreeBSD-n pl. rá lehet bízni az OS-re, de maga a boot-loader is csont nélkül meg tudja csinálni, még a kernel betöltése előtt. (Ment is mostanában a lamenta, hogy melyik a preferált / jobb megoldás, és abban maradtak, hogy kapcsolt be a mind akétfélét, ha nagyon perverz akarsz lenni, nem fáj.)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

A CPU-nak van jó pár regisztere ezzelé kapcsolatban, és ilyenkor egy belső memóriába kerül a CPU-n belül. Kb. mintha egy EEPROM lenne.

https://www.intel.com/content/www/us/en/developer/articles/technical/in…

A 3A kötet 10.11.1-es fejezete foglalkozik azzal, hogy kell a CPU-n mikrokód frissítést csinálni. A lényeg, hogy írni kell efgy gépspecifikus regisztert meg még pár általános célút a megfelelő adatokkal, éppen a 0x79-et, ez a IA32_BIOS_UPDT_TRIG regiszter. 

Minden indításkor frissíteni kell, mert ez két CPU boot között elveszik.

"Célszerű modulba fordítani, mert a microcode feltöltése után a modul eltávolítható (rmmod microcode), és így nem foglal feleslegesen memóriát."

Ez a mondat elég furcsán hangzik a flatpak/snap/appimage korában, meg amikor GB-okat rábízunk a garbage collectorra, vagy még arra se. De akkoriban képesek voltunk valóban azon a pár 10kB-on spórolni :)

Nekem nem hitted el múltkor, hogy azért néha újra kell bootolni. Jöttél nekem, hogy nem mert az Ubuntu az tud live kernelpatcht, stb..

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nem emlékszem már melyik szálban volt, de valami uptime-mal kapcsolatosban. Jó, talán azt nem írtad, hogy sose, de hogy nem szoktál újrabootolni.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Megjött, reboot is volt azonnal. Eleve nekem minden nap cold boot van, és nap végén elzárom a gépet, nem hibernáció, nem sleep, hanem komplett shutdown. Ezek között sokszor van, hogy ha valami olyan update jön, új kernel, systemd, firmware, microcode, pipewire, stb., ezek Arch-on, főleg a Testing tárolóknál szinte mindennaposak, akkor külön is rebootolok. Nálam úgyis gyors a boot, alig néhány mp. alatt minden betölt, feláll, nem nagy időveszteség.

Néha még olyan miatt is átbootolok, ha mondjuk Windowson a dedikált Nvidia kártyával játszok valamivel, bár az most nem történt meg 1+ hónapja, alig van időm, mikor mégis egy kicsi, akkor Linuxon tolom a Far Cry 1-et, az egy olyan régi játék, hogy még a prociba integrált 680M-en is ilyen 180-370 fps-sekkel futkorászik kimaxolt FullHD-ben.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nekem megfelel a mai napig. Ha akarnám, a jelenlegi WM-jeimmel menthetnék munkamenetet is, scriptek formájában, vagy tmux-ban, de erre sincs szükségem. Pont ez a lényege, hogy friss lappal indulok minden nap, és nem a több hete futó, beragadt, stb. szutykokat görgetem magam előtt. Időben sem vesztek semmit, mert minden olyan ultragyorsan, villámpattogósan indul, hogy nem áldozat rá várni.

Ez a sleep meg hibernáció a régi desktop OS-eken és a HDD korszakban volt fontos, mikor adott esetben a cold bootnál lefőtt egy kávé, mire rotyogó/kávédaráló HDD-ről betöltött a rendszer, meg betöltötte valaki a komplex IDE-it, projektjeit, és ezt a kínt el akarta kerülni, ha csak egy mód volt rá. A mai SSD-s, meg minimál Linuxok korszakában ezek már nem játszanak, olyan villámgyors lett a hardver, főleg az SSD-k dobtak rajta sokat, de a sok procimag, sok giga RAM is segített azért.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nincs bajom a nosztalgiával, magam is szoktam nosztalgikus állapotba kerülni. Most gondolj bele, hogy nekiállok egy hosszabb HUP cikket írni (jó, de tegyük fel) egy kávézóban, de aztán a felénél úgy döntök hogy mennem kell ... akkor a felénél mentesem ki a szöveget, zárjak be minden ablakot, állítsam le a gépet, majd otthon bootoljak, indítsak el minden ablakot, lépjek be, másoljam vissza a félbehagyott szöveget. Vaaaaagy .... a kávézóban nyomjak egy suspend-et a félbehagyott szöveggel ...

<fél óra elteltével, resume után>

                                                          .... azonnal ott folytassam, ahol abbahagytam?

trey @ gépház

hat lehet hogy a hup nem, de a sok portal szepen logoutoltat annyi ido alatt, es irhatod be ujra egy kave mellett a szoveget. ugyh igyis-ugyis erdemes kirakni egy notepad-ba, a chome meg ugyis visszaallitja a tabokat.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Majd mindjárt elmondják, hogy az évtizedek alatt kényelmesre és hatékonyra csiszolódott workflowdat hogyan is kéne csinálnod... 

Nem kurvára tök mindegy? Ha neked így jó és ezt szoktad meg, kit érdekel, hogy talán ugyanazt máshogy is meg lehetne csinálni? De utálom ezt a kényszeres térítést állandóan...

van aki nem csak a hupra irogat,...

Akkor nyilván más a workflow, na bumm. Én meg google docs-ba szoktam a nagyobb lélegzetvételű, de nem privát szarjaimat írni, így elérem máshol is más gépről. Nem gondolom, hogy ez az ultimate workflow, de nekem ilyen esetekben ez vált be. Kb. ennyit érdemel a téma.

Csak. Nekem négy van, amit rendszeresen használok HUP-olvasásra. Utazás közben telefont, otthon asztalnál az asztali gépet, ügyféles munka szünetében a laptopomat, este ágyban meg a tabletemet.
 

És ez szerintem nem is kirívóan sok eszköz. És akkor ne is beszéljünk arról, hogy mindenféle okok miatt egy eszközön is használhatok több böngészőt egyszerre.