[WinAPI] Read-only-Heap

[Krishty]

Hi,

Ich benutze momentan Windows’ Heap-Funktionen zur Speicherverwaltung und bin damit auch sehr zufrieden.

Nun möchte ich aber bestimmte Regionen, die damit allokiert werden, gegen Veränderungen schützen. VirtualProtect() bietet diese Funktionalität, kann (bzw. soll) aber nicht mit den Heap-Funktionen zusammen benutzt werden …

… gibt es eine Möglichkeit, durch die Heap-Funktionen allokierte Bereiche zu schützen, oder ist das ausschließlich mit durch die Virtual-Memory-Funktionen allokierten Bereichen möglich?

Ich spreche hier explizit von lose verteilten Bereichen, nicht von ganzen Seiten … die Chancen stehen zwar schlecht, aber fragen kostet ja nichts.

Gruß, Ky

[Schrompf]

VirtualProtect hat für mich prima funktioniert, trotz der anders lautenden Doku. Du nimmst einfach den Startzeiger des Speicherbereichs (bei uns mit new angefordert) und fütterst den um die Pagesize bereinigt an VirtualProtect(). Allerdings arbeitet die Funktion nur seitenweise, die Größe einer Seite erfährst Du mit GetSystemInfo(). Kleinere Speicherbereiche als eine Seite gehen also nicht - das führt zu Speicherschutzausnahmen beim Zugriff auf andere Variablen, die nur zufällig in der selben Seite liegen.

[kimmi]

Da Schrompf die Frage schon beantwortet hat, noch 2 Ideen vion mir zu deiner Frage:

1.)Du könntest dir einen eigenen new-Operator implementieren, der zusätzlich zu deinem alloziertem Speicherbereich noch eigene Infos bezüglich Zugriffsrechte anlegt. Damite ließe sich die Funktionsweise von VirtualProtect simulieren. Allerdings hat man dann den Ärger, daß die Heapfunktionalitäten einem nicht die Arbeit abnehmen.
2.) Eine weitere Idee: einen speziellen Allokator implementieren, den man für geschützte Daten benutzen möchte. Der greift dann auf ienen eigenen Heap und VirtualProtect zu. Durch die Vorgabe des Allokators, nur geschützte Speicherbereich anzubieten, könnte man so ebenfalls deine Anforderung erfüllen. Aber auch hier fällt viel Verwaltungsarbeit an ( Allokator schreiben, dafür sorgen, daß andere nicht die Speicherbereiche mit anderen Allokatoren versehentlich freigeben etc.).

Gruß Kimmi

[Krishty]

Danke für die Antworten :)

Kleinere Speicherbereiche als eine Seite gehen also nicht - das führt zu Speicherschutzausnahmen beim Zugriff auf andere Variablen, die nur zufällig in der selben Seite liegen.

Das ist ja das, wovor die Doku warnt. Wenn ein Mini-Block zwischen zwei Seiten liegt, dank Low-Fragmentation-Heap hunderte Mini-Objekte drumrum, schützt man am Ende sein halbes Programm :)

1.)Du könntest dir einen eigenen new-Operator implementieren, der zusätzlich zu deinem alloziertem Speicherbereich noch eigene Infos bezüglich Zugriffsrechte anlegt. Damite ließe sich die Funktionsweise von VirtualProtect simulieren. Allerdings hat man dann den Ärger, daß die Heapfunktionalitäten einem nicht die Arbeit abnehmen.

Das verstehe ich nicht ganz – nur, weil ich eigene Infos vor einen Block schreibe, wird er doch noch lange nicht geschützt?

2.) Eine weitere Idee: einen speziellen Allokator implementieren, den man für geschützte Daten benutzen möchte. Der greift dann auf ienen eigenen Heap und VirtualProtect zu. Durch die Vorgabe des Allokators, nur geschützte Speicherbereich anzubieten, könnte man so ebenfalls deine Anforderung erfüllen. Aber auch hier fällt viel Verwaltungsarbeit an ( Allokator schreiben, dafür sorgen, daß andere nicht die Speicherbereiche mit anderen Allokatoren versehentlich freigeben etc.).

Das klingt ziemlich gut! Ich lege einen eigenen Heap ausschließlich für schreibgeschützte Objekte an. Die Verwaltungsarbeit dürfte minimal sein, denn ich kann ja weiterhin den Windows-Allocator nutzen. Ich allokiere Heap-Speicher, entferne den Schreibschutz (VirtualProtect()), schreibe die neuen Daten rein, packe den Schreibschutz wieder drauf. Dass über die Seiten hinausgeschrieben wird macht nichts, weil der Heap immer in Seiten-großen Schritten wächst und keine veränderbaren Daten enthält.

Ich probiere das gleich mal aus.

[kimmi]

Zu 1.) Stimmt, man müßte dann jeden Zugriff wrappen, keine wirklich gute und performante Idee.

Gruß Kimmi