Názory k článku Pod pokličkou vašeho počítače: adresování procesorů Intel x86
-
Pekny a prehledny. Jen par zanedbatelnych detailu:
* TSS = Task State Segment, ne Task Switch Segment.
* prepnuti procesu neprovadi casovac ale jadro vzbuzene casovacem.
* mozna by stalo za to v zavorkach za pouzitymi terminy uvadet anglicky original. Precejenom se clovek spis setka s anglicky psanou literaturou na tohle tema.
Ale to jsou fakt jen drobnosti. -
Martin (neregistrovaný)Pěkný článek, tohle mě opravdu zajímá. Ale protože toho o chráněném režimu moc nevím, tak musím přiznat, že po přečtení tohoto článku jsem nějak přesnou představu nezískal (možná až si to ještě nekolikrát přečtu a nakreslím). Chtělo by to více rozepsat a vysvětlit, přidat nějaké obrázky co kam odkazuje a odkud se co bere a jak se to skládá dohromady. Nemáte nějaký tip na knihu, skriptum odkaz na web, kde by byli tyhle a podobné věci podrobně popsané např. i s konkterétními příklady a assemblerem. Datasheety k procesorům se mi nějak studovat nechce.
-
Protoze Intel ve sve neskonale moudrosti diktovane marketingem rozhodl, ze jeho P3 chipsety pro SDRAM pameti budou podporovat maximalne pul giga a pokud chce nekdo vic, at si priplati na "modernejsi" board s chipsetem pro RDRAM (kterej ale stejne vetsinou neumel vic nez 512MB, ale to bylo omezeni boardu, ne chipsetu, takze v tom byl Intel nevinne :-))
-
em. (neregistrovaný)hmm.. ja jen takovej dotaz, uz je to hodne davno kdy jsem videl 286, ale pokud se nepletu, tak i tyhle procesory umely protected mode, ale ze navrat do realnyho modu byl jedine mozny restartem celeho stroje... a pokud si dobre pomatuju tak duchovni otec internetu preci prohlasil, ze 640kilo musi stacit, tak co s nakejma megabajtama ci gigabajtama pameti.... :0)
-
Autor se mu na zacatku clanku elegantne vyhnul (preskocil ho) ono 1MB pameti bylo opravdu dost. 386 procesory prisli jeste v dobe kdy prakticky neexistovala aplikace ktera by na toto omezeni nejak vyrazne narazela. To ze jeste na 486kach se stale pouzivaly 16ti bitove programy nebyla rozhodne chyba Intelu. Diky ti, Bille :-).
-
markon (neregistrovaný)Uplne stejne je to ale dneska se 64bity, existuji procesory, ale software ne. BTW Bill Gates nikdy neprohlasil, ze 640kB je nejake maximum, je to jen dlouha fama.
Nicmene jeste ke clanku, moc mi nevyplynulo k cemu byl ten chraneny mod, vsechny hry to zobrazovali a pod windows na to byl nejaky emulator, nemohl by mi to nekdo priblizit -
Marek Brunda (neregistrovaný)Chraneny mod hry pouzivaly, aby mohly linearne adresovat celou RAM bez nutnosti zonglovant se segmentovymi registry a nebo 32bitovy adresovy prostor adresovat pomoci 36ti bitu. Ono 64kB segment neni pro hru zadny terno, zvlaste kdyz disponujete 386kou, ktera ma neuverite 4MB RAM:) Jinak dnesni OS pracuji v chranenem modu vsechny.
Nesrovnavejte 16bit -> 32bit k 32bit -> 64bit. Aspon ne na Intelu:) -
Rika se tomu "flat mode" a vyuziva se toho, ze po prepnuti zpet do realnyho modu obsahujou segmentovy registry porad informace z chranenyho modu. Intel ve specifikaci pozaduje, aby se po tomhle prepnuti znovu naladovaly segmentovy registry, cimz se zacnou chovat jako klasicky realmodovy segmentovy registry, ale pokud se to neudela ;-)
Umi to treba DOS knihovna FRMI, pouziva se to pomerne casto treba v BIOSu pri testu pameti a asi i leckde jinde. -
Alien MasterMynd (neregistrovaný)Ona taky existuje nedokumentovana instrukce LOADALL, ktera z pameti nacte vsechny registry (vcetne nejakych skrytych) a vcetne deskriptorove cache segmentovych registru - a to v realnem rezimu.
Co se tyka prechodu z PM zpatky do RM na 286, tak to nebyl restart celeho stroje, ale jen reset procesoru. -
seth (neregistrovaný)Takovy maly komentar:
- kdyz sem pred lety psal zapoctak na prepnuti do protected modu na 386+, samozrejme jsem se nechal inspirovat tehdy znamym programkem unreal, ktery nastavovale tento "flat mode" (tehda se to tak skutecne jmenovalo, nikoliv unreal mode).
Ackoliv se mi prepnuti do protected modu nedarilo (porad to tuhlo a tehda zadna sance odladit takovou vec nebyla, protoze debuggery pro protected mod nebyly), presto se mi podarilo objevit celkem vyznamnou vec a to, ze flat mode lze pouzit i bez prepnuti do protected modu a naslednehoavratu zpet. Alespon to tedha fungovalo na procesorech 386, 486 a myslim ze i na Pentiu. Slo pouze o to prislusne nastavit tabulky descriptoru, coz lze i v real modu a pak pouzivat 32bitove adresovani pro pristup k pameti. -
iki (neregistrovaný)jj, povolite adresni linku a20 pro adresovani nad 1MB, prepnete procesor do protected, nastavite limity segmentu z 64k na 4g, prepnete zpet do realu a pokud je zaveden XMS ovladac tak alokujete pamet pres nej, jinak pres int 15h (tusim).
Funkcni implementace viz http://admin.virt.cz/asm/nivr95a1.zip. 3D kod v tom prikladu napsal TomBy. -
> Uplne stejne je to ale dneska se 64bity, existuji procesory, ale software ne.
Jsme na severu o Linuxu, ze ano? Tak vezte ze az na par closed-source vyjimek (napr. acrobat reader) jsou snad vsechny distribuce dostuplne i v 64b verzi. Jasne ze 64b bash je vam k nicemu, ale 64b GIMP + spousta pameti + ohromne obrazky, to uz je znat.
Ale nejen open sourcem ziv je clovek, takze si muzete koupit 64b Oracle nebo 64b IBM DB2 (ostre verze, ne nejake bety jako WinXP64). Cili bych rekl, ze na jiste platforme by software byl :-)
Mimochodem WinXP64 je vazne komicky system - pustim Explorer (asi 64b), jdu na Windows Update a dozvim se, ze Windows Update vyzaduje 32b explorer. Mno jeste to Billovi hosi nemaji uplne zvladnuty, coz je ale skoda, protoze teprve s dostupnosti WinXP64 zacnou lidi tenhle procesor ve velkym kupovat a stane se z nej mainstream. Do ty doby, co si budem nalhavat, to s par 64b distribucema linuxu nevytrhnem. -
Jojo, to byl masochismus. Je to už 12 let, co jsem ze zvědavosti si dělal prográmek pro kopírování disket (disketa -> paměť -> disketa). Bylo to fakt brutální, hlavně když jsem si hrál se segmenty a offsety. Po dvoutýdenní práci (to jsem byl začátečník) to skutečně chodilo, až na tu maličkost, že na konec té aplikace byl zapotřebí restart.
-
Na 286 byly dve moznosti - budto vygenerovat reset s tim, ze se kamsi do pameti zapsala informace, ze tohle je reset pro navrat z chranenyho modu, takze BIOS to odchytil hned v pocatku a nezacal provadet standardni inicializaci pocitace, nebo pomoci "tajny" instrukce. Ta instrukce se jmenuje LOADALL, neni bezne dokumentovana a funguje tak, ze naladuje obsahy vsech registru z pameti. Slovnim spojenim "vsechny registry" jsou mineny skutecne vsechny registry vcetne jinak nepristupnych internich registru CPU - no a jeden z nich udrzuje i informace o protected/real modu.
Tuhle instrukci implementoval Intel, aby mohl snadno testovat chovani procesoru za ruznych nestandardnich situaci. Podobna existuje i u 386 a mozna i dalsich CPU. -
Hmm...nejsem si jistý, jestli LOADALL funguje i na switch protect->real. Informace o protected/real modu neni nikde skryta, ta je úplně normálně v MSW. Akorát ten bit nejde změnit z hodnoty protected na hodnotu real. :-)
Mmch. klasickým způsobem resetování CPU je požádat keyboard controller o vyslání signálu RESET. Jenže to je periférie, tudíž je to dost pomalý; jestli chcete (samozřejmě, že dneska ne, tehdy :-) ) pouštět pod woknama na 286ce staré programy, tak potřebujete dost rychle přepínat protected->real, což takhle nejde. Nuže, jak na to? Pomocí triple faultu. :-)
-
Prave ze LOADALL dokaze zmenit VSECHNY bity vsech registru:
http://www.x86.org/articles/loadall/tspec_a3_doc.htm -
Nedokumentovana instrukce LOADALL v procesorech 80286 a 80386:
Instrukci LOADALL nelze v 80286 provest prepnuti z chraneneho rezimu do realneho. Jakmile je v 80286 jednou chraneny rezim zapnut (nastavenim bitu PE na jednicku v registru MSW), musi byt instrukci LOADALL plnen registr MSW tak, ze ma v bitu PE jednicku. Jedinou moznosti jak prepnout zpet do realneho rezimu je aktivovani signalu RESET.
-
Petr F (neregistrovaný)Zdravim vsechny.
V clanku bych ocenil informace, co byla "genialni programatorova myslenka"
a co jen prasarna na usetreni penez.
Realny mod znam, takze 16+16=20 je podle meho cista prasarna,
ale protected ne a prijde mi dost slozity.
Neni tam take neco podobneho, co na prvni pohled nedava vubec smysl
a je to tam jen pro usporu nakladu pri vyrobe?
Jinak clanek je IMHO velmi hodnotny a ocenil bych mnoho dalsich podobnych. -
jrx (neregistrovaný)no 16 + 16 = 20 nie je "prasarna" to jednoducho vzniklo kvoli kompatibilite z 8 bit procesormi.
napr. 8080 mal 16 adr. zbernicu cize dokazal adresovat 64 kB pamete a bezal na nom napr. operacny system CP/M. no a aby sa zabezpecilo jednoduchsie portovanie programov na novy procesor 8086 resp 8088 tak bolo vhodne aby bola podobna adresacia. a IMHO nikto nemohol tusit k akym "sialene" velkym kapacitam RAM raz prideme :-) takze ten 64kB segment sa vyvojarom zdal v pohode :-) no a kvoli spetnej kompatibilite mame 16+16=20 dodnes :-) -
black.Bill (c) (neregistrovaný)Clanek se mi docela libil, na to na jaky server byl umisten. Par OS jsem jiz napsal (bez podpory PM), takze o problemu x86 a >> trochu vim a rekl bych ze adresovani v RM je docela povedene, protoze kdyz clovek potrebuje naprogramovat treba nejakeho robota a ma k dispozici nejaky intel chip tak je schopen udelat program, ktery ma treba i 1mb... Jinak RM je duleziny, nejen pro to ze i nejnovejsi 64b procesory po nacteni boot sectoru se nachazeni v RM pri 16b adresovani a je uz jen na jadru OS jestli prepne CPU do strankovaci,atp... rezimu.
-
Petr (neregistrovaný)Už delší dobu přemýšlím jak je možný na i386 architektuře buffer overflow útok. Vžfyť datové segmenty mohou mít důsledně zakázáno spouštění kódu. V čem je problém? Proč to tak není?
Nějaký problém v tom asi bude.,Ještě jsem neslyšel o systému, kde tento způsob útoků neexistuje. -
rrrado (neregistrovaný)Segmentacia sa totiz vobec nepouziva vo win ani v linuxe, pretoze koli kompatibilite s velkym mnozstvom procesorov musi byt jadro naprogramovane tak aby bezalo aj na najhorsom procesore. A myslim ze niekolko podporovanych procesorov segmenty nepodporuje, len stranky, tak sa aj na x86 pouziva len strankovanie
-
Problem je v tom, ze ve vetsine pripadu existuje prekryv mezi obsahem datovych a kodovych segmentu, nejcasteji o velikosti 4GB. Hlavnim duvodem je, ze vetsina prekladacu predpoklada flat memory model (a napr. sizeof(void *)==sizeof(int)) a neni schopna generovat kod pouzitelny pro jine situace.
Nektera bezpecnostni vylepseni (non-executable stack) segmenty pouzivaji.
Novejsi procesory obsahuji i bit non-executable ve strankovani, coz je mnohem praktictejsi metoda ochrany.
Ne vsechny buffer overflow jsou ovsem ciste spusteni dat (jen vetsina). Existuji i slozitejsi okliky. -
online (neregistrovaný)Koukam jak pan autor tak vyhybave preskocil TSS :-)) Onehda jsem se s par lidmi na toto tema docela dlouho dohadoval, nehlede na to, ze jsem se pokusel prepinani tasku "jako to panbuh a intel v x86 chtel" pokousel naimplementovat, ovsem marne.. Kdyby nekdo mel zajem videt co jsem nabastlil (je toho vic ;-) nebo chtel podiskutovat , at mi pisne na vsiman@grall.cz
-
Jenom upřesnění: Na x86 nemůže flat memory model fungovat popsaným stylem „nadefinovat si jeden velký segment s bázovou adresou 0 a limitem rovným velikosti operační paměti - a přiřadit selektor tohoto segmentu všem segmentovým registrům“, protože do kódového segmentu nelze zapisovat a datový segment nelze provádět. Potřebujete nejméně dva segmenty (jeden kódový, druhý datový), selektor kódového dáte do CS, selektor datového do všech ostatních. (V praxi ještě jinak, protože se hodí používat registry FS, GS např. pro thread local storage apod., ale pod dva to prostě nejde vůbec, pokud chcete mít nějaká data. :-) )
-
jfk (neregistrovaný)Pekny clanek..ale tohle uz jsem se ucil na stredni skole, na vysoky, cetl jsem o tom knihu a spousty clanku..takze dalsi clanek na toto tema povazuji za relativne zbytecny (i kdyz jich neni nikdy dost..). Dokazal by nekdo nastudovat stejnou problematiku pro nejaky alternativi procesor? Anicka by mozna zvladla PowerPC, to by mne zajimalo vic protoze pres veskerou teoretickou pripravu ve veci x86 CPU jsem nakonec skoncil u pocitace s PowerPC :) (a jiste nejsem sam..)
