Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: Ħαℓ₸℮ℵ ␏⫢ ⦚ 12. 12. 2023, 15:09:18
-
Je nějak možné zachránit data z počítače (Windows, 10 Intel 64bit, DDR4), který náhle majestátně zamrzl? Prostě se přestal hýbat kurzor a obraz je stále stejný i po odpojení / připojení (více) monitorů na jiné výstupy. Pochopitelně jen tam tom původním výstupu.
Před dnem ještě sporadicky komunikoval po síti po připojení/zapojení kabelu (sporadicky= že třeba vyslal SYN packety na nějaké internetové adresy, něco v lokální)
Po včerejšku ale už neudrží, myš, moč, ani IP adresu. (To myslím, že je příčina odpojení sítového kabelu na delší dobu, kdy si není jistý přidělenou IP) a komunikuje jen z 169.254. adresy, kromě arp dotazů na obsazenost 169.254.x.y se ptá i na bývalou adresu brány... Komunikace z opačného konce (s vsříknutím i neigh add ) je bez odezvy
Po odpojení myši a klávesnici už se obojí o opětovném přípojení tváří, že do toho nejde proud ani.
Nezajímá mě ani tak příčina(mám pocit, že nějaká služba udělal obrovský memory leak na už tak zaplněné kombinobané přeplněné operační paměti rozšířené ještě odkládacím souborem), ale jak to řešit, jesli existují nějaké možnosti , jak se dostat k obsahu paměti, a a zachránit otevřené programy s otevřenými daty.
Momentálně osobně netuším, na co by PC zareagoval,. Už den je na něm zamrzlý obraz.
+ Jestli to jde (na windows) nějak řeši do budoucna. Se na to připravit, třeba něco jako telnet do windows, do kterého by se i v této situaci šlo připojita killnout dwm. exe. NEbo nějak se připojit přes sériový port nebo nějak vykonat třeba příkaz pro restart dwm.exe nebo restart grafického driveru.
-
Teoreticky jde ochladit paměti, rychle je přendat do jiného počítače a tam je přečíst. Ten druhý počítač by neměl paměti mazat. Akorát nevím, proč by se to dělalo, kromě odhalení šifrovacího klíče v paměti,
https://en.wikipedia.org/wiki/Cold_boot_attack
-
Toto bude u Windows takmer nemožné, ale môžeš vyskúšať radu od kolegu, čo písal predo mnou. I tak bude dosť otázka čo prežilo. Je totiž aj rozdiel či zamrzol len front-end a IO, alebo aj niečo na nižšej úrovni v systéme, alebo či systém už nezabil tasky a nedealokoval pamäť, ktorá dáta obsahovala, prípadne či tieto dáta uložila do temp súborov alebo niekam inam na disk. Možností je mnoho, a vážne záleží od situácie... u Windows je to ale rozhodne problematickejšie než u Linuxu z viacerých dôvodov... Windows je totiž monolitický a implementácia uzavretá. Sám by som to už vzdal, lebo neviem či hodnota tých dát je taká vysoká, že by to stálo za ten čas to skúšať obnoviť s neistým výsledkom.
-
+ Jestli to jde (na windows) nějak řeši do budoucna.
Ano. nenechavat spustene programy s neulozenymi udajmi, ale pravidelne priebezne ukladat. Ine bezpecne riesenie neexistuje. V linuxe by bola este aka-taka nadej, lebo tam ked zamrzne grafika, tak sa da dostat do terminalu.
Ale kedze spominas, ze ani mys/klavesnica nereaguje - ked tam pichnes nejaky usb ventilator toci sa? na overenie, ci je mrtva doska, alebo len system. Lebo su situacie, ked oddide nejaky hw komponent a windows na to zareaguje tak, ze komplet zamrzne.
-
Prý je možné všechno. Ale chtělo by to spešl HW na vyčtení dat z RAM, nebo počítač s hodně speciálně upraveným BIOSem. Taky ne všechna data jsou v RAM, něco se toulá v různých cache mezi komponentami.
No a to co bude v RAM, nemusí být moc pěkné ke koukání ani ke skládání něčeho většího, co by dávalo smysl.
Každopádně by to byl pěkný "výlet" do světa "za zrcadlem".
Před skoro 1/4 stoletím jsem takhle skládal 8MB souboru, databáze účetnictví z 2GB disku, který zemřel s Win Millenium Edition. Něco bylo na disku za sebou, ale ne všechno, takže to bylo skládání puzzle. Trvalo mi to 3 dny, ale podařilo se.
-
NE, NE A POTŘETÍ NE
Moc se koukáš na filmy.
Myslím si, že ti chybí přirozená sebereflexe která by tě nutila aby sis ty informace sám od sebe dohledal.
https://cs.wikipedia.org/wiki/RAM
https://cs.wikipedia.org/wiki/Opera%C4%8Dn%C3%AD_pam%C4%9B%C5%A5
-
Vsechno se da, ale pochybuji ze na takovy ukon mas rozpocet nebo vybaveni a znalosti, takze odpoved zni: vyfot si obrazovku mobilem a zmackni reset :)
-
Jak již bylo řečeno, smůla. Reálně nemáš šanci se k těm datům dostat. Existují nějaké teorie, nějaké laboratorní testy apod., ale nemáš hw, nemáš znalosti a není to laboratorní test.
Ten, kdo si pravidelně neukládá práci a nezálohuje, toho pak většinou nic nezachrání.
Zdar Max
-
Hm, vzpomínám, jak jsem lovil rozepsaný dlouhý mail z obrazu RAM, když mi před lety spadnul KMail. Tohle je ale fakt de facto mission impossible. Pro příště fakt ukládej a ideálně používej programy, které to umí automaticky. A verzuj.
-
NE, NE A POTŘETÍ NE
Ano, přesně tak. Pokud operační systém "tvz. zamrzne" neexistuje žádné software řešení jak data z RAM získat. Možná pokud by si člověk naprogramoval vlastní BIOS(UEFI) s nějakým vlastním commandem(shellem) a náhodou by zamrzl OS a BIOS by fungoval tak by to možná šlo, myslím tím udělat bitovou kopii RAM a hodit třeba na flasku. Ale pochybuji, že v ČR má někdo takové znalosti má aby to dokázal.
-
NE, NE A POTŘETÍ NE
Ano, přesně tak. Pokud operační systém "tvz. zamrzne" neexistuje žádné software řešení jak data z RAM získat. Možná pokud by si člověk naprogramoval vlastní BIOS(UEFI) s nějakým vlastním commandem(shellem) a náhodou by zamrzl OS a BIOS by fungoval tak by to možná šlo, myslím tím udělat bitovou kopii RAM a hodit třeba na flasku. Ale pochybuji, že v ČR má někdo takové znalosti má aby to dokázal.
Co brání RAM po rebootu přečíst (předpokládám, že HW neumřel), pokud se člověk smíří se ztrátou (malé) části, kterou bude potřebovat program provádějící dump pro svůj běh? Tj. chce to nějaký minimalistický image/bootloader, jako například zde (https://rmprepusb.com/tutorials/124-cold-boot-attack-dump-a-computers-memory-to-a-usb-drive/). Interpretovat obsah dumpu a najít hledaná data bych viděl jako větší problém ...
Nebo mi něco uniká?
-
Většina toho, co mě napadlo, již byla řečena, dodám jen:
* Nějaká data můžou být i ve swapu. Záleží ale, co přesně se stalo, a jak často bylo k těm zajímavým datům (+datům v okolí) přistupováno.
* Dost je otázka, co hledáte. Některé věci bývají v RAM jako souvislý blok dat (ideálně malý, ať nemusíme řešit fragmentaci), a šlo by je najít relativně snadno. Ale obecně se snažit interpretovat obsah RAM (i kdyby byl kompletní), zvlášť že zamrznutého systému (může být různě poškozený) a zvlášť u closed-source (potřeba reverzního inženýrství) může jít o docela náročný úkol. Ať už to budete dělat sám, nebo si na to někoho najmete, asi se to nevyplatí kvůli jednomu dni ztracené práce, pokud nemáte nějaký jednoduchý způsob specifický pro konkrétní data.
* Případná ECC (nebývá běžná u úplně obyčejných kancelářských strojů) může na jednu stranu pomoci (větší šance u cold bootu, aspoň teoreticky – nevím, jak je to prakticky významné u dnešních RAM), na druhou stranu tam BIOS typicky přemaže obsah RAMz aby zabránil falešným chybám při čtení neinicializované RAM. (Možná se to nebude dít u specifických platforem – např. Zen 3 patrně koriguje chyby potichu, takže tam se na to výrobce teoreticky může vykašlat, prakticky nevím a může to být výrobce od výrobce.)
* Bylo již řečeno, ale stojí za zopakování: Do budoucna bych doporučil držet v RAM jen tolik neuložených dát, kolik si můžete čas od času dovolit ztratit. A totéž do nějaké míry platí i pro data na jakémkoli jiném médiu – ztráta se občas stane, je potřeba s tím počítat a zálohovat.
-
Bývaly časy, kdy nebylo zase tak neobvyklé, že bylo potřeba se pohrabat v systému který "zamrznul".
Pozůstatek těch časů máme na většině klávesnic pod klávesou PrintScreen, funkce SysRq.
https://cs.wikipedia.org/wiki/Kl%C3%A1vesa_Sys_Rq
Kdysi, ještě počítačovém v pravěku, jsem se dozvěděl, že v jedné střední škole v Plzni mají učebnu s 10 PC XT, ale že je zavřená a nikdo tam nechodí.
Tak jsem se tam dostal a zkoušel to tam dát do kupy. Většina těch počítačů měla podivné chyby, zamrzávaly, objevovaly se chyby na disku a další záhady. Pro odchovance socialistickými sčoty, to nebylo tak neobvyklé, ale protože jsem měl zkušenost s jinými XTčky, které fungovaly dobře, tak jsem to nenechal být. Z tlusté knížky o HW, půjčené ze státní vědecké knihovny (na kterou jsem se štěstím čekal jen 1/2roku), jsem vyčetl, že by za to mohly vadné RAM moduly. Tehdá to ještě nebyly karty, ale švábíci nasázení do patic na základovce. Pomocí walkmena se dalo zjistit, který modul je funkční a který vadný. Stačilo naladit správnou frekvenci na rádiu, s anténou jezdit nad chipy. Ty, které byly funkční vydávaly pěkný zvuk, ty které byly vadné vydávaly nepěkné šumoruchy. Pak bylo potřeba ty vadné vydolovat z patic a dát tam funkční z jiného počítače. Po téhle proceduře zbyly dva nefunkční, zkanibalizované, počítače a 8 perfektně šlapajících mašinek.
-
Co brání RAM po rebootu přečíst (předpokládám, že HW neumřel), pokud se člověk smíří se ztrátou (malé) části, kterou bude potřebovat program provádějící dump pro svůj běh? Tj. chce to nějaký minimalistický image/bootloader, jako například zde (https://rmprepusb.com/tutorials/124-cold-boot-attack-dump-a-computers-memory-to-a-usb-drive/). Interpretovat obsah dumpu a najít hledaná data bych viděl jako větší problém ...
Nebo mi něco uniká?
Pokud si dobře pamatuji při rebootu z RAM zmizí elektrické napětí, opětovně se objeví a to pamětové buňky " tvz. smaže". Ty biti(příp. bajty) tam nezůstanou, což je dobře. Proto Fikar mluvil o ochlazení(fyzikálního procesu) aby i po odpojení elektrického zdroje tam nějaké napětí zůstalo(zpomalí se entropie). Toto je naprosto mimo mé pole působnosti a tyto znalosti přenechávám kompetentnějším.
-
Opakuju, že neznám nejnovější detaily ohledně současných RAM (byť teda DDR4 není horká novinka), nicméně co si pamatuju, tak obě varianty (reset + boot z flashky a ochlazení tekutým dusíkem + boot na jiném stroji) měly svoje místo:
a. Pokud nebyl problém bootovat jiný systém z flashky a zároveň nešlo o ECC, nějaká varianta resetu fungovala dobře. Nedám ruku do ohně, jestli dojde k odpojení napájení RAM, ale skoro bych se vsadil, že ani ne.
b. V komplikovanějších případech (ECC nebo BIOS password + secure boot / zákaz bootu z flashky) ta jednodušší varianta nefungovala, takže nezbylo než ochladit RAM (ideálně kapalným dusíkem, ale IIRC stačily i nějaké celkem obyčejné spreje*) a hodit jiného jiného počítače, který je na situaci připraven.
Tuším, že u DDR4 je ten proces v praxi o něco komplikovanější než u DDR3.
*) On i „stlačený vzduch“ (typicky to bývá snad metan) mi při otočení láhve plival kapalný plyn, který následně mrznul.
-
Btw jako nejjenodussi pristup je pridat do kompu:
- PCI/PCIe kartu s DMA pristupem (umeli to stare FireWire karty, ktere meli explicitni podporu ve win debuggeru)
- pripadne pouzit modernejsi nahrazku - PCILeech, DMA Warrior, LeetDMA, atd
Vsechno tohle ale vyzaduje:
- vypnuti IOMMU v biosu a v OS
- pristupovat jen na adresy kde fyzicka pamet je, jinak se muze stat ze se komp rovnou resetne
-
+ Jestli to jde (na windows) nějak řeši do budoucna. Se na to připravit, třeba něco jako telnet do windows, do kterého by se i v této situaci šlo připojita killnout dwm. exe. NEbo nějak se připojit přes sériový port nebo nějak vykonat třeba příkaz pro restart dwm.exe nebo restart grafického driveru.
Tento Win umí restart dwm nebo ovladače. Obávám se, že právě z důvodu opakovaného selhání je v tomto stavu.
-
Pokud si dobře pamatuji při rebootu z RAM zmizí elektrické napětí, opětovně se objeví a to pamětové buňky " tvz. smaže". Ty biti(příp. bajty) tam nezůstanou, což je dobře.
Nějaký relevantní zdroj k takovému tvrzení? Též bych si vsadil na variantu, že k tomu nedojde.
* Případná ECC (nebývá běžná u úplně obyčejných kancelářských strojů) může na jednu stranu pomoci (větší šance u cold bootu, aspoň teoreticky – nevím, jak je to prakticky významné u dnešních RAM), na druhou stranu tam BIOS typicky přemaže obsah RAMz aby zabránil falešným chybám při čtení neinicializované RAM.
Dobrá připomínka. Že v případě ECC může paměť mazat BIOS mě nenapadlo.
BTW debugoval jsem custom zařízení s FPGA/DDR2, kde byl právě problém s DDR2 a překvapilo mě, jak dlouho data v paměti drží při vypnutém napájení. Očekával jsem, že po pár sekundách tam nebude nic, ale i po několika minutách tam byly rozpoznatelné zbytky původních dat. Spolu s ECC a chybou v řadiči to způsobovalo takové náhodné chování, které mě dost mátlo. Právě při krátkých vypnutích se to tvářilo celkem bezproblémově a po dlouhém odležení nastaly potíže, když už to ECC nedokázala opravit. Takže především ráno a po obědě to nechtělo naběhnout :-)
-
Ħαℓ₸℮ℵ ␏⫢ ⦚
Moznost A) Ak ten pocitac este bezi, skuste napisat do NSA, CIA, a ostatnych troj (a štvor) pismenkovych agentur a za par tisic eur isto rad prileti typek s vybavou - tekutym dusikom a masinou upravenou na cold boot attack. Ten typek vam vytiahne data co este zostali vo vasich ramkach do svojich, tie ulozi na disk, a ten disk s tou kopu neusporiadanych smeti vam potom da. Nasledne mozte travit niekolko mesiacov az desatroci skladanim dat do niecoho co bude davat zmysel.
Moznost B) Prestat sa divat na rozne CSI kriminalky, skodi vam to.
-
Něco z těch "kriminálek" je nesmysl, spousta věcí nesmysl není, ale bývá to bývá podáno "uměleckou zkratkou"
V realitě je toho možného dokonce mnohem víc, než ukazují ve filmech/seriálech a je to o znalostech a vybavení.
V domácích podmínkách by minimálně stál za pokus rychlý hw restart (pokud na to nemáte tlačítko, tak by mohly být piny na základovce), nabootování do nějakého minimalistického Linuxu a odtud dump paměti někam na externí disk.
Pokazit by to mohl BIOS, kdyby dělal kontrolu a vynulování RAM. Novější počítače už to, hádám, nedělají, ale volba typu "Fast Boot" a podobné by tomu měly napomoci.
Pro Linux bych hledal něco ke čtení z /dev/mem
Pro Widle je nějaký návod zde:
https://knowledge.broadcom.com/external/article/179911/create-a-full-memory-dump.html
-
Díky za všechny odpovědi je to dost rozmanité a já spíš myslel něco "in-band" a bez externího hardwaru ,ale asi bych nic nenašel.
Ten hajzl celou dobu běžel, zapisoval do protokolu událostí, jen jsou umazané asi kvůli počtu záznamů, je jich tam posledních 60 tisíc
(když dám filtr "-140", tak jich to podobných 59800 skryje, každou sekundu něco o protokolu transakcí, ale to už registroval jsem předtím, asi se nějak zbláznil driver virtuálního disku v RAM i když nebyl ani jeden disk v RAM vytvořen).Nezahrnuje bohužel už okamžik crashe, ale den poté. A zahrunuje den před vypnutím.
Takže nic zajímavého jsem tam nenašel, zřejmě se během těch dvou dnů slepoty nic zajímavého nedělo (kromě odpojování ethernetu a monitoru).
Jo, je tam že předchozí vypnutí systému bylo neočekávané a asi 30x něco ve smyslu, že driver síťové karty požádl o restartování síťovky po 73, po 74 ...
Je tam jedna zajímavá událost ne z Záložky Systém, ale aplikace, tak ji sem postnu. upoutalo mě to hodně kostrbatým překladem.
-
...
vědecké knihovny (na kterou jsem se štěstím čekal jen 1/2roku), jsem vyčetl, že by za to mohly vadné RAM moduly. Tehdá ...
zvuk, ty které byly vadné vydávaly nepěkné šumoruchy. Pak bylo potřeba ty vadné vydolovat z patic a dát tam funkční z jiného počítače. Po téhle proceduře zbyly dva nefunkční, zkanibalizované, počítače a 8 perfektně šlapajících mašinek.
Jo, tohle nám PCčka ze svrchní křídy ve škole dělala taky, úplně stačilo DIPové brouky zamáčknout na jednom konci, pak na druhém, čímž se částečně povytáhly, a zmáčknutím uprostřed zatlačit zpátky. Docházelo totiž k elektrochemické oxidaci na styku nohou s kontakty patice. Pak to zase měsíc až dva chodilo. Jak to začlo zlobit, rinse & repeat.
-
Pokud si dobře pamatuji při rebootu z RAM zmizí elektrické napětí, opětovně se objeví a to pamětové buňky " tvz. smaže". Ty biti(příp. bajty) tam nezůstanou, což je dobře.
Nějaký relevantní zdroj k takovému tvrzení? Též bych si vsadil na variantu, že k tomu nedojde.
Ztráta napětí právě data nesmaže. A vydrží tam tím dýl, čím je nižší teplota. DRAM jsou v podstatě kondenzátory a normálně za běhu se musí čas od času přečíst a znovu zapsat.
https://en.wikipedia.org/wiki/Memory_refresh
Takže když paměti ochladíte, opojíte a do pár sekund zase uděláte refresh, tak tam nějaká data zbudou.
https://www.pdl.cmu.edu/PDL-FTP/NVM/dram-retention_isca13.pdf
-
Ten experiemnt probíhal s DDR3. IIRC, novější DDR4 se typicky po ztrátě napětí mažou výrazně rychleji než DDR3.
Pokud ale něco při resetu RAM vymaže, bude to spíš BIOS (zmíněná kontrola RAM nebo vynulování ECC RAM) než vypnuté napájení, které by vyžadovalo další elektroniku, bylo by do nějaké míry zbytečné a jehož dopad (zvlášť na tak krátkou dobu) je přinejmenším s otazníkem.
-
...
No já si to pamatuji trochu jinak. Tu informaci mě vysvětlovali na nějaké kurzu na konci 90tek. To tehdy byli ještě SDRAM (nebo jak se to tehdy jmenovalo)a je možné že u nich to fungovalo jinak. Bez ohledu na to jak to v těch pamětích funguje se všichni shodneme, že neexistuje jednoduché("domácí") řešení jak z pamětí získat data v případě zamrznutí softwaru (OS či Biosu/uefi) či hw(procesoru, či jiných). Navíc se jedná ještě binární data které si "náhodně" v paměti umísťuje OS a i kdyby se dali získat je velmi obtížné a velmi pracné z nich nějaké informace vyčíst.
-
Btw na modernich procesorech jsou data scramblovana, jakozto ochrana predtim, kdyz vam "nekdo" vynda celou dimm a bude se ji snazit precist. Takze smolik tak jako tak. Imho kazdy boot bude generovat novy nahodny klic.
https://en.wikipedia.org/wiki/Memory_controller#SCRAMBLING
https://security.stackexchange.com/questions/251715/disable-memory-scrambling
https://www.amd.com/system/files/documents/amd-memory-guard-white-paper.pdf
-
Že zběžného projití odkazů jsem pochopil:
a. Memory scrambling tu není primárně pro bezpečnost a lze obejít. Navíc pro malé bloky dat nemusí být žádnou překážkou.
b. AMD memory guard je něco jiného, sami v dokumentu píší, že scrambling nestačí. A tuším, že to podporují jen některé procesory, navíc to nemusí být vždy zapnuté.
-
...
No já si to pamatuji trochu jinak. Tu informaci mě vysvětlovali na nějaké kurzu na konci 90tek. To tehdy byli ještě SDRAM (nebo jak se to tehdy jmenovalo)a je možné že u nich to fungovalo jinak. Bez ohledu na to jak to v těch pamětích funguje se všichni shodneme, že neexistuje jednoduché("domácí") řešení jak z pamětí získat data v případě zamrznutí softwaru (OS či Biosu/uefi) či hw(procesoru, či jiných). Navíc se jedná ještě binární data které si "náhodně" v paměti umísťuje OS a i kdyby se dali získat je velmi obtížné a velmi pracné z nich nějaké informace vyčíst.
No to myslíte SRAM, tam není potřeba refresh a po odpojení a připojení napájení se to většinou samo vnitřně resetuje.
https://en.wikipedia.org/wiki/Random-access_memory#Memory_cell
-
Pokud operační systém "tvz. zamrzne" neexistuje žádné software řešení jak data z RAM získat.
Existuje a celkem běžně se i používá, příkladem je linuxový kdump. Má to ale dva háčky: za prvé je potřeba ho mít nakonfigurovaný a připravený předem, za druhé nevím, jestli je něco podobného běžně dostupné i pro Windows, které používá tazatel.
-
Velmi matně si pamatuju, že v dávných dobách snad existovaly "ladící" karty do PCI, které pomocí bus masteringu dokázaly sáhnout kamkoli do hostitelovy DRAM, tzn. také udělat kompletní obraz RAM zaseklého počítače, pokud byl do té míry funkční.
Nejsem si jistý, zda přístup z PCI do adresního prostoru hostitelova procesoru (resp. fyzické DRAM) podléhá nějakým omezením, a jakým. Vím že PCI host bridge (a další bridge za ním) filtrují/dekódují přístup z hostitele do MMIO oken periferií - ale opačným způsobem... nevím. Je možné, že se toto v průběhu desítek let vývoje PCI nějak vyvíjelo, předpokládal bych směrem k utužení bezpečnosti. Určitě do toho má co mluvit IOMMU v případě mapování PCI(e) zařízení guestům, ale nejsem si jistý, zda v defaultní konfiguraci prostě pustí BM transakce ze strany PCI sběrnice kamkoli do RAMky fyzického hostitele.
A pokud se k obrazu RAMky dostanete, k nápadu "něco z toho zjistit" se tu vyjádřili ostatní. Kdyby aspoň ten obraz byl "plochý", ale ony user-space aplikace dostanou fyzickou RAMku přidělenou několikapatrovým překladem adres stránkovacího mechanismu, a pak nad tím přídělem ještě běží nějaký alokátor... Takže najít a parsovat kernelové page allocation tables, a nad tím alokátor příslušné "runtime knihovny" dané aplikace... a pak se snad dostanete k nějakým datům.
Zkusil bych tomu stroji dát kouř Memtest86+ (https://www.memtest.org). Přes noc, nebo pár dnů v kuse.
Pokud PC tohle ustojí, tak to pořád není garance, že tam není nějaký další bug. Třeba pokud je načatá grafika, tak zatuhlý grafický ovladač asi dokáže systému taky solidně zamotat hlavu.
Čerstvá verze memtestu je koukám sedmička (hledejte string "latest version"), já tuším jedu ještě na 6.20 - viz archiv (https://www.memtest.org/archives), pokud nemáte rád kulaté verze.
-
IIRC hotplug na PCIe* není úplně samozřejmost.
*) Předpokládám, že nebylo myšleno původní PCI.
-
Nejsem si jistý, zda přístup z PCI do adresního prostoru hostitelova procesoru (resp. fyzické DRAM) podléhá nějakým omezením, a jakým. Vím že PCI host bridge (a další bridge za ním) filtrují/dekódují přístup z hostitele do MMIO oken periferií - ale opačným způsobem... nevím. Je možné, že se toto v průběhu desítek let vývoje PCI nějak vyvíjelo, předpokládal bych směrem k utužení bezpečnosti. Určitě do toho má co mluvit IOMMU v případě mapování PCI(e) zařízení guestům, ale nejsem si jistý, zda v defaultní konfiguraci prostě pustí BM transakce ze strany PCI sběrnice kamkoli do RAMky fyzického hostitele.
Pokud mas IOMMU a je nastaveno, tak to kazdou kartu pusti jen na vyhrazeny pisecek - aktualne mapovany region, o ktery pozadal driver.
Pokud nemas IOMMU, tak muze karta cist co chce. Prakticky omezeni pak je takove, ze kdyz pak ctes region ktery bys cist nemel (smm ram, nebo jine vyhrazene oblasti resp diry v regionu fyzicke pameti), tak je vysoka sance ze se HW dostane do stavu, ve kterem to prestane fungovat i na teto urovni a nezbyva ti nic jineho nez power cycle.
Tech karet je mnoho, ale prave kvulio iommu je pouziti na modernim hw spatne (pokud si clovek explicitne nevypne iommu): https://github.com/ufrisk/pcileech-fpga