Login
Newsletter
Werbung

Thema: OpenBSD deaktiviert Unterstützung für Hyper-Threading

17 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
4
Von kraileth am Do, 21. Juni 2018 um 09:34 #

Als ich von dieser Änderung auf Undeadly las war mein erster Gedanke: "Wie kaputt ist x86 eigentlich?". Es ist gut, daß OpenBSD hier ohne Rücksicht auf Verluste vorprescht und Sicherheitsmaßnahmen ergreift. Spätestens dann, wenn es die "Performance", die moderne heilige Kuh, berührt, werden die meisten Entwickler grantig (man erinnere sich daran, daß Beobachter zurecht Lunte rochen, als KPI in Linux eingeführt wurde, ohne daß Herr Torvalds die Macher wüst beschimpfte). Proaktiv auf HT zu verzichten ist ein ziemlich radikaler Schritt. Und wenn OpenBSD, das eine gewisse Abneigung gegen unnötige "knobs" hat, dafür ein Sysctl einführt, dann heißt das auch schon etwas.

Die Frage, die sich mir stellt ist: Nachdem Prozessorspekulation und angrenzende Bereiche jetzt verstärkt in den Fokus der Sicherheitsforscher rücken - was bleibt übrig von x86, wenn die Lücken so weit gestopft sind, daß die Plattform wieder mit einiger Zuversicht sicher betrieben werden kann? Sind wir dann mehr oder weniger wirklich wieder fast beim originalen Pentium (ohne "Pro"), nur mit höherer Taktfrequenz und zusätzlichen Instruktionen? Wo führt das hin und wo endet es? In einer Teilung "Langsam aber sicher" und "sauschnell aber nicht für sicherheitskritische Anwendungen"?

Ich wünschte, wir kämen von der totalen x86-Dominanz weg. Mein Traum wäre ein brauchbares und idealerweise bezahlbares RISC-V-System - aber auch ARM als Zwischenschritt bin ich nicht wirklich abgeneigt. Vielleicht schadet aber auch ein Blick in Richtung anderer Architekturen nicht. Gut, daß OpenBSD einige davon unterstützt (wenn auch nicht auf dem Niveau von x86).

