Intel - Hardwarebug

Weiß man wieso das FreeBSD Team hier wohl so spät informiert wurde? Das FreeBSD Projekt ist ja jetzt nicht dafür bekannt sowas verfrüht öffentlich zu machen (wie z.b. OpenBSD das gemacht hat).
 
Das FreeBSD Projekt ist ja jetzt nicht dafür bekannt sowas verfrüht öffentlich zu machen (wie z.b. OpenBSD das gemacht hat).
OpenBSD machte lediglich die Aussage, dass es dämlich ist auf einem Patch sitzen zu bleiben und sie bekommten die Zustimmung dafür KRACK "still" zu patchen, so rebellisch wie jeder tut wars nicht... Wenn der Zustimmer im Nachhinein einen Fehler in seiner Entscheidung sah, kann da keiner was zu


Zitat: https://www.krackattacks.com/#openbsd
Code:
Why did OpenBSD silently release a patch before the embargo?
OpenBSD announced an errata on 30 August 2017 that silently prevented our key reinstallation attacks. More specifically, patches were released for both OpenBSD 6.0 and OpenBSD 6.1.

We notified OpenBSD of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: “In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging”. Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.

Weiß man wieso das FreeBSD Team hier wohl so spät informiert wurde?
Intel besteht einfach aus #!§$%&%§$# :)

EDIT: Zitat von @medV2
 
Ich hoffe das gibt keinen Ärger, weil es dabei auch etwas von BSD abschweift. Bitte drückt ausnahmsweise mal ein Auge zu, vielleicht hilft es ja einigen BSDlern weiter, falls auch mal ein gekauftes Video Game auf Windows gespielt werden möchte.

Für FreeBSD gibt es ja leicht die Möglichkeit CPU Microcode Updates sobald verfügbar mittels des Ports sysutils/devcpu-data beim booten zu laden, wenn die Mainboardhersteller ihre BIOSe und UEFIs nicht aktuell halten, was wohl die Mehrheit betrifft. Auch auf Linux gibt es solch eine Möglichkeit.

Trickreich scheint aber bei Microsoft Windows nötig zu sein, da fand ich dies hier, wobei auf den VMware CPU Microcode Update Driver zurückgegriffen wird:
http://forum.notebookreview.com/threads/how-to-update-microcode-from-windows.787152/

Die ganz Harten spielen vielleicht sogar mit dem Gedanken, wie man die CPU Microcode Updates per DIY in das BIOS hinein bekommt, wenn der Mainboardhersteller sich nicht darum kümmert:
https://www.win-raid.com/f16-BIOS-Modding-Guides-and-Problems.html
 
wie ist denn dazu die Handhabung? Einmal devcpu-data einspielen und gut ist?

Bei jedem booten muss der CPU Microcode geladen werden, mit einem Eintrag in die /etc/rc.conf wird das dann automatisch gemacht beim booten:
Code:
#-------------------------------------------------------------------------------
# Intel® CPU microcode updates
# sysutils/devcpu-data
#-------------------------------------------------------------------------------
microcode_update_enable="YES"
Der sysutils/devcpu-data Port gibt aber auch eine entsprechende Meldung aus, lässt sich auch schon vorab mal anschauen:
Code:
cat /usr/ports/sysutils/devcpu-data/files/microcode_update.in
Code:
#!/bin/sh
#
# $FreeBSD: head/sysutils/devcpu-data/files/microcode_update.in 458169 2018-01-05 20:37:57Z sbruno $
#

# PROVIDE:      microcode_update
# REQUIRE:      root mountcritlocal
# KEYWORD:      nojail
# BEFORE:       SERVERS

#
# Add the following line to /etc/rc.conf to enable flow-capture:
# microcode_update_enable (bool):       Set it to "YES" to update microcode on startup
#                                       Set to "NO" by default.
# microcode_update_datadir (str):       Directory, microcode updates stored in.
#                                       Default is "%%DATADIR%%"
# microcode_update_cpus (str):          A list of cpus to update on startup, or "ALL" for all.
#                                       Example: microcode_update_cpus_cpus="0 CPU0"
#                                       Set to "ALL" by default.
# microcode_update_flags (str):         Flags for cpucontrol(8).

. /etc/rc.subr

name="microcode_update"
rcvar=microcode_update_enable
stop_cmd=":"
start_precmd="microcode_update_prepare"
start_cmd="microcode_update_start"
requires_modules="cpuctl"

CMT="/usr/sbin/cpucontrol"

microcode_update_prepare()
{
        if ! kldstat -q -m cpuctl; then
                if ! kldload cpuctl > /dev/null 2>&1; then
                        warn "Can't load cpuctl module."
                        return 1
                fi
        fi
}

microcode_update_start()
{
        echo "Updating cpucodes..."
        if [ "${microcode_cpus}" = "ALL" ]; then
                ncpu=`/sbin/sysctl -n hw.ncpu`
                cpus=`jot ${ncpu} 0`;
        else
                cpus=${microcode_cpus}
        fi
        for i in ${cpus}; do
                ${CMT} -u ${microcode_update_flags} \
                    -d "${microcode_update_datadir}" /dev/cpuctl${i} || \
                    (echo "Failed." && exit 1)
        done
        echo "Done."
}

