Tag Archives: memory

Firefox: Sicherheitsloch „Memory-Dump“

Posted on by

Im Zuge eines Bugreports für Jitsi Meet kam raus, daß die Speicherfunktion im Firefox Modul „about:memory“ nicht nur den eigenen Speicherinhalt, sondern wohl auch den von anderen Prozessen abspeichern kann. So oder so, muß man aufpassen, was man heraus gibt.

Firefox: Sicherheitsloch „Memory-Dump“

Eine aktuelle Instanz von Jitsi Meet führt zusammen mit der „Hintergrund Blur“ Funktion der Videokonferenzsoftware zu einem massiven Speicherverbrauch von Firefox, der das System nach einiger Zeit zum Swap-of-Death treiben kann. Ob und wann das passiert, hängt natürlich stark von Eurem PC-Setup ab. Bei mir waren es 16 GB Hauptspeicher, die Firefox in knapp 3 Stunden mit 8+ GB eigenem Speicher gefüllt hatte, der Rest war vom System und OBS belegt, als das Problem aus heiterem Himmel auftrat. Da es sich um das LPD Live-Streaming handelte, hatte ich zum Glück noch eine zweite OBS Instanz in der Hinterhand, die das Streaming dann direkt übernommen hat.

Im Zuge des Bugreports an Mozilla wurde ein Speicherdump angefordert, der allerdings (aller Wahrscheinlichkeit nach) auch Daten des laufenden Matrixclientens enthielt, sowie sensible Zugangsdaten, die Firefox gerade in Benutzung hatte. Die teilweise 190 MB großen Textfiles von Hand nach sensiblen Informationen zu durchsuchen würde viel zu lange dauern. Insgesamt sprechen wir hier über eine etwas weniger als 1 GB große Textfilesammlung.

URLs, Userids und Matrixdaten

In den Files habe ich besuchte URLs mit GET Parametern, UserIDs für Jitsi und sämtliche Nutzernamen von dem Clienten bekannten Matrixbenutzern gefunden. Da Firefox nur mit einem Testbenutzer in Kontakt kam, kann es fast unmöglich Firefox gewesen sein, dessen Speicher die Benutzerkennungen von anderen Matrixaccounts enthielt.

Ich kann Euch nur raten, diese Textfiles vor dem Übersenden an den Support von Mozilla in Augenschein zu nehmen, damit Euch nicht sensible Daten abhanden kommen. Wenn der Bugreport im Tracker nicht als „Security“ Report markiert ist, kann jeder diese Datenfiles runterladen und darin nach Herzenslust rumstöbern.

Am Wochenende hatte erst von Golem den neuen Firefox-Absturzreport als „positiv für andere Software-Projekte“ bezeichnet. Nachdem was in meinem Dump ( nicht vom Absturztool erzeugt ) drin war, glaube ich das sofort, nur bin ich da anderer Ansicht. Ein Browser ist heute ein sehr sensibles Stück Datenhalde, da kann man nicht mehr einfach alles zum Hersteller schicken und schon gar nicht von an dem Problem unbeteiligten Prozessen.

Kleiner Lacher am Rande: Das angeforderte „Mozilla-Regressiontool“ 4.0.17 muß wohl auch erst einmal gefixt werden, es crasht nämlich beim Start hart und schmeißt einen Coredump 😉

…
Fontconfig warning: „/etc/fonts/conf.d/90-synthetic.conf“, line 5: unknown element „its:translateRule“
Fontconfig error: „/etc/fonts/conf.d/90-synthetic.conf“, line 5: invalid attribute ‚translate‘
Fontconfig error: „/etc/fonts/conf.d/90-synthetic.conf“, line 5: invalid attribute ’selector‘
Fontconfig error: „/etc/fonts/conf.d/90-synthetic.conf“, line 6: invalid attribute ‚xmlns:its‘
Fontconfig error: „/etc/fonts/conf.d/90-synthetic.conf“, line 6: invalid attribute ‚version‘
Fontconfig error: Cannot load config file from /etc/fonts/fonts.conf
Fontconfig warning: FcPattern object weight does not accept value [0 205)
Speicherzugriffsfehler (Speicherabzug geschrieben)

Da ist wohl „einiges“ im Argen bei Mozilla 😉

Quelle: https://github.com/mozilla/mozregression/releases

Powertop SegFaultet … schon wieder

Posted on by

Wer im März und April das Blog verfolgt hat, der konnte an der Tablet Artikelserie praktisch nicht vorbeikommen. In dem Beitrag Das Surface Pro 4 mit dem Linux Touch wurde PowerTop vorgestellt und wie man damit die Laufzeit des Tablets verlängern kann.

Segmentation Fault

Als der Beitrag geschrieben wurde, war PowerTop gerade nicht einsatzbereit, weil es Segmentation Faults produziert hat, so eine eher unspezifische Fehlermeldung die alles als Ursache haben kann. Da neben mir auch andere diesen Bug bei PowerTop gemeldet hatten, wurde zwischenzeitlich eine Version verteilt, die wieder lief.