[
| Versenden | Drucken ]
  • 1
    Von Anonymous am Do, 21. Juni 2018 um 12:31 #

    Ich glaube, dass das weitergehen wird wie bisher.

    Performance kann man einfach messen, Sicherheit nicht. Also werden alle weiter auf Performance setzen und Sicherheitslücken notdürftig flicken, soweit sie bekannt werden.

    Im bestehenden System wird so viel Geld bewegt und die Grossen der Branche sind so mächtig, dass da keiner raus kommt. Für die Kunden bleibt da nur "friss oder stirb".

    Sieht man ja an Intel. Die Kunden rennen nicht in Scharen weg (zu wem auch? Die Konkurrenz wäre ja mangels Kapazitäten gar nicht lieferfähig), sondern ordern sogar zusätzliche Server mit Intel-Hardware, wenn die Performance ihrer Systeme aufgrund der Patches sinkt.

    [
    | Versenden | Drucken ]
    • 1
      Von Antiquities am Fr, 22. Juni 2018 um 08:29 #

      BSD hat kaum noch kompetente Entwickler und die Gründergeneration hat längst das Rentenalter erreicht. Da die alles mögliche zum Anlass nehmen, um dieses oder jenes neumodische Feature nicht mehr zu unterstützen, um ihre wenigen Ressourcen zu schonen, liegt deshalb auf der Hand.

      [
      | Versenden | Drucken ]
      • 1
        Von kraileth am Fr, 22. Juni 2018 um 09:07 #

        Glückwunsch: Mein erstes Schmunzeln des Tages über einen mißlungenen Kommentar gehört Dir.

        Um aber der Legendenverbreitung vorzubeugen: Die Aussage „BSD is dying“ steht ziemlich genau auf der gleichen Stufe wie „dieses / nächstes Jahr wird das Jahr des Linux-Desktops“. Beides sind Prognosen von Leuten, die ihren Verstand in arg engen Wahrnehmungsräumen eingesperrt haben. Linux steht weiterhin nicht gerade eben davor, den Desktop zu dominieren (weil all die fraglos guten Argumente dafür in der Marktrealität nahezu völlig ins Leere laufen und andere Dinge zählen - so hirnrissig das auch sein mag) und *BSD ist quicklebendig.

        Ja, OpenBSD schaltet HT ab (übrigens aber nur „bis auf weiteres“). Und ja, OpenBSD hat auch die einmal vorhandene Linux-Emulation begraben und sogar die Unterstützung für nachladbare Kernelmodule entfernt (!). Ersteres, weil niemand ein Interesse an der Pflege hatte, letzteres aus Sicherheitsgründen. In beiden Fällen ist OpenBSD beeindruckend konsequent. Übrigens bringen sie eine Menge an Entwicklerzeit auf, um ihr System aufzuräumen, wo andere auf Pinguin-komm-raus! ganz überwiegend nur neue Funktionen einbauen (ja, das ist eine bewußt überspitzte Aussage). Sowohl FreeBSD als auch OpenBSD haben aber genügend Entwickler, um - z.B. - jeweils einen eigenen Hypervisor aus dem Boden zu stampfen: Bhyve / Vmm. Ersterer wird sogar als technisch so interessant eingeschätzt, daß die Leute von SmartOS/Illumos lieber Bhyve portieren, als die lange schon bei ihnen verwendete KVM von Linux weiterhin zu pflegen... ;)

        [
        | Versenden | Drucken ]
    1
    Von kamome umidori am Do, 21. Juni 2018 um 12:40 #

    Ich hoffe ebenfalls auf RISC-V und OpenPOWER & Co. Mal sehen, wann (ob?) wir ein System erhalten, das vom Prozessor bis zu (jeglichem) Speicher und allem drum herum Frei u/o Open ist … Software ohnehin!

    [
    | Versenden | Drucken ]
    • 1
      Von JoeHuns am Do, 21. Juni 2018 um 13:16 #

      RISC-V ist Fluch und Segen zugleich.
      Der Markt wird weiter fragmentiert weil jeder sein eigenes Süppchen kochen kann und wird.

      [
      | Versenden | Drucken ]
      • 1
        Von blablabla233 am Do, 21. Juni 2018 um 15:55 #

        Nicht wirklich...es gibt ein standard, ob du dann drauf noch was anderes packst ist egal, die compiler werden auf den kleinsten gemeinsamen Nenner gehen...wie heute bei intel/amd auch..

        [
        | Versenden | Drucken ]
        0
        Von schmidicom am Do, 21. Juni 2018 um 16:12 #

        SiFive Statement on Meltdown and Spectre

        Ich würde das mal so interpretieren das bei einem RISC-V, wenn überhaupt, wohl nur eigene und nicht die selben Spectre-Varianten wie beim x86 funktionieren würden.

        [
        | Versenden | Drucken ]
        • 1
          Von AAAber am Do, 21. Juni 2018 um 16:35 #

          Man muss aber dazu sagen, das ist Stand Januar mit dem ersten Set an Meltdown/Spectre-Lücken.
          Mittlerweile gibt es ja noch weitere bekannte Lücken ("Spectre NG") und es wird erwartet, das auch noch mehr davon nach und nach publiziert werden.

          Somit gilt ganz grundsätzlich, was der Kollege von SiFive korrekterweise vorausschickt:

          The vulnerabilities these attacks exploit are not limited to a particular instruction-set architecture, nor are they restricted to a single vendor’s implementations. Many processors that rely upon speculation to improve performance are affected, even some that do not use out-of-order execution.

          Der springende Punkt ist die spekulative Ausführung, die auch SiFive vermutlich in irgendeiner Form integriert hat, so wie ich den gesamten Post lese.
          Man sollte sich also nicht ZU sicher wähnen...

          Recht hat er allerdings auch damit:

          now is the time for open architecture and open hardware designs to shine. Researchers and implementers are already working to develop both architectural solutions and novel microarchitectures that are hardened against this form of attack.
          Das bietet zumindest eine gute Chance, hier was zu bewegen und Transparenz zu schaffen. Ich hoffe, die Chance wird genutzt.

          [
          | Versenden | Drucken ]
    2
    Von AAAber am Do, 21. Juni 2018 um 14:21 #

    Aber Spectre betrifft nicht nur x86!

    Spectre greift die spekulative Ausführung an und das haben ALLE Prozessoren der letzten 5-10 Jahre. Auch ARM und höchstwahrscheinlich auch RISC V (wobei ich letzteres nicht sicher weiß).
    Lediglich die konkrete Implementierung ist mal besser und mal schlechter - so war sie bei Intel scheinbar sehr unsicher, während AMD die spekulative Ausführung besser, sprich sicherer, implementiert hat.

    Sprich: Auch andere Architekturen sind nicht per se sicher! Es ist die spekulative Ausführung, die große Performance-Gewinne bringt und auch die Sicherheitslücken.

    [
    | Versenden | Drucken ]
    2
    Von noob am Do, 21. Juni 2018 um 17:48 #

    Du hast es schon richtig angesprochen:

    Auf keinen Fall mehr x86-CPU-Hardware kaufen, diese Architektur ist praktisch tot. Denn eine rund 20jährige komplette Fehlentwicklung kann man nicht in kurzer Zeit direkt in der CPU-Hardware "fixen". Es gibt aktuell nur CPUs, die ab Werk diese Hardware-Bugs besitzen. Intel-CPUs besitzen ab dem Pentium Pro (mit Ausnahme einiger alter Atom-CPUs) alle Hardware-Bugs, AMD-CPUs sind zwar angeblich nicht für Meltdown, wohl aber für einige Spectre-Varianten anfällig.

    Alternativ bieten sich ARM-Prozessoren an, die ohne diese Spekulation arbeiten (es gibt ja auch von den Hardware-Bugs betroffene ARM-CPUs) und nicht für Meltdown-, Spectre- oder Hyperthreading-Hardware-/Sicherheitslöcher anfällig sind.

    Alternativ kannst Du Dir ja ein P54C-System zusammenstellen (ich habe mir ein solches altes Socket7-System mit TX-Chipsatz und max. 256MB RAM testweise zusammengestellt; Debian 8 läuft mit Systemd problemlos darauf) und wichtige Dinge im Textmodus erledigen oder gleich einen ARM-Einplatinencomputer benutzen, der eine nicht für die Hardwarebugs anfällige ARM-CPU verwendet.

    Ein aktuelles Multi-Core-ARM-Notebook z.B. wäre auf diesem Hintergrund sehr zu begrüßen.

    Wenn man sämtliche CPU-Spekulation hardwareseitig im Kernel abschalten kann, dann schlage ich vor, uns Nutzern diese Möglichkeit an die Hand zu geben. Dann laufen halt notgedrungen z.B. Core i3-, Pentium- und Celeron-Dual Core-Varianten vermutlich allesamt auf dem gleich niedrigen Performance-Niveau.

    Zudem sollten die Distributionen angesichts der Hardwarebugs die Unterstützung für alte Prozessoren vor dem PentiumPro/Pentium II tunlichst nicht abschaffen (Debian hat mit Debian 9 Stretch ja diesen Fehler schon gemacht).

    Bitte nicht vergessen: Wir brauchen jetzt sichere Systeme, jetzt. Dann herzugehen und wissentlich hardwaredefekte Systeme zu kaufen, ist komplett hirnverbrannt. Diese Systeme sind schon weit vor 2023 nicht mehr in juristisch verantwortlicher Weise verwendbar (man denke nur an Servereinbrüche aufgrund von bereits bekannten Meltdown-, Spectre- oder Hypertreading-Bugs), da dann höchstwahrscheinlich bereits angeblich hardwarebugfreie x86-CPUs auf den Markt gekommen sein werden.

    [
    | Versenden | Drucken ]
    • 1
      Von Anonymous am Do, 21. Juni 2018 um 22:22 #

      Sorgen sollte man sich nicht wegen des/der eigenen popeligen Rechner(s) machen, sondern wegen der vielen Server, die man beim Browsen besucht oder auf denen persönliche Daten lagern (und letzteres betrifft bei weitem nicht nur die Nutzer von asazialen Netzwerken).

      Und die Server sind fest in der Hand von Intel.

      [
      | Versenden | Drucken ]
      • 2
        Von noob am Fr, 22. Juni 2018 um 07:46 #

        Das ist ein ähnliches Verhalten der "serverbetreibenden Firmen" gegenüber defekter und hardwarebugverseuchter x86-Hardware wie dasjenige von Staaten gegenüber der sog. Klimakatastrophe. Es wird erst dann etwas getan (werden), wenn das Kind bereits in den Brunnen gefallen ist und zwar in juristischem Sinne.

        Würde man diese Überlegungen bereits jetzt durchführen, so käme IMO dabei heraus, dass sich neue x86-Hardwareanschaffungen für Server, die in unsicheren Netzwerken wie dem Internet eingesetzt werden, strengstens verbieten, da man ja bereits weiß, dass die neue CPU-Hardware immer noch die bekannten, datensicherheitsgefährdenden Hardware-Bugs aufweist. Ein solches Tun klingt für mich recht fahrlässig, zumal auch jetzt schon bekannt ist (siehe eben diese Meldung), dass viele x86-CPU-Hardwarebugs noch geheimgehalten werden (u.a. im Sinne der Fristen von angeblich "responsible disclosure").

        Jedenfalls habe ich logischerweise keine Möglichkeit, die Sicherheit mir nicht gehörender Server auch nur irgendwie zu beeinflussen. Nur ziehe ich hieraus nicht die Konsequenz, mich um die Auswirkungen der Benutzung meiner eigenen Rechnersysteme nicht zu kümmern. Ich bin aktuell selbst recht ratlos und suche momentan nach Alternativen.

        U.U. ist es auch an der Zeit zu überprüfen, welchen Anbietern man die Nutzung und Verarbeitung privater sensitiver Daten wie z.B. des Geburtsdatums untersagen sollte, selbst wenn sich daraus ein "termination of service" ergibt.

        [
        | Versenden | Drucken ]
2
Von Celric am So, 24. Juni 2018 um 17:29 #

Der Hintergrund, warum OpenBSD hyper threading deaktiviert, ist hier gut dargestellt (Stichwort TLBleed):

https://www.theregister.co.uk/2018/06/22/intel_tlbleed_key_data_leak/

[
| Versenden | Drucken ]
  • 0
    Von noob am Di, 26. Juni 2018 um 11:44 #

    Oder z.B. hier auf Deutsch:
    https://www.heise.de/security/meldung/
    TLBleed-Luecke-verraet-geheime-Schluessel-4091114.html

    [
    | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung