Manch einer wird das vermutlich schon bei fefe gelesen haben, aus fedora-Kreisen gibt es Beschwerden über defektes Audio beim Abspielen von youtube-Videos. Betrifft mich jetzt erstmal nicht direkt, hier funktioniert das gut und stabil. Aber den Bugreport sollte jeder, der weiß, was memcpy und memmove sind, mal lesen.
Kurzabriss (aus meiner Sicht; alle Details versteh ich [noch] nicht): Von Intel-Leuten wird bei der glibc-Entwicklung ein Patch eingereicht, der die oben angesprochenen Speicherfunktionen für diverse Intel-CPUs (bei 64Bit-Systemen) beschleunigt, teilweise erheblich (fefe ist der Meinung, dass die erhebliche Beschleunigung auf einen möglichen Fehler in der Atom-CPU zurückzuführen ist). Einzige Begründung ist eben diese Beschleunigung. Und diese Änderung krempelt die interne Arbeitsweise der Befehle um, was aber bedeutet, dass bestimmte Annahmen bei der Nutzung über den Haufen geworfen werden. Für memcpy(3) ist zB. eine Annahme, dass die Speicherbereiche von Quelle und Ziel nicht überlappen dürfen. Hat man diese Situation im Programm, ist memmove(3) zu nutzen. Bei Adobe wiederum hat man sich für diese Annahmen offensichtlich nicht interessiert, was bisher nicht negativ aufgefallen sein dürfte. In neueren Linux-manpages von memcpy fehlt da ein interessanter Nebensatz, der den Spezialfall der überlappenden Speicherbereiche als undefiniert bezeichnet. Und jetzt (tatsächlich wurde der Fehler schon im September/Oktober letzten Jahres diskutiert) führt diese Situation eben dazu, dass der bestehende Code im flashplayer mit der alten glibc-Version (Fedora 13) funktioniert, aber in der neuen Fedora-Version 14 nicht mehr. Kein großes Ding, möchte man meinen, es wurden auch verschiedene Würgarounds gefunden – der Fehler in der glibc existiert aber eben weiter. Wenig überraschend tauchen nach und nach weitere Programme auf, die plötzlich Probleme haben.
Was dann am stärksten in dieser Situation nervt, ist die Tatsache, dass die Verantwortung gegenseitig hin- und hergeschoben wird. Die Fedora-Leute (die imo keine Schuld trifft) meinen, dass das nur upstream (also bei den glibc-Leuten) zu behandeln sei; die glibc-Entwickler sagen, dass Adobe schuld ist, weil sie eben den Code nicht so einsetzen, wie das zu machen ist; und Adobe kommt nicht aus dem Arsch, um einen Fix bereitzustellen. Öhm, und was ist jetzt mit dem Fehler in der glibc? Die Entwickler meinen, dass Verhalten der Funktion ist ok und bedarf keiner Änderung. Linus Torvalds, der von dem Fehler eben auch betroffen ist, hat aber einige Argumente aufgezählt, warum es eben nicht ok ist (Stichwort: prefetch-Logik einer CPU). Es ist nicht das erste Mal, dass die glibc-Entwickler eine gewisse Sturheit an den Tag legen und sinnvolle Argumente vom Tisch wischen. Bis dato bleiben die Änderungen bestehen.
In einem Post, der in der weiter fortgeschrittenen Diskussion (in dem bug-report) auftaucht, macht ein Kommentator einen weiteren, imo schwerwiegenden Aspekt deutlich. Wenn das Verhalten vom memcpy zu falschen Speicherzugriffen führt und vielleicht auch Speicherbereiche überschreibt, ist das ein Sicherheitsproblem. Da die glibc auch noch ein elementarer Bestandteil jedes Std-Linux-Systems ist, kann das auch als schwerwiegendes Problem bezeichnet werden, denn falls ein Malware-Schreiber einen Weg finden sollte, wie dieses Problem für ihn nutzbar ist, dann sind da recht schnell alle Distributionen betroffen, sprich die Wirkung wäre verheerend.
update: ich war gerade fertig mit schreiben und hab auf der glibc-Mailingliste nachgesehen, ob es nicht vielleicht Neuigkeiten in der Angelegenheit gibt. Entgegen meiner Befürchtung, dass nichts zu finden ist, war tatsächlich ein neuer Patch da, der zumindest einen der vorgeschlagenen workarounds implementiert und sicheres Verhalten bewirkt.
