Warum sollte ein Programm auf geschützten Speicher zugreifen, wenn nicht aus bösen Absichten oder zum Debugging auf Systemebene?

Irgs. Izotope gehört ja mittlerweile zu Native Instruments... ob deren Sachen auch betroffen sind?

Das wurde ein wenig im Heise-Forum diskutiert. Hier einige mögliche Antworten (deren Richtigkeit ich aber nicht einschätzen kann).

Da hatte ich noch mal Glück gehabt - eine Java-Anwendung die ich regelmäßig verwenden muss läuft weiterhin - nur das Bild im Splash-Screen wird nach ein paar Sekunden horizontal gespiegelt - aber das stört nicht weiter.

Anscheinend hat Apple das wirklich zwischen RC und Release noch geändert und nicht wirklich kommuniziert. So schreiben es auch die Leute von Jetbrains, einem bekannten Hersteller von IDEs, deren Produkte alle auf Java basieren:

PS: Kleiner Tippfehler im Artikel, das Signal heißt SIGSEGV

Danke, ist repariert!

Tatsächlich war die Änderung, welche Java betrifft, bereits in 14.4 Beta 4 vorhanden. Was zwar nicht viel weiterhilft für die Anwendungen die es betrifft, aer immerhin der Vollständigkeit halber.

Ich benutze GoLand und Rider von Jetbrains, mir ist aber noch keine "Absonderlichkeit" aufgefallen.

Nun, ich vermute, dass es sich hier ebenfalls um eine Sicherheitsmaßnahme handelt.
Dem SIGSEGV geht ja eine „Segmentation Fault“ Exception voraus und dem SIGBUS eine „Bus Error“ Exception. Das sind im Allgemeinen Zugriffe auf nicht allokierte (Bus Error) oder geschützte (Segmentation Fault) Speicherbereiche - die normalerweise gar nicht erst auftreten sollten und im Allgemeinen auf „schlechten“ Code hinweise. In C typischerweise Zugriff auf einen NULL-Pointer. (Daher haben native Anwendungen immer eine „PAGEZERO“, die bei 64-Bit 4 GB groß ist - Zugriff auf diese unteren 4 GB führen so zu einem Segementation Fault).

Nun gibt es aber gerne die Methode, auf solche Fehler nicht zu testen („if prt == NULL“) und mit einem Fehlerstatus zurückzukehren sondern statt dessen in der aufrufenden Funktion per (Software-)Exceptions solche Fehler zu fangen („try … catch“). In manchen Programmiersprachen (Java) ist das sogar der übliche Weg (weil es eigentlich keine Pointer gibt).

Das führt dazu, dass Anwendungen darauf beruhen, dass Exceptions (oder Signals) ausgelöst und abgefangen werden. So hat man Programme, die zwar nicht immer das tun, was sie sollen, aber nicht abstürzen.

Nun ist es aber so, dass man eben auch programmatisch Signale und Exceptions fangen kann. Aber gerade bei Exceptions wird der Exception Handler dann im Kernel-Kontext ausgeführt und kann da wirklich allerhand Schindluder treiben. Ist eigentlich dafür gedacht, dass ein Exception Handler die Ursache „heilen“ kann. So funktioniert zum Beispiel auf der Page-Fault, wenn eine Speicherseite ausgelagert (oder komprimiert) wurde. Der Kernel fängt diese Exception, stellt die Speicherseite wieder her und übergibt die Kontrolle wieder an das Programm.

Ich kann mir vorstellen, dass versucht wurde mit Exception-Handlern eben solchen Schidnluder zu treiben um zum Beispiel in fremden Prozessen Speicherbereiche anzulegen, dort Code einzuzschleusen und diesen dann in einem Thread auszuführen. Selbstverständlich hat der Kernel schon Sicherheitsmaßnahmen dagegen, ganz so einfach ist es nicht. Aber es ist möglich - ich hatte damit vor ein paar Jahren experimentiert.

Eventuell gab es jetzt einen Exploit, der die bestehenden Sicherheitsmaßnahmen umgehen konnte und als sicherste Methode, dem Vorzubeugen, hat Apple entschieden, dass in solchen Fällen der Fallback-Exception Handler im System (falls weder Threads noch Tasks Exceptions behandeln) anstelle von SIGSEGV und SIGBUS jetzt einen SIGKILL auslöst, den man auch mit sigmask() nicht unterdrücken kann.

Java ist da also gar nicht unbedingt die Ursache, sondern leidet nur unter den Folgen der Entscheidung. Eventuell müsste die VM anstelle von Signals dann Exception-Handler verwenden, was den Code der VM weniger portabel macht.

Inkompetenz

Die meisten Zugriffe außerhalb des vorgesehenen und reservierten Speicherbereichs passieren schlicht und einfach infolge von Bugs und der Benutzung nicht speichersicherer Programmiersprachen wie C und C++. Wie es mit Java aussieht, weiß ich nicht, um die Sprache mache ich ohnehin einen Bogen, aber es kann gut sein, daß das JDK auch in C bzw. C++ geschrieben ist.

Wie ich versucht habe zu erklären, ist es unter Umständen gar ncht mal die Inkompetenz der Anwendungsentwickler, sondern ein Design-Problem des verwendeten Frameworks. So wie ich es bisher verstanden habe, betrifft das wohl nur bestimmte - aber häufig verwendete - Java Frameworks und selbst scheinen nicht alle Anwendungen betroffen zu sein.

Wie gesagt, in C/C++/ObjC sollte man halt Pointer immer prüfen, bevor man sie verwendet (dafür gibt es dann auch Static Code Analyzer und Address Sanitizer). Da Java am Ende auch nativen Code ausführt, kann es an der Stelle Probleme machen.

Hat schon mal jemand mit Problemen versucht, ob die Anwendung dann mit einer Intel-VM via Rosetta läuft? Rosetta hat ja einen eigenen JIT-Modus, der vielleicht davon gar nicht betroffen ist.