CleanPress

Schlagwort: Windows

  • (Un)freie Software ist auch (k)eine Alternative

    Photo by Pieter van Noorden on Unsplash

    Neben aktuellen News und längeren Artikeln gibt es auf diesem Blog gelegentlich auch Meinungsbeiträge. In diesem hier geht es um freie und unfreie Software mitsamt ihren Grenzen und Problemen. Kommentare und Anmerkungen zu eigenen Erfahrungen sind willkommen.

    Mit freier Software ist es wie mit dem Vegetarismus. Es spricht vieles dafür, dieser Lebensweise zu folgen. Manchmal ist es aber erstaunlich schwierig, dem Steak zu widerstehen, wenn man sonst nur Beilagen zur Auswahl hat.

    Wenn freie Software keine Alternative ist

    Es gibt Momente, in denen freie Software keine Alternative ist. Diese sind zwar deutlich seltener als gemeinhin angenommen, zumindest zwei Szenarien fallen mir allerdings ein: Zum einen, wenn ein Gerät ohne freie Software gar nicht läuft. So sehr ich auch auf freie Software setzen möchte: Damit allein läuft mein Drucker nicht.

    Zum Zweiten gibt es Situationen, wo man beruflich, schulisch oder universitär Software vorgesetzt bekommt, die unfrei ist. Da hilft kein Jammern: Wenn die Videokonferenz aus dem Hause Cisco stammt, kann man nur darüber teilnehmen. Will man sich dann auch noch selbst beteiligen, so ist man auch angeraten, den (unfreien) Client zu installieren. Gibt es den wenigsten für Linuxdistributionen? Natürlich nicht.

    Das sind Momente, wo man sich die Frage, ob die freien Alternativen wie Jitsi oder BigBlueButton nicht auch taugen, gleich sparen kann. Man ist eh nicht in der Entscheidungsposition.

    Wenn freie Software die Alternative ist

    Allerdings hört hier die Grenze allerdings auch schon auf: Ab jetzt ist man immer in der Entscheidungsposition. Und da macht es dann auch Sinn, sich mit freier Software zu beschäftigen. Diese wird übrigens als solche bezeichnet, wenn sie über folgende vier wesentliche Freiheiten verfügt:

    • Die Freiheit, das Programm auszuführen wie man möchte, für jeden Zweck (Freiheit 0).
    • Die Freiheit, die Funktionsweise des Programms zu untersuchen und eigenen Datenverarbeitungbedürfnissen anzupassen (Freiheit 1). Der Zugang zum Quellcode ist dafür Voraussetzung.
    • Die Freiheit, das Programm zu redistribuieren und damit Mitmenschen zu helfen (Freiheit 2).
    • Die Freiheit, das Programm zu verbessern und diese Verbesserungen der Öffentlichkeit freizugeben, damit die gesamte Gesellschaft davon profitiert (Freiheit 3). Der Zugang zum Quellcode ist dafür Voraussetzung.

    Schon beim Durchlesen dieser Definitionen leuchtet den meisten ein, dass es durchaus Sinn macht, sich an erster Stelle im Entscheidungsprozess auch immer mit freier Software zu beschäftigen. Und diese gibt es eben auch für fast jeden Zweck.

    Wenn unfreie Software die Alternative ist

    Nur manchmal lachen die unfreien Alternativen den Nutzer an. Besonders gerne, wenn sie vorinstalliert sind. Oder aber als Marktstandard gelten. Da stellt sich dann doch die Fragen, wie man damit umgehen möchte. Mitunter erinnern Diskussionen zwischen Verfechtern freier Software und jenen Nutzern, die proprietäre Programme nutzen, an jene, die Vegetarier und Fleisch-Esser führen: Der Nutzer freier Software sieht alle entscheidenden Argumente (zumindest die ethischen) auf seiner Seite und versucht, den anderen davon zu überzeugen.

    Aber wie viele Fleischesser wurden bislang durch eine Diskussion mit Vegetariern zum Vegetarismus bekehrt? Zumal bei einer Diskussion über Freiheit auch hinzukommt, dass der Nutzer Entscheidungsfreiheit besitzt. Er darf sich auch gegen freie Software entscheiden. Auch wenn die Entscheidung nicht unbedingt clever ist. Mitunter bietet sich dann allerdings die Chance, zumindest auf einen freien Standard zu setzen.

    Wenn unfreie Software keine Alternative ist

    Manchmal zeigt sich allerdings auch im Nachhinein für den Nutzer selbst, dass unfreie Software auch keine Lösung ist. Dazu eine Anekdote: Zu Beginn des Jahres kaufte ich mir (gebraucht) ein älteres iPhone. Und das durchaus als Verfechter freier Software. Trotzdem war die Entscheidung bewusst: Ein vier Jahre altes Smartphone, das noch immer mit aktueller Software versorgt wird, ein gutes Energiemanagement verfügt und durchaus sicher ist. Alles Dinge, die die Konkurrenz auf dem Markt der mobilen Endgeräte nicht erfüllt. Mir war bewusst, dass ich mich dabei auch für ein Ökosystem entscheide. Heutzutage sind die Smartphones ja sehr unabhängig von anderen technischen Geräten, was sollte da schon schief gehen.

    Nun, einen ersten Makel erlebte ich früh. Schon beim Versuch, meine Musiksammlung auf das Smartphone zu übertragen, musste ich feststellen: Das geht ohne iTunes schlichtweg nicht. iTunes ist natürlich keine freie Software und läuft unter Linux nicht. Dafür muss man sich eine virtuelle Maschine basteln, die für die Nutzung eines USB-Ports auch wieder ohne freie Software auskommen muss. Da wird dann Windows installiert, danach iTunes und dann darf man sich um seine Musiksammlung kümmern. Das mag heutzutage nur noch wenige Menschen stören, wenn jeder seine Musik streamt. Wer allerdings Musikstreaming ablehnt oder mit der Musik einschlägiger Streamingdienste unzufrieden ist, der muss basteln.

    Trubleshooting XXL

    Aber einige Monate später kam es noch schlimmer: Eines der hochgelobten Upgrades für iOS lief schief. Nichts ging mehr, das Geräte zeigte mir an, dass ich es an einen Computer anschließen sollte. Das soll auch nicht das Problem sein, allerdings ist mit PC heutzutage wohl ein Mac oder ein Windows-Computer mit iTunes gemeint. Eine virtuelle Maschine hingegen funktioniert nicht. Der Restore-Modus des iPhone lässt sich nicht als USB-Geräte an die virtuelle Maschine weitergeben, zumindest bei den bekanntesten drei Programmen für virtuelle Maschinen.

    Hat man kein Mac oder Windows in seinem Haushalt nativ, muss man sich eben eines zulegen. In der Reserve befand sich noch einen bootfähigen Windowsstick. Dieser hat auch mal funktioniert, wollte aber just in diesem Moment nicht: „Medientreiber“ fehlen. Dasselbe gilt dann auch für jeden der weiteren erstellen bootfähigen Sticks und auch kein erdenklicher Treiber des Planeten lässt mich die Installation starten. Nächster Versuch: Es soll eine DVD gebrannt werden, der alte klassische Weg. Allerdings funktioniert natürlich auch dies nicht einfach so.

    Obwohl Windows nach einer Installation eh noch massig Updates runterlädt, ist das Installationsimage über 5 Gigabyte groß. Auf eine Standard-DVD passen allerdings nur 4,7 GB. Ich halte wenig davon, Menschen über das Internet die Kompetenz abzusprechen, schließlich könnte man das bei mir auch wunderbar machen. Allerdings bin ich dicht davor, für die Mitarbeiter aus dem Hause Microsoft, die das Installationsimage für Windows erstellen, eine Ausnahme zu machen. Zu groß für eine normale DVD, zu klein für den „Medientreiber“? Immerhin, im vergangenen Jahr konnte man aus einem USB-Stick auch nicht ohne Weiteres einen Windows 10 Stick machen, weil eine Einzeldatei des Images zu groß für das Dateisystem war, welches zur Windowsinstallation benötigt wird.

    Also erst einmal eine DVD des Typs „Double-Layer“ besorgt, wenig später dann noch einen passenden Brenner (da sind wir wieder bei der Kompetenz, wer austeilt…). Dann also „schnell“ die DVD gebrannt, Windows installiert, Treiber und Updates heruntergeladen, iTunes installiert und iTunes mein iPhone retten lassen.

    Fazit

    Eigentlich haben die Nutzer freier Software alle Argumente auf ihrer Seite. Allerdings stoßen sie doch gelegentlich auf Grenzen. Diese sind zwar deutlich geringer als gemeinhin angenommen und spielen sich häufig eher im Kopf ab. Probleme hat man auch mit unfreier Software. Mich hat die Erkenntnis, dass freie Software und freie Standards viel wert sind, fast einen ganzen Tag an Troubleshooting gekostet. Keine freie Software ist halt auch keine Alternative. Vielleicht finde ich ja noch eine für die mobile Welt.

  • Gefährlicher Design-Fehler in Intel CPUs

    Fehler in Intel CPUs
    Bild: „Intel“ von Christian Rasmussen Lizenz: CC By-SA-2.0

     

    Nach den Erkenntnissen der letzten Wochen zu Intel ME scheint Intel auch 2018 nicht aus den negativen Schlagzeilen herauszukommen. In einem Blog erschien am 1. Januar  ein Artikel, der Hinweise auf einen Fehler sammelte, der anscheinend alle Intel-CPUs der letzten Jahre betrifft. Der Artikel weist zwar einige Fehler und vorschnelle Annahmen auf, folgt aber generell der richtigen Spur. Eine Beseitigung der Sicherheitslücke dahinter ist nur durch teils massive Änderungen an den einzelnen Betriebssystemen möglich, er kann anscheinend nicht in Intels Microcode repariert werden.

    Linux- und Windows-Patches vorhanden

    Bei Linux sind die Patches teilweise in Kernel 4.15 integriert und weitere für 4.16 geplant. Seit gestern abend ist bereits Kernel 4.14.11 gepatched. Bei Windows wurden sie den Benutzern des Fast Ring bereits im alten Jahr ausgeliefert und sollen an einem der nächsten Microsoft-Patchdays offiziell ausgeliefert werden. Apple schweigt sich wie üblich aus. Aber auch Intel hüllt sich über den Fehler in Schweigen. Die Kommentare in den Patches, die die Sicherheitslücke stopfen, verschleiern die technischen Hintergründe.

    Viel geteilter Blogeintrag

    Aufmerksam war der Autor des ersten Berichts durch hektisches Treiben bei den Kernel-Entwicklern in den letzten Wochen und über die Feiertage geworden. Tiefgreifende Änderungen am Virtual-Memory-Subsystem des Kernels, die ansonsten oft über Monate und Jahre diskutiert werden, bevor eine Zeile Code einfließt, brauchten nur wenige Wochen um in Kernel 4.15 einzufließen, der vermutlich in zwei Wochen veröffentlicht wird.

    Hektik bereits seit Oktober

    Der entsprechende Bug hat derzeit den Status embargoed, was bedeutet, dass betroffene Institutionen Kenntnis davon haben, der Fehler aber noch nicht veröffentlicht ist. Die zugrundeliegende Sicherheitslücke und die seit Oktober einfließenden Patches wurden zuerst am 20. Dezember auf LWN näher gewichtet. Der dortige Artikel ist derzeit aber nur für Abonnenten zugänglich und wird erst in den nächsten Tagen freigegeben.

    Torvalds lässt Patches für 4.15-rc4 zu

    Linus Torvalds hatte sich zu den sogenannten KAISER-Patches, die seitdem in KPTI für Kernel-Page-Table-Isolation umbenannt wurden, am 27. November dahingehend geäußert, er würde die Patches lieber in 4.16 sehen, wies aber auch gleich auf die Notwendigkeit der Portierung in die zurückliegenden LTS-Kernel 4.9 und 4.14 hin. Trotzdem flossen in 4.15-rc4 vorbereitende Patches ein, der Großteil wird, der gebotenen Sorgfalt bei solch tiefgreifenden Änderungen geschuldet,  erst mit 4.16 ausgeliefert.

    Künftig getrennte Page-Table-Bereiche

    Was steckt nun hinter dem ganzen geschäftigen Treiben? Die Kernel-Entwickler trennen damit strikt die Page Tables, die derzeit noch von Kernel- und User-Space gemeinsam genutzt werden, in zwei völlig getrennte Sätze auf. Damit wollen sie verhindern, dass ein unprivilegierter Prozess auf den Speicherbereich im Kernel-Space zugreifen kann. Nach bisherigem Erkenntnisstand kann ein Prozess eine Intel-CPU durch Ausnutzen der Sicherheitslücke dazu bringen, Speicherbereiche zu prefetchen und dann durch Aushebeln der Zugriffskontrolle direkten Zugriff auf den Kernel-Bereich zu erhalten. Zudem könnte auch der Sicherheitsmechanismus ASLR ausgehebelt werden. Die auslösenden Prozesse können von normalen Anwendungen wie Office-Anwendungen bis hin zum JavaScript in Web-Browsern stammen. Im schlimmsten Fall könnten manipulierte Anwendungen oder Anwender den Kernelspeicher auslesen, der alle möglichen Geheimnisse wie Passwörter und weitere Zugangsdaten enthalten kann. Stellt man sich das auf öffentlichen Cloud-Servern vor, wird das mögliche Ausmaß klar.

    Systemaufrufe bald langsamer

    Wenn eine Anwendung in eine Datei schreiben oder eine Netzwerkverbindung öffnen will, muss sie dazu vorübergehend die Kontrolle über den Prozessor an den Kernel abgeben. Um den Übergang vom User-Modus in den Kernel-Modus und zurück so schnell und effizient wie möglich zu gestalten, hat der Kernel Zugriff auf den  virtuellen Adressraum aller Prozesse, obwohl dieser für die Anwendung unsichtbar ist. Wenn der Kernel benötigt wird, führt das Programm einen Systemaufruf (syscall) durch, der Prozessor wechselt in den Kernel-Modus und hat Zugriff auf den Kernel. Wenn das erledigt ist, wird die CPU aufgefordert, in den Benutzermodus zurückzukehren und den Prozess erneut zu starten. Im Benutzermodus bleiben der Code und die Daten des Kernels für die Anwendung unsichtbar, ist aber in den Page Tables des Prozesses vorhanden.

    AMD vermutlich nicht betroffen

    Diese Sicherheitslücke ist in hohem Maße für virtuelle Maschinen und Container relevant, wo Bereiche mit Kernel-Techniken isoliert werden und ein Ausbrechen daraus kritisch sein kann. Nach Angaben des Kernel-Entwicklers Thomas Lendacky, der bei AMD beschäftigt ist, sind AMD-CPUs nicht betroffen. Er schreibt dazu auf LKML: » Die AMD-Mikroarchitektur erlaubt keine Speicherreferenzen, einschließlich spekulativer Verweise, die auf höher privilegierte Daten zugreifen, wenn sie in einem weniger privilegierten Modus ausgeführt werden, wenn der Zugriff zu einem Seitenfehler führen würde.«

    Mindestens 5 Prozent Strafe

    Also kann, wenn sich das bewahrheitet, für AMD-Prozessoren der KPTI-Patchset entfallen. Das könnte sich als Wettbewerbsvorteil herausstellen, da mit der Trennung der Page Tables ein anwendungsabhängiger Performance-Verlust von derzeit geschätzten mindestens fünf Prozent einhergeht. Diese Geschwindigkeitseinbußen entstehen dadurch, dass pro Syscall-Kontextwechsel ein TLB-Flush notwendig wäre. In Phasen ohne Syscall soll der TLB weiter wie gewohnt arbeiten. Modernere Intel-CPUs können dem TLB-Flush mit der PCID-Technik etwas entgegenwirken. Auf Phoronix gibt es erste Benchmarks dazu.

    Des Pudels Kern?

    Eines der Schlüsselwörter in der Aussage von Lendacky ist »spekulative Referenzen«. Bereits bei der Durchsicht der ursprünglichen KAISER-Patches von Sicherheitsforschern der Universität zu Graz stellte der Reviewer Anders Fogh in seinem Bericht fest: »Meine Ergebnisse zeigen, dass die spekulative Ausführung trotz Verstößen gegen die Isolation zwischen Kernel- und Benutzermodus tatsächlich weiter ausgeführt wird.« Hier könnte nach heutiger Erkenntnis der auslösende Fehler in Intels Silizium liegen.

    Intel schweigt

    Im Moment ist vieles an dieser Sicherheitslücke noch recht spekulativ, vor allem fehlen Informationen von Intel selbst. Klar ist, dass die Lücke besonders im Unternehmensumfeld ausgenutzt werden könnte. Große Cloud-Anbieter wie Amazon und Microsoft Azure haben bereits kurzfristig Wartungsmaßnahmen und Reboots angekündigt, ohne dabei jedoch ein mögliches Problem zu erwähnen.

    Klar scheint auch zu sein, dass der Patch erst beim Booten aktiviert wird und somit AMD-CPUs von dem Performance-Verlust nicht betroffen sein werden. Unklar ist noch, wie weit genau die Lücke bei Intel-CPUs zurückreicht. Bisher sieht es aber so aus, als seien mindestens alle Intel-CPUs der letzten zehn Jahre betroffen.