Ermittlung einer physischen Adresse durch virtuelle Adresse?
Hallo!
1.) Ich habe 4GB RAM und eine Page Size von 0x1000 Bytes am Rechner.
Heißt das ist habe 4GB (Ist das Hex oder Dec?) / 0x1000 = Pages seitens des Betriebssystems die ich benutzen kann?
2.) Jetzt starte ich einen Prozess und will rein testhalber
DWORD* dwPEHeader = (DWORD*) 0x4000E8;
printf("%x\n" , *dwPEHeader);
mir diese 4 Bytes anzeigen lassen, wobei das die Baseadresse ist vom .exe Modul.
Wie komme ich dann auf die tatsächlich Adresse im RAM? Wo doch jeder Prozess diese Adresse im virtuellen Speicher völlig unabhängig verwenden kann?
Die CPU muss ja dann die Page wissen wo das steht und da dann noch den Offset hinzufügen von den Daten dort? Weil sonst lande ich ja immer bei derselben Adresse im RAM?
Ist diese Erweiterung des Adressbereiches ein Grund für das verwenden von Pages, neben der Tatsache dass es keine ungenutzten Lücken unterschiedlicher Größe gibt im RAM?
Lg
4 Antworten
1.) Ich habe 4GB RAM und eine Page Size von 0x1000 Bytes am Rechner.
Heißt das ist habe 4GB (Ist das Hex oder Dec?) / 0x1000 = Pages seitens des Betriebssystems die ich benutzen kann?
Order Number: 325462-072US, May 2020
32-bit paging may map linear addresses to either 4-KByte pages or 4-MByte pages.
0x1000 oder 4KB Pages oder 4 MB Pages sind bei 32-bit die einzigen Optionen!
A page directory comprises 1024 32-bit entries (PDEs).
1024 "pages entries" und damit auch Pages kann ein 32-bit virtueller Adressraum haben.
2.) Jetzt starte ich einen Prozess
Wie komme ich dann auf die tatsächlich Adresse im RAM? Wo doch jeder Prozess diese Adresse im virtuellen Speicher völlig unabhängig verwenden kann?
Jeder Prozess hat seinen eigenen Adressraum also sein eigenes "page directory" und übersetzt die eigene Virtuelle Adresse anders auf den Physischen Speicher.
Die CPU muss ja dann die Page wissen wo das steht und da dann noch den Offset hinzufügen von den Daten dort? Weil sonst lande ich ja immer bei derselben Adresse im RAM?
Ja richtig, dieses Umrechnen der Virtuellen zur Physischen Adresse beinhaltet zuerst das Ermitteln der physischen Page Adresse, und dann wird das Offset dazurechnet. Zumindest glaube ich das, wie soll es denn sonst sein ^^
Ist diese Erweiterung des Adressbereiches ein Grund für das verwenden von Pages, neben der Tatsache dass es keine ungenutzten Lücken unterschiedlicher Größe gibt im RAM?
Ich schätze mal, dass mitunter ein Grund ist, dass du dadurch mit 2 x32 Prozessen 8 GB RAM verwenden könntest, also wenn du auf x64, x32 emulierst, kannst du so mehr Speicher verwenden.
Falls du 32-bit Windows hat, wird das Limit aber immer 4GB sein.
Aber auch bei x64 bit Programmen hat das Paging zum einen den Vorteil, dass jeder Prozess seinen eigenen unabhängigen Adressraum hat, was das Zugriffsrechte-Verwalten einfacher macht und auch ermöglich, dass man sehr große durchgehende Adressräume Reservieren kann.
Ein Beispiel:
Ich habe 32 GB RAM und kann mit einem x64 Prozess z. B. 25 GB mit new oder malloc reservieren, obwohl mit fast absoluter Sicherheit nicht wirklich 25 GB durchgehend im physischen RAM verfügbar sind. Es werden die Pages nur in die Lücken des physischen RAM's einsortiert und mir dann als ein einziger Adressraum nutzbar gemacht.
Noch ein Vorteil von Pages sind die Zugriffsrechte, die Pages mitbringen.
Mann kann lesen, schreiben und ausführen für jede Page einzeln bestimmen.
Dadurch kann man Sicherheitslücken bei Buffer Overflows usw. eher verhindern und auch das Debugging ist übersichtlicher, weil man halt oft den Fehler "Zugriffsverletzung beim Ausführen an Position ..." bekommt (Visual Studio Debugging), anstatt das der CPU sinnlose Daten ausführt, denn der Prozessor kann auch Nullen ausführen oder zufällige Daten manchmal sogar sehr lange, wie aus eigenen Experimenten hervorgegangen ist.
Auch ist der executable-Stack veraltet, wie er bei früher bei GCC und Linux noch verwendet wurde, weil er extreme Sicherheitslücken ermöglicht hat!
Ich hoffe, ich bin nicht zu weit vom Thema abgekommen, mich stört es auch immer, wenn ich so große Antworten bekomme, normalerweise mache ich das nicht ^^
"4 GB" ist Binär. Ein Byte ist 8 mal eine 1 oder 0, folglich ist Irgendwas-Byte immer eine binäre Angabe. Bei Festplatten kann Giga je nach Hersteller 1,000,000,000 oder 1,073,741,824 bedeuten. Bei einem RAM aber immer die Zweierpotenz, also 1,073,741,824 Byte => 2^30 Byte.
4 GB entspricht also 2^32 Byte. Bedeutet deine Adressgröße ist 32-Bit. Die Pagesize ergibt umgerechnet 0x1000 = 2^12.
Folglich haben 1048576 Pages im RAM Platz. Rechnung: 2^32 / 2^12 = 2^20.
Natürlich können, falls denn der RAM voll sein sollte, auch Pages auf die Festplatte ausgelagert werden.
Wie man's zur Physikalischen Adresse umrechnet siehst du hier: https://stackoverflow.com/questions/40292822/translate-virtual-address-to-physical-address/40293053
Genau!
Weiter kann ich dir nicht helfen, das sind alles Details die wir in der Uni nicht lernen, sorry.
Wie komme ich dann auf die tatsächlich Adresse im RAM? Wo doch jeder Prozess diese Adresse im virtuellen Speicher völlig unabhängig verwenden kann?
All das macht die MMU - die rechnet zwischen virtuellen und physischen Adressen um. Daher merkt auch ein normaler Prozess nichts davon und kann auch nicht versehentlich im virtuellen Adressraum anderer landen.
Ist diese Erweiterung des Adressbereiches ein Grund für das verwenden von Pages, neben der Tatsache dass es keine ungenutzten Lücken unterschiedlicher Größe gibt im RAM?
Pages sind einfach eine Frage des Aufwands für die Speicherverwaltung. Würde man jedes Byte einzeln verwalten, bräuchte man dafür mehr RAM als man verwaltet. Also teilt man das Ganze in größere Häppchen auf.
Nebenbei, du scheinst ja eine Menge Fragen zu Windows zu haben: es gibt ausgezeichnete Bücher zum Thema, zu "meiner" Zeit (als ich noch viel auf Windows entwickeln musste) hieß das "Inside Windows NT", heute anscheinend "Windows Internals". Ich weiß dass in Zeiten von Youtube-Tutorials Bücher etwas uncool geworden sind, aber da lernst du diese Details direkt von der Quelle statt von irgendeinem Nachschwätzer. Für so allgemeine Fragen tut's auch ein billiges gebrauchtes Exemplar, soviel änderte sich da nicht: https://www.amazon.de/Inside-Microsoft-Windows-CD-ROM-Programming/dp/0735610215/
Was ich wissen will ist woher die CPU oder das OS weiß, welche virtuelle Adresse sich in welcher Page befindet nicht welche Page in welchem Frame!
Nochmal: dafür gibt's die MMU. Die bildet Pages (also virtuelle Häppchen) auf "Frames" (also physische Häppchen) ab. Und im Regelfall sind die genauso ausgerichet, d.h. die MMU muss nur die höherwertigen Bits der Adresse übersetzen. Das "Offset" in die Page (also die niedrigwertigen Bits der Adresse) hinein ist identisch.
Generell bist du bei dem Thema mehr in der Computerarchitektur als im Betriebssystem. Viele dieser Details unterscheiden sich stark je Architektur (zB ARM und die diversen Intel-Varianten). Das Betriebssystem konfiguriert die MMU, aber es muss sich eben nicht im Detail über das Mapping von virtuellem auf physischen Adressraum kümmern.
Du verstehst es glaub ich nicht ganz:
Wenn ich 100 Prozesse laufen habe, dann kann jeder Prozess die Adresse 0x4000E8 in seinem virtuellen Speicher verwalten, aber trotzdem adressiert dann doch jeder Prozess seine eigene 0x4000E8, also muss es sowas wie eine zweite Adresse geben, die von Windows verwaltet wird aus der dann die "logische Adresse" folgt?
Jeder Prozess hat seinen eigenen virtuellen Adressraum, richtig. Und für jeden Prozess gibt es dementsprechend eine eigene Page Table (eigentlich ein Baum von Tabellen, nicht nur eine einfache Tabelle). Und jetzt darfst du dreimal raten, wer diese Page Table verwendet, um von 0x4000E8 des jeweiligen Prozesses auf die eindeutige physische Adresse zu übersetzen...ein Tipp, ich habe es schon ein paarmal erwähnt...
Ja aber in der Pagetable steht doch nur drinnen, auf welchem Frame sich welche Page befindet?
Aber nicht welche virtuelle RAM Adresse auf welcher Page steht?
Ein anderer Experte meinte die volle logische Adresse könnte aus 2 Adressen bestehen, der "Anschrift" und den 32bit der virtuellen Adresse? Weil jeder Prozess hat dieselben 32 bit virtuellen Adressen?
Ich wüsste nicht, dass in der Pagetable steht, welche virtuelle Adresse auf welcher Page steht? Zumindest ergeht das nicht aus diversen Quellen wie Vorlesungen.
Aber nicht welche virtuelle RAM Adresse auf welcher Page steht?
Weil diese Information schon in der virtuellen Adresse steckt! Bei einer einfachen, nichthierarchischen Page Table sind die oberen n bits die Page-Nummer, und der Rest das Offset, fertig.
Bei einer hierarchischen Page Table gibt es mehrere Ebenen von Page Tables und dann sind es halt die obersten x Bytes für die erste Ebene, dann die nächsten x Bytes für die nächste Ebene, und am Schluss noch das Offset.
Sowas wird in erschöpfendem Detail in Fachliteratur abgehandelt...
Wie gesagt: In den obersten n bits, je nachdem welche Architektur verwendet wird und wie die Pagetables konfiguriert sind. Schau dir das hier sehr schön erläutert für ARM an (auf Intel ist alles tendenziell komplizierter, weil die viel Ballast aus der Vergangenheit mitschleppen): https://developer.arm.com/architectures/learn-the-architecture/memory-management/the-memory-management-unit-mmu
Wie soll das in den Bytes stecken? Bei 200 Prozess kann es die Adresse 200 mal geben?
OK, das ist nun mein letzter Versuch. In einem modernen OS wie Windows ab NT hat jeder Prozess einen völlig eigenen Adressraum der bei 0 startet, und jeder Prozess hat daher eine eigene Page Table (wie oben bereits erklärt). Beim Umschalten zwischen Prozessen wird entsprechend auch die Page Table umgeschaltet. (Darum kümmert sich das Betriebssystem, denn der Prozessor an sich hat keinen Begriff von "Prozess".)
Also ja: es kann dieselbe virtuelle Adresse 200x geben, weil es 200 Page Tables gibt. Und dann geht der ganze Vorgang wie beschrieben.
Wenn es nur eine Page Table gäbe müssten sich die Prozesse tatsächlich den einen virtuellen Adressbereich aufteilen. Gut möglich, dass das zB im Embedded-Bereich auch noch so gemacht wird, weil man sich damit RAM und Aufwand spart.
Ich glaube, ich verstehe es allmälich:
Angenommen ich will die Adresse 0x400500 von Prozess 200 in eax laden.
Dann geht die Anfrage zuerst an Windows nicht an die CPU. Windows schaut dann in die Pagetable von Prozess 100 und looped diese durch und returned einen Error wenn die Adresse auf keiner Page steht oder sieht dann:
Aha! Page 10 geht von 0x400000 bis 0x401000, das trifft auf die gewünschte Adresse zu!
Dann zieht es den ersten Wert ab und kommt auf den Offset 500 auf der Page 10.
Dann gibt es Page 10 + 500 an die MMU und diese sieht Page 10 ist auf Frame 30 und nimmt von da den 500sten Wert und legt den Bus an Eax.
Somit ist virtuelle Adresse ein vollkommen abstraktes Konzept den der Programmierer braucht nur zu wissen wie viel Speicher er braucht / haben kann und sich nicht darum zu kümmern braucht wo das ganze ist, wodurch zwar der indirekte Zugriff über die Schnittstelle OS langsamer ist aber dafür neben der Koordination mit anderen Prozessen noch den Vorteil von Speicherschutz hat.
Falls das soweit zutrifft, würde mich noch interessieren, ob das OS selber überhaupt weiß wo im RAM die Page ist, weil soweit ich weiß nein.
Also wäre diese Ansicht in RAMMap komplett fiktiv, wo Pages bestimmte Adressen haben?
Ich weiß nicht was Du letztlich vorhast... einen (Cheat)Trainer basteln?
Bevor Du Dich in irgendwelche Wagnisse stürzt um auf Adressen außerhalb des virtuellen Speichers deines Programms zuzugreifen:
- um auf Adressen außerhalb des eigenen Adressraums zuzugreifen muss Dein Programm im Kernelmode laufen!
- Programmen im Usermode ist nur der Zugriff auf den eigenen Adressraum gestattet.
Bevor Du in diese Richtung weiterarbeitest, solltest Du Dich eingehend mit der Speicherverwaltung deines Systems auseinandersetzen.
Um auf andere Speicher zuzugreifen gibt es ja Readprocessmemory().
Das ist mir bekannt ..
Das ändert jedoch nichts an den Zugriffsrechten auf den Speicher anderer Prozesse.
https://docs.microsoft.com/en-us/windows/win32/procthread/process-security-and-access-rights
Ich habe Deinen Disput mit @alfredo153 verfolgt und dabei den Eindruck gewonnen, das Du beim Ergründen der nötigen Informationen lediglich Projektbezogen vorgehst und tangierende Themen wie Prozesssicherheit und Speicherschutz für Dich irrelevant sind.
Wir arbeiten nicht mehr unter Dos, wo man beliebig mit den Speicherinhalten verfahren konnte..
Wenn Du bereits über die nötige Funktion (und die Rechte) verfügst, welshalb versuchst Du dann noch direkt mit in der Speicherverwaltung herumzuquirlen? (geht sowiso nicht)
Readprocessmemory() kopiert Daten aus einem Speicherbereich eines anderen Programms in einen für Dein Program verfügbaren virtuellen Speicherbereich. WriteProcessMemory() schreibt Daten aus dito Puffer...
Diese Funktionen haben haben ihren Grund in dem Umstand genau in oben beschriebenem Zugriff im Kernelmode.
Ein Usermode-Programm hat keine Berechtigung auf Speicher außerhalb des eigenen Adressraums zuzugreifen. *ProcessMemory() stellt ledigich eine "Anfrage" an ein Gate zu einen KernelmodeTreiber, Daten von/zu Deinem Speicher zu duplizieren.
Die MMU und Speicherverwaltungstabellen etc. befinden sich ein weiter Ferne für ein normales Programm .
Ich kann Dir hier nicht in einem Kommentar die Regeln der Speicherverwaltung beibringen ...
hier ein Paar ganz allgemeine Grundlagen :
Das weiß ich eh her je.
Kannst du mir nicht einfach sagen, wie ich von 0x4000E8 auf meine logische CPU Adresse komme?
Es geht um allgemeine Verständnis!
Es können 200 Prozesse die virtuelle Adresse mit einem anderen Wert beschreiben, also muss es noch irgendwo etwas geben dass weiß in welcher Page die Adresse von Prozess 1 bis 200 steht?
Und das ist nicht die Pagetable meines Wissens, denn die übersetzt diese von mir gesuchte Adresse in eine Frame + Offset.
Und die Antwort: Das macht die Speicherverwaltung des Betriebssystem kann ich mir auch geben.
wie man (theoretisch) die gewünschte physische Adresse erhält wird in 1000 Beispielen demostriert: https://www.google.com/search?q=virtual+address+physical+memory+address
Ich nenne es Theoretisch, da es in der normalen Praxis völlig irrelevant ist. (es sei denn man programmiert ein völlig neues Betriebssystem, dann müsstest du ber Assemblercode die MMU ansprechen, welche Dir die entsprechenden Einträge liefert)
Es können 200 Prozesse die virtuelle Adresse mit einem anderen Wert beschreiben, also muss es noch irgendwo etwas geben dass weiß in welcher Page die Adresse von Prozess 1 bis 200 steht?
was Interessiert die Page, wenn man ohne ein Programm im Kernelmode diese Informationen ohnehin bekommt.
Du hast selbst die *ProcessMemory() -funktionen ins Spiel gebracht. ergo solltest du eigentlich über deren Funktion wissen.
Du musst nicht nach nach einen Tabelleneintrag für einen Prozess suchen, das erledigt Windows automatisch für dich, Du übergibst ReadProcessMemory() das Handle auf den Gewünschten Prozess, die gewünschte virtuelle Basisadresse für die Daten, die Anzahl der Bytes, welch du ab der Basisadressen haben möchtest und letztlich die Adresse der Variable in welche das Ergebnis geschrieben werden soll.
- https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-readprocessmemory
- https://stackoverflow.com/questions/46431860/how-to-use-readprocessmemory
Du musst garnicht wissen ab welcher Physischen Adresse das zu untersuchende Programm im Speicher "hängt" , es genügt völlig, dass das Betriebssystem weiß, wo sich das Programm befindet.
Das hat nichts mit Ignoranz oder Unwissen Meinerseits zu tun. (in der Übergangsphase zum Prodectedmode haben wir seinerzeit mit diversem Zauber experimentiert zB Huge Realmode).
Aber es bringt absolut keinen Nutzen zu versuchen irgendwelchen aufwändigen Zauber von Hand zu versuchen... Nichts dagegen das Du die Hintergründe kennen möchtest aber erwarte keine Privatvorlesung...
Es gibt relativ wenige Leute, welch sich überhaupt über den Hintergrundkram Gedanken machen. und zugegeben seit den Zeiten wo man noch tricksen müsste um den ganzen Speicher verfügbar zu machen, interessieren mich direkte Hardwarezugriffen nur noch am Rande...
Ich glaube, das ganze ist nicht so leicht zu verstehen wie ich anfangs dachte.
Also ich glaube in erster Linie geht es um die Buchhaltung die Windows betreibt.
Weil wenn ich eine virtuelle Adresse anfrage, dann muss bei größerer Pagesize Windows weniger Einträge durchgehen um festzustellen obs die Adresse überhaupt gibt mit kleiner größer Vergleichen und wenn ja wird die erste Wert abgezogen, um an den Offset zu kommen und dann Page + Offset an die MMU weitergeleitet.
Und der Begriff virtueller Adressraum von mir falsch verstanden wurde, weil das bloß der theoretisch addressierbare Bereich ist dessen Größe von 4 GB weitgehend willkürlich ist, weil man genauso gut 500MB oder 1GB nehmen könnte.
Hat das mit 2 hoch 32 damit zu tun, dass der Systembus dann Adressen in einem Takt übertragen kann und die Register 32 bit haben?
Eine kleine Frage am Rande: Wie groß ist ein CPU Register eigentlich in echt? Und sind die mit Spannung versorgt und flüchtig, erst man PC ausschaltet aber sonst gleich bis sie geändert werden?
Bevor Dir der Kopf abraucht, lege das Thema einfach erstmal bei Seite.
Leute wie ich haben über einen Zeitraum von 35 Jahren die Informationen zur CPU-Architektur in kleinen Dosen genossen und ihr Wissen mit der Entwicklung stück für Stück erweitert.
- Ich habe mit dem U880 begonnen. (Befehlssatz:https://www.iee.et.tu-dresden.de/~kc-club/05/BOOK10/0510-02.HTML)
- 1989 gesellte sich der x86 hinzu (Befehlssatz:https://en.wikibooks.org/wiki/X86_Assembly/X86_Architecture)
- mit den 64Bit-CPU wurde die sache richteig "fett"(Befehlsatz:https://www.felixcloutier.com/x86/)
...allerdings hatte ich als die 64biter kamen schon längst einen anderen Weg eingeschlagen und die hardwarenahe Programmierung war für mich bestenfalls noch theoretischer Natur. (zumal auch noch Sachen wie Grafik und Pixeshader relevant wurden)
Im ernst, mich interessiert herzlich wenig wie Windows den Speicherinhalt managt . Nicht umsonst gibt es Spezialisierungsrichtungen im Bereich der Informatik. Heute kann kein einzelner Mensch mehr alles Überschauen.
Heute kannst Du mit Google auf die gesamte Information dieser Welt zugreifen. Warum dann nicht auch auf Informationen zum Speicher https://en.wikipedia.org/wiki/DDR4_SDRAM , elektronish ist die Funktionsweise von Speicher extrem Komplex den es genügt nicht den RAM mit Strom zu versorgen, die gespeicherten Informationen müssen auch in gewissen Zyklen ständig gelesen und neu geschrieben werden. Refresh
Manche sollte man garnicht im Detail wissen wollen....
Du hast Dir den Nick Usedefault gegeben, also lebe danach... Nimm es wie es ist... sonst kommen irgendwann die freundlichen Männer und streifen Dir eine modische Jacke mit sehr langen Ärmeln über...
Wer sollte etwas überstreifen wollen? Meinst weil ich überschnapp im Wunsch alles sofort verstehen zu wollen? Ich quere ja keine Interessen, weil ich jetzt Google hacke oder so.
Aber so schlecht finde ich Windows nicht, weil wenn man nicht wüsste man hat immer die 4GB Adressraum, egal wo, dann müsste man wissen, wo die anderen Programme liegen um nicht drüber zu schreiben?
Das heißt ich brauche eine Pagetable die 2^20 Einträge haben kann bzw. 20 bit um jede Page zu addressieren?
Angenommen es ist NICHTS ausgelagert:
Wenn ich jetzt eine .exe starte, dann erkennt der ntloader automatisch, dass das Module 6 Pages braucht z. b. oder entnimmt der das dem Header?
Weil der PE-Header belegt anscheinend immer eine eigene Page die erst gar nicht ganz aufüllt und auch alle anderen sections scheinen immer vielfache der Pagesize zu sein?
Und jetzt ist die virtuelle Adresse 0x4000E8 in meinem Beispiel.
Wie komme ich jetzt auf die richtige Page?
Dann muss ja irgendwer wissen, dass sich dieses eine Byte was ich dort haben will auch auf der Page 5 ist? Und dann muss ich erst von jedem Byte die Page wissen?
Also woher weiß ich welche virtuelle Adresse sich auf welche Page befindet?