spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Sofern der Treiber ordentlich arbeitet. Natürlich können Objekte und Texturen dort verbleiben, falls man sie nicht löscht und der Treiber dies ebenfalls nicht tut.

Zitat von »Nimelrian«

Das meint er nicht. Er meint, dass du mit free()/delete einen Memorybereich zwar wieder für andere Anwendungen freigibst, deine Daten aber noch drinstehen. Bei sensitiven Daten sollte man den Speicher deswegen vorher mit Ramsch-/Nullbytes füllen.

Nicht ganz richtig – das SecureZeroMemory() ist für den Fall, dass ein Exploit im Prozess selber auftritt und die allokierten Seiten durchsucht. Andere Prozesse können freigegebene Daten sowieso nicht mehr auslesen weil Windows grundsätzlich alle Speicherkacheln nullt bevor sie einem Prozess zur Verfügung gestellt werden. (Ebenso wie die Sektoren des Dateisystems genullt werden bevor eine Datei drauf angelegt wird, was eine bekannte Leistungseinbuße ist.)

Zitat von »Krishty«

weil Windows grundsätzlich alle Speicherkacheln nullt bevor sie einem Prozess zur Verfügung gestellt werden

Ist das so? Denn dann frage ich mich wieso neu allozierte Arrays so viele Müll-Daten enthalten. Oder sprichst Du von Debug-Runtimes?

Ist immer so; das ist Teil der Prozessisolation. Der Müll, den du siehst, kommt aus deinem EIGENEN Prozess. Falls du es schaffen würdest, Müll eines anderen Prozesses zu sehen, hättest du ein wirklich übles Sicherheitsleck entdeckt.

Tatsächlich gibt es unter Windows genau einen Systemprozess allerniedrigster Priorität: Den Dienst, der nichts anderes tut, als freigegeben Speicher zu nullen damit das nicht erledigt werden muss wenn Anwendungen anfangen, Speicher zu allokieren.

Woher kommt der Müll wenn bisher vom eigenen Prozess immer nur Speicher angefordert, aber nie welcher freigegeben wurde?

Woher weißt du, dass nichts freigegeben wurde? Allein die C-Runtime legt bei der Initialisierung ein ganzes Dutzend Objekte an und gibt sie wieder frei. Die DLLMains abhängiger Module bereiten ihre Daten vor. Nicht zuletzt braucht der Image Loader, der dein EXE-Modul in den Adressraum lädt, auch ein Bisschen Platz für Temporäres.

Z.B. muss auch die Kommandozeile geparst werden, damit deine main() argc und argv erhält. Das schließt auch die Konvertierung von UTF-16 zu ANSI ein. Und jede WinAPI-Funktion, die du dabei aufrufst, allokiert vielleicht selber was, dessen Überreste du dann siehst (schließlich will man erreichen, dass möglichst viel im User Mode arbeitet).

Simples Experiment: Mach VirtualAlloc() und prüf, dass die Seite genullt ist. Du wirst nie eine ungenullte finden. Der Müll kommt also aus bereits bestehenden Allokationen, irgendwo in der CRT.

Ja; und malloc und HeapAlloc kriegen ihren Speicher auch nur von VirtualAlloc. Was immer also drin steht, es kann unmöglich von einem anderen Prozess kommen.

Übrigens bezieht sich das Nullen auch auf andere Aspekte: Die Page File wird genullt sobald eine Kachel freigegeben oder in den Speicher zurückgeholt wird (damit sensible Daten nicht im Klartext auf der Platte stehen).