Gibt es einen besseren Weg als das Analysieren von/proc/self/maps, um den Speicherschutz herauszufinden?

Question

Unter Linux (oder Solaris) gibt es einen besseren Weg als Hand /proc/self/maps wiederholt zu analysieren, ob Sie lesen, schreiben oder ausführen können, was an einer oder mehreren Adressen im Speicher gespeichert ist?

Zum Beispiel haben Sie in Windows VirtualQuery.

In Linux kann ich mprotect diese Werte ändern, aber ich kann sie nicht zurück lesen.

Darüber hinaus ist es eine Möglichkeit, zu wissen, wann diese Berechtigungen ändern (zB wenn jemand mmap auf eine Datei hinter meinem Rücken verwendet) als etwas schrecklich invasive und mit ptrace auf alle Threads im Prozess zu tun und das Abfangen jeden Versuch zu machen a syscall, die die Speicherabbildung beeinträchtigen könnte?

Update:

Leider bin ich mit diesen innerhalb eines JIT, die sehr wenig Informationen über den Code hat es ausgeführt wird eine Annäherung zu bekommen, was konstant ist. Ja, ich weiß, dass ich eine konstante Karte veränderbarer Daten haben könnte, wie die von Linux verwendete vsyscall-Seite. I kann sicher auf eine Annahme zurückfallen, dass alles, was nicht in der ersten Analyse enthalten ist, veränderlich und gefährlich ist, aber ich bin nicht ganz glücklich mit dieser Option.

Gerade jetzt, was ich tue, lese ich /proc/self/maps und baue eine Struktur, die ich für den Schutz einer gegebenen Adresse binär durchsuchen kann. Jedes Mal, wenn ich etwas über eine Seite wissen muss, die nicht in meiner Struktur ist, lese ich/proc/self/maps erneut, vorausgesetzt, dass es in der Zwischenzeit hinzugefügt wurde, oder ich würde sowieso segfault werden.

Es scheint nur, dass das Parsen von Text, um an diese Informationen zu gelangen und nicht zu wissen, wann es sich ändert, schrecklich ist. (/dev/inotify funktioniert nicht auf so ziemlich alles in)

Answer 1

Ich kenne kein Äquivalent von VirtualQuery auf Linux. Aber einige andere Möglichkeiten, es zu tun, die möglicherweise nicht funktionieren, sind:

• Sie Setup ein Signal-Handler Trapping SIGBUS/SIGSEGV und gehen Sie voran mit Ihrem Lese- oder Schreib. Wenn der Speicher geschützt ist, wird Ihr Signalfangcode aufgerufen. Wenn nicht, wird Ihr Signal-Trapping-Code nicht aufgerufen. So oder so gewinnst du.

• Sie könnten jedes Mal, wenn Sie mprotect aufrufen und verfolgen eine entsprechende Datenstruktur, die Ihnen hilft zu wissen, wenn eine Region gelesen oder schreibgeschützt ist. Das ist gut, wenn Sie Zugriff auf den gesamten Code haben, der mprotect verwendet.

• Sie können alle mprotect Aufrufe in Ihrem Prozess überwachen, indem Sie Ihren Code mit einer Bibliothek verknüpfen, die die Funktion mprotect neu definiert. Sie können dann die erforderliche Datenstruktur erstellen, um zu wissen, ob eine Region schreibgeschützt ist, und dann das System mprotect aufrufen, um den Schutz wirklich einzustellen.

• können Sie versuchen, /dev/inotify zu verwenden und die Datei /proc/self/maps für jede Änderung zu überwachen. Ich schätze, das funktioniert nicht, aber sollte den Versuch wert sein.

Answer 2

Es sorta ist/war/proc/[pid | Selbst]/pagemap, Dokumentation im Kernel, Einsprüche hier: https://lkml.org/lkml/2015/7/14/477 So ist es nicht ganz ungefährlich ...