Login
Login-Name Passwort


 
Newsletter
Werbung

Thema: Linux-Kernel 4.16 freigegeben

14 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von Anonymous am Mo, 2. April 2018 um 14:48 #

Im (ausführlicheren) Artikel der c't zum neuen Kernel habe ich einen interessanten Hinweis gefunden:

Der Meltdown-Schutz für 32-bit-Kernel wird wohl noch einige Zeit auf sich warten lassen.

Ich war bisher bei 32bit-Linuxen verblieben, weil meine Kisten max. 4GB RAM haben und ich gelegentlich einige 32bit-Windows-Programme unter Linux ausführen möchte. Da hat es sich eigentlich nicht gelohnt, auf 64bit umzusteigen - ich habe aber inzwischen notgedrungen wegen MeltDown umgestellt.

Der c't-Artikel erwähnt jedoch, dass man durchaus einen 64bit-Kernel in einem reinen 32bit-System verwenden kann. Im Detail mag es Probleme geben, zumindest auf den ersten Blick läuft aber alles (Slackware 14.2 - unter Distributionen, deren Paketmanager eine Abhängigkeitsprüfung durchführen, wird man basteln müssen, um ihnen einen 64bit-Kernel unterzuschieben).

Dass man ein 32bit-Subsystem unter einem 64bit-System installieren kann, um z.B. 32bit-Windows-Programme unter einem 32bit-Wine auszuführen , ist ja bekannt und trivial. Mir jedenfalls war jedoch nicht bekannt, dass ein 64-bit-Kernel ein reines 32bit-System starten kann.

64-bit-Kernel oder kernelnahe Software lassen sich selbstverständlich nicht auf dem System kompilieren, und ich bin gespannt, an welchen Stellen es noch krachen wird.

  • 1
    Von Nonymous am Mo, 2. April 2018 um 23:30 #

    Wird nicht krachen. Das funktionierte schon immer.

    Hatte früher ne Zeit lang Lolbuntu 6.06 genau so laufen.

    1
    Von Verfluchtnochmal am Di, 3. April 2018 um 03:31 #

    Dem Kernel ist das doch naturgemäß völlig wurscht weil er ganz oben in der Nahrungskette läuft und alles andere auf ihm aufsetzt

    Ich frage mich nur was all das Geschiss soll

    x86_64 hat einen Haufen andere Vorteile wie zB dass SSE mandatory ist und damit viele Software schneller läuft während ix86 bei so gut wie allen Distributionen immer noch von Hardware aus dem letzten Jahrtausend ausgeht

    Sorry, aber noch nichtmal auf einer VM mit unter 1 GB RAM kommt mir seit mehr als 10 Jahren auch nur das kleinste 32bit Binary drauf

    ix86 ist tot und weiss es nur noch nicht

    • 0
      Von Anonymous am Di, 3. April 2018 um 10:57 #

      Ich frage mich nur was all das Geschiss soll

      Unter Slackware ist es vergleichsweise umständlich, auf einem 64bit-System ein 32bit-Subsystem einzurichten und aktuell zu halten, darum habe ich es möglichst lange rausgezögert.

      Nich jeder braucht möglichst viel Geschwindigkeit und RAM. Warum soll man mit dem SUV Brötchen holen, wenn es auch ein Fahrrad tut?

      • 0
        Von Verfluchtnochmal am Di, 3. April 2018 um 11:47 #

        Ähm hat Slackware keine Paketverwaltung? "yum install wine.i686" auf einem Redhat zieht dir alles was gebraucht wird und fertig

        Der SUV/Fahrradvergleich ist selten dämlich, es gibt keinen rationalen Grund nach 2007 noch ein 32bit System aufzusetzen und egal ist es nur wenn man alle paar Jahre neu installiert - Bei mir haben alle Systeme Redundanz und sterben nicht weg, ergo ist umsiedeln auf neue Hardware eine non-hostonly initrd zu bauen, runter fahren, Platten raus und in den neuen Rechner, einschalten, MAC-Adresse der internen NIC anpassen, durchstarten und fertig ist der Lack

    0
    Von Anonymous am Di, 3. April 2018 um 09:34 #

    64-Bit Systeme haben doch schon immer Unterstützung für 32-Bit Anwendungen. Wenn du ab und an mal eine 32-Bit Anwendung brauchst, muss doch nicht das ganze System 32-Bit sein.

    Auch wenn man 4GB RAM hat, haben 64-Bit Systeme deutliche Vorteile. Das wurde doch schon so oft erwähnt, als die entsprechenden CPUs rauskamen. Von deinen 4GB kannst du unter 32-Bit z.B. nur etwas mehr als 3GB nutzen.

    • 0
      Von ,.- am Di, 3. April 2018 um 18:50 #

      IMO liegt das Problem etwas verzwickter und ändert im Grunde an der 32bit-Patchproblemstellung für Meltdown und Spectre nichts. Wenn man 32bit-Anwendungen unter 64bit benutzt, kann sich hier auch das 32bit-Meltdown- und Spectre-Problem auswirken, z.B. wenn man eben 32bit-Windows- oder 32bit-Linux-Software unter einem 64bit-Linux ausführt.

    0
    Von ,.- am Di, 3. April 2018 um 18:42 #

    Ich betreibe z.B. unter Debian Wheezy 32bit einen 64bit-Kernel, Probleme habe ich bis dato noch nicht festgestellt (Wheezy ist zum Glück multiarch-fähig). Diese 32bit-Installation stammt aus einer Zeit (so um die Squeeze-Veröffentlichung), in der die meisten Distros noch standardmäßig 32bit-Images zur Installation anboten.

    Im Prinzip müsste ich "nur" das 32bit-Userland auf 64bit upgraden können.

    Es ist IMO symptomatisch, dass das Gros der Arbeit am Meltdownschutz für 32bit von einem Mitarbeiter von Opensuse-/Suse stammt, obgleich Opensuse 32bit im Prinzip "aussortiert" hat (außer in Tumbleweed). Hätte Torvalds nicht jüngst gesagt, dass die 32bit-Unterstützung noch 5 bis 10 Jahre beibehalten werden muss, wäre die 32bit-Architektur mit Meltdown/Spectre vielleicht schon aufgegeben worden.

    Zudem ist das Ausmaß der Ausnutzung von Meltdown unter 32bit nachwievor vollkommen unklar. U.U. schützt der übliche 1/3GB-Split zwischen Kernel und Userland schon ausreichend gegen Meltdown? Die noch nicht vollständigen Spectre-Schutzmaßnahmen für 64bit funktionieren hingegen auch bereits jetzt unter 32bit.

0
Von pointer am Di, 3. April 2018 um 13:53 #

Gute Zusammenfassung, danke.

Hier noch zwei Ergänzungen:

1) Für's Kompilieren des Kernels braucht man neben Flex und Bison auch die Developer-Version von libelf, sonst erhält man folgende Meldung:

"Cannot use CONFIG_STACK_VALIDATION, please install libelf-dev, libelf-devel or elfutils-libelf-devel"

Die verschieden Bezeichnungen meinen die gleiche Datei. Diese Bibliothek sollte von der jeweiligen Distribution erhältlich sein. Alternativ kann man sich die elfutils auch selbst besorgen, kompilieren und inkl. der header-Dateien installieren.

2) Hibernate (s2disk/s2both) sollte jetzt auch dann zuverlässig funktionieren, wenn VirtualBox- oder VMWare-VMs laufen bzw. geladen sind. Ausreichend Speicher (RAM/swap) natürlich vorausgesetzt.

Pro-Linux
Unterstützer werden
Neue Nachrichten
Werbung