Leider ist die neuste Version schon wieder buggy. Diesmal wissen wir aber ungefähr wieso:

failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)
failed to mmap with 12 (Cannot allocate memory)

Bleibt zu hoffen, daß es wieder recht zügig behoben wird. Scheint eine Krankheit zu sein, zuviel Speicher zu allokieren: Nachzulesen im Artikel …. I wish

Games: Astrolords mit Touchsupport?

PHP-CGI verbraucht zuviel Speicher

Posted on by

Dieser Beitrag ist aus der Kategorie:

„Was kann da schon schief gehen“

Speicher ist billig, aber doch endlich und nicht beliebig nachrüstbar.  Es kann also Situationen geben, wo man Speicher einsparen muß, weil andere der irrigen Meinung, waren, das mit dem Speicherverbrauch  wäre kein Problem.

Aber der Reihe nach:  Was ist überhaupt das Problem ?

PHP als CGI ausgeführt, verbraucht pro Start > 400 MB Speicher fürs Nichtstun.

Beispiel:  „php-cgi -a“ startet PHP ohne irgend was zu machen.

In einer zweiten Konsole läßt man sich mit pmap anzeigen, wer in dem Prozess was an Speicher belegt:

pmap {pid of process}

Beispielausgabe ( gekürzt : Warum kommt später )

[root@xxx]# pmap 5408
5408:   php-cgi -a
0000560d00b44000   3724K r-x– php-cgi
0000560d010e6000    536K r—- php-cgi
0000560d0116c000     16K rw— php-cgi
…
00007fce773f8000     28K r-x– libcrypt-2.23.so
00007fce773ff000   2044K —– libcrypt-2.23.so
00007fce775fe000      4K r—- libcrypt-2.23.so
00007fce775ff000      4K rw— libcrypt-2.23.so
…
total           420372K

Genau, 410 MB und nicht eine Anweisung ausgeführt. 3.7 MB gehen für den PHP-Interpretercode selbst drauf, ok. 2 MB gehen alleine für die libcrypt drauf.

Und jetzt der Grund wieso die Ausgabe gekürzt ist: PHP benutzt 75 Libs => ~ 160 MB Speicherverbrauch … bei jedem Script!

Bei der Analyse ist aber aufgefallen, daß auch eine Locale eingebunden wird:

-rw-r–r– 1 root root 110562112 22. Dez 12:01 /usr/lib/locale/locale-archive
-rw-r–r– 1 root root         0 22. Dez 12:01 /usr/lib/locale/locale-archive.tmpl

Auch bekannt als 107 MB und diese Datei wird in jeden PHP Prozess geladen,  der läuft. Keine Gnade.

Locale  – was sind das ?

„Locals“ sind keine Eingeborenen, sondern nur die Informationen über jene, also Zahlensysteme, Schreibrichtung, Datumsformat, Gewichte, Längen usw. . Wer mal sehen will, welche auf seinem Linux installiert sind, gibt das ein : locale -a

Da kommen Sachen von Sprachen, wo man nicht mal sagen kann, wo die passenden Länder sind 😉

Irgendwann hat Red Hat mal entschieden, daß die einfach alle Sprachen des Planeten ausliefern, weil dann der User nicht mehr machen muß. Stimmt.

Auf einem Desktopsystem ok. Aber auf einem Server ist das nicht ok und deswegen muß das auf ein gesundes Maß gedrückt werden. Das macht man mit  : /usr/sbin/build-locale-archive -v -l „de:en:ru:jp“

„Oh… geht ja gar nicht“ ????

Doch geht, aber nur mit Trick Siebzehn aus der „Erschiesst den Trottel Ecke“.

Die obige Locale-Archiv-Datei kommt mit dem Paket „glibc-all-langpacks“ auf den Server. Damit kommt aber auch ein TEMPLATE File mit, aus dem man sich genau das Archiv selbst bauen kann, wenn man eben nicht alles haben will.

…

Ihr habt’s erfaßt, das wäre zu einfach gewesen 🙁

Die Templatedatei ist nämlich LEER und damit nicht zu gebrauchen. Ihr Fragt Euch jetzt : „Wie bekommt man so ein Template?“ hmm.. Tja.. aus dem Repo jedenfalls nicht und doch, bekommt man. Jetzt wird es lustig, wir kopieren das vorhandene Archiv als Template für sich selbst ! Ja, richtig, mit der Faust durchs Auge: In your Face Red Hat!

Also eingegeben:

cp locale-archive locale-archive.tmpl
/usr/sbin/build-locale-archive -v -l „de:en:ru:jp“
locale -a

und schon ist das File keine 107 MB  mehr sondern nur noch 7 MB und auch das halte ich für extrem viel Schrott für 4 Sprachen. Aber jetzt lädt das php nur noch 7 MB rein. Das macht in der Endabrechnung dann 25% weniger RAM Verbrauch.

Als nächstes muß man rausfinden, wieso die Libs jeweils 2 MB verbrennen, wenn die nur 70k groß sind. Aber das ist eine andere Geschichte aus dem |-: La-La-La-Land 😐 .