load_rc_config $name

# Set default values
: ${microcode_update_enable="NO"}
: ${microcode_update_datadir="%%DATADIR%%"}
: ${microcode_cpus="ALL"}
: ${microcode_update_flags=""}

run_rc_command "$1"
 
Wobei ich mir noch gar nicht sicher bin, ob es wirklich sinnvoll ist jede sowieso verseuchte Windows-Kiste mit Microcode und komplizierten Kernelpatches gegen Specte abzusichern. Das haut einerseits noch mal richtig auf die Geschwindigkeit und andererseits ist der Angriff in den meisten Fällen doch eher theoretisch zu sehen. Für die breite Masse dürfte es wirklich ausreichend sein den Browser als das Einfallstor Nummer 1 abzusichern und alles andere optional zu lassen...
 
Intel sieht sich nicht in der Lage Spectre alleine durch Microcode zu fixen. Daher implementieren sie per Microcode-Update drei neue Funktionen in die CPU, die es erlauben Predictions zu verhindern und gecachte Predictions zu verwerfen. Simpel gesagt. Fun Fact am Rande: Bisher behauptete Intel immer, man könne keine Funktionalität per Microcode-Update nachrüsten und müsste neu kaufen...
 
Schöner Artikel mit Zitaten von Theo:
https://www.itwire.com/security/813...losure-incredibly-bad-openbsd-s-de-raadt.html

Hier der genialste Part:
Code:
"It is a scandal, and I want repaired processors for free. I don't care if they are 30% slower, as long as they work to spec. Intel has been exceedingly clever to mix Meltdown (speculative loads) with a separate issue (Spectre). This is pulling the wool over the public's eyes."

De Raadt found an analogy with the Volkswagen emission issue. "Some VW executives probably wish a problem with their brake controller software has been discovered at the same time," he quipped.
 
Ich würde sagen ja, denn:
  • JITs sind generell problematisch, da man sie vergleichsweise einfach dazu bringen kann Dinge zu tun, die sie nicht tun sollen. FreeBSDs BPF JIT dürfte relativ wenig Reviews bekommen haben, schon da FreeBSD eine Nische ist und dazu ist es noch ein optionales Feature. Außerdem läuft der JIT noch im Kernel Mode, also ist da generell offene Hose.
  • Die meisten CPUs sind nur deshalb gegen Meltdown immun, da sie Instruktionen schon beim Pipeline Entry auf Zulässigkeit prüfen und sofort verwerfen. Werden sie aus dem Kernelmode abgefeuert, gilt das nicht mehr. Die Instruktionen werden dann ausgeführt und Pech gehabt. Die Paper sagen explizit, dass Linux eBPF JIT für sowas missbraucht werden kann. FreeBSDs BPF JIT ist zwar eingeschränkter, aber mir würde das reichen um mich von dem Ding zu trennen.
Ich sehe in dem JIT kein Problem, weil ja man kann per JIT etwas nativen Code ausführen, aber nichts was nicht auch mit nem Interpreter geht und um den Seiteneffekt der spekulativen Ausführung auf einer korrekten CPU zu beobachten musst und du auch den Receiver deines Side Channels dort ausführen. Natürlich ist der JIT etwas mehr Komplexität und kann z.B. die gefährliche Instruction Sequence kurz genug bekommen um ins Instruction Window der CPU zu passen, aber schon nen alter PPC 970 konnte ca. 1000 in flight Instructions haben. Das reicht auch für nen Interpreter. Es wird also beim Lücken flicken bleiben bis die CPU Hersteller einsehen, das Multitenancy auf der amd64 Platform wichtig ist und sich entsprechend verhalten.
 
Nicht "schon wieder". Das ist erst das Update für Spectre für einige CPUs. Das Update vom 5.1. hat das Paket erst mal überhaupt auf den Stand von November letzten Jahres gebracht ;)
 
Gibt wohl schon Sammelklagen bei den Amerikanern, fand die Punkte recht interessant:
Klar, der Bug selbst, wissentlicher Verkauf von fehlerhaften Teilen und (der interessanteste Punkt) zu hohe Verzögerung bei der Bekanntmachung des Fehlers.

Ich könnte mir gut Vorstellen, dass der 3. Punkt bei einer Schuldzuweisung (Präzedenzfälle sei Dank) zu einer höheren Transparenz bei Hardwareherstellern folgen könnte.
 
Der Sourcecode der x11/nvdia-settings und x11/nvidia-xconfig in der Version 384.111 sind nun auch auf dem Github Nvidia Account verfügbar, so dass in den Makefiles USE_GITHUB=yes und GH_ACCOUNT=NVIDIA funktioniert.
 
Bei Sammelklagen muss man sich aber immer vor Augen führen, dass es dabei vor allem um das oft ungerechtfertigte Erpressen von Geld geht und nicht darum, dass real entstandener Schaden ersetzt oder sogar Aufklärung betrieben wird. Das läuft in den allermeisten Fällen so ab, dass windige Anwaltskanzleien mögliche Kläger suchen. Das passiert auch schon mal durch Zeitungsanzeigen, TV-Werbung und so weiter. Sie reichen dann Klage ein, die Gerichte koordinieren sich und am Ende wird es zu einer Klage zusammengefasst, die den Status einer Sammelklage erhält. Anschließend wird das Gericht entscheiden, ob die Klage zugelassen wird. An diesem Punkt wir es denn interessant. Denn eigentlich will niemand, dass diese Klage tatsächlich verhandelt wird. Das ist für alle beteiligten zeitraubend und teuer. Die Angeklagten möchten nicht über ihre Interna berichten müssen. Die Kläger möchten (und können) ihren Schaden nicht konkret belegen. Also wird das Gericht zu einem Vergleich drängen. Der sieht dann so aus, dass der Angeklagte den Betroffenen Summe X zahlt und die Betroffenen unterschreiben im Gegenzug eine Schweigeerklärung. Damit ist die Sache erledigt.
 
Dazu fällt mir ein: amerikanische Fastfoodkette, heißer Kaffee, fehlende Warnung auf dem Becher .... wurde sehr teuer:D
 
Dazu fällt mir ein: amerikanische Fastfoodkette, heißer Kaffee, fehlende Warnung auf dem Becher .... wurde sehr teuer:D
Es würde mich wundern, wenn es diesmal so käme.
Überall, wo ich in den letzten Tagen war, hat niemand sich aufgeregt oder gefragt, was man tun kann. Das ist eine deutlich geringere Reaktion, als beim letzten WanaCry. Vielleicht kapitulieren alle oder niemand hat das Potential dieses Lecks erkannt. Vielleicht auch, weil es ja keine bekannten Schäden gibt.
Intel ist nicht wirklich böse in dieser Angelegenheit, andere haben ja die gleichen Probleme. Es ist also ein Stand der Technik und nicht ein Versäumnis von Intel, was diesen Fehler begründet. Ich schätze mal, dass es da keine großartigen Klagen geben wird.
Ein wenig teurer wird es, die Produktion komplett umzustellen. Aber das wird nicht passieren, wie ich die Lage einschätze. Es wird ein Gebastel drum herum bleiben und alle werden damit zufrieden sein und damit leben. Wir haben ja auch kaum eine Wahl.
 
Dazu fällt mir ein: amerikanische Fastfoodkette, heißer Kaffee, fehlende Warnung auf dem Becher .... wurde sehr teuer:D
Generelle Warnung zu solchen unglaublichen Urteilen aus den USA. Ein verwandter (deutscher) Anwalt sagte, dass die meisten spektakulären Schadensersatzfälle, die hier so bekannt werden, erstinstanzliche Urteile sind... die später wieder aufgehoben werden.

Im Fall Liebeck v. McDonalds "weiß" ja jeder, dass der Frau Millionen zugesprochen wurden. Aber der Richter hat es später drastisch reduziert und letztlich hat sich McDonalds außergerichtlich mit ihr geeinigt, lt. Wikipedia für eine unbekannte Summe unterhalb 600.000 USD. Das ist immer noch viel, aber weit weg von dem, was hierzulande die meisten von der Geschichte zu wissen glauben.

Sorry für diesen OT-Beitrag. Ich hör schon wieder auf...

Andere Frage (nicht ganz ernst gemeint): Gibt es schon Berichte, dass Festplatten am Markt knapp werden? Ich würde erwarten, dass derzeit Geheimdienste, Firmen, Kriminelle en Masse Daten aus verwundbaren Systemen abziehen und irgendwo speichern wollen. Das muss doch ein gefundenes Fressen für NSA & Cyber-Mafia sein. Selbst wenn ich nicht direkt an die interessanten Server mit sensiblen Daten kommen sollte, kann ich doch nun vergleichsweise einfach Laptops etc. von hochrangigen Personen in Regierungen, Firmen, Forschungseinrichtungen übernehmen und darüber in die ansonsten geschützten Netzwerke gelangen... oder war das eh schon immer so einfach, dass es für die größten Daten-Spione ohnehin keinen Unterschied macht? Jetzt können halt auch irgendwelche Skriptkiddies einfach mitmischen?
 
Intel ist nicht wirklich böse in dieser Angelegenheit, andere haben ja die gleichen Probleme. Es ist also ein Stand der Technik und nicht ein Versäumnis von Intel, was diesen Fehler begründet. Ich schätze mal, dass es da keine großartigen Klagen geben wird.

Ich kann hierzu nur nochmals mein Zitat von Theo posten:
Some VW executives probably wish a problem with their brake controller software has been discovered at the same time
Spectre ist separat zu betrachten und sollte nicht mit Meltdown in einer Diskussion gemischt werden, denn Intel hat Mist gebaut (Meltdown) und zeitgleich noch einen Fehler (Spectre).

Es wird ein Gebastel drum herum bleiben und alle werden damit zufrieden sein und damit leben.
Die Patches sind reine Mitigation, keine Heilung des Problems, wir werden sicherlich noch öfter von Meltdown hören, vorallem im VM-Bereich
 
Zurück
Oben