Intel - Hardwarebug

Vermutlich müssen die BSDs ebenfalls Kernel Page Isolation im Stil von Linux und Windows implementieren. Ansonsten kann man ja nicht viel dagegen tun. Da es aber im Zusammenhang mit (K)ASLR erwähnt wird, weiß ich nicht inwieweit das dann z.B. in FreeBSD möglich ist, da dort kein (K)ASLR in der Form enthalten ist.

Dann werden halt in 2018 alle (sicheren) Intel Server demnächst etwas langsamer. Aber zumindest unter Linux hat AMD noch keine Ausnahme erhalten. Kernel 4.14.11 bremst auch AMD-CPUs.
 
mogbo schrieb:
Hab die Mailinglisten nicht im Blick, gibts dazu schon was aus der *BSD-Welt?
Zum Vergrößern anklicken....
Hier: https://lists.freebsd.org/pipermail/freebsd-current/2018-January/068021.html

Weiter unten in dem Thread sagt Warner Losh dann auch:
Warner Losh schrieb:
The register article says the specifics are under embargo still. That would
make it hard for anybody working with Intel to comment publicly on the flaw
and any mitigations that may be underway. It would be unwise to assume that
all the details are out until the embargo lifts.
Zum Vergrößern anklicken....

Davon mal abgesehen sind 5% bis 30% Performance Hit hart. Da werden sich viele Nutzer 3x überlegen, ob sie den Work Around aktivieren oder nicht doch lieber mit dem Risiko leben.
 
Yamagi schrieb:
Davon mal abgesehen sind 5% bis 30% Performance Hit hart. Da werden sich viele Nutzer 3x überlegen, ob sie den Work Around aktivieren oder nicht doch lieber mit dem Risiko leben.
Zum Vergrößern anklicken....
Verstehe die Angabe nicht wirklich, spricht das dann für einen Leistungsverlust von 5-30 % der gesamten CPU oder erhöht sich die Rechendauer der CPU um 5-30 %.

Mit einem Gesamtleistungsverlust, der sich nicht auf die Dauer auswirkt könnte ich leben, jedoch mit einer höheren Rechenzeit von über 10 % könnte selbst ich als Privatperson an gewissen Ecken nicht leben.
 
Yamagi schrieb:
Da werden sich viele Nutzer 3x überlegen, ob sie den Work Around aktivieren oder nicht doch lieber mit dem Risiko leben.
Zum Vergrößern anklicken....

Im Linux-Fall muss man den Work-Around deaktivieren, da er standardmäßig eingeschaltet wird.

mogbo schrieb:
Verstehe die Angabe nicht wirklich, spricht das dann für einen Leistungsverlust von 5-30 % der gesamten CPU oder erhöht sich die Rechendauer der CPU um 5-30 %.
Mit einem Gesamtleistungsverlust, der sich nicht auf die Dauer auswirkt könnte ich leben, jedoch mit einer höheren Rechenzeit von über 10 % könnte selbst ich als Privatperson an gewissen Ecken nicht leben.
Zum Vergrößern anklicken....

Anders ausgedrückt: Du verlierst 5-30% Leistung je nachdem was du tust. Die Angabe von den Linux-Kernel-Entwicklern ist "5% im Normalfall". In Micro-Benchmarks bis zu 50%, aber das sind halt Micro-Benchmarks.
 
So wie ich es verstehe wird jeder Sprung zwischen dem Userland und dem Kernel teurer, da ein Mapping eingefügt wird, um den Userland-Teil und den Kernel-Teil des Adressraums eines Prozesses komplett zu trennen. Das würde bedeuten, dass Syscalls und (Hardware) Interrupts teuerer werden. Wie sehr es ein Programm trifft hängt davon ab, wie viele Syscalls es nutzt. Grundsätzlich ist unixoide Software aber sehr syscalllastig, da fast alle durch das Betriebssystem bereitgestellte Funktionalität letztendlich durch Syscalls implementiert wird. Solange ein Programm nur rechnet, dürfte der Performanceverlust also eher gering sein. Sobald es aber zu Dingen wie IO kommt, dürfte der Performanceverlust relativ groß sein.

Letztendlich hat AMD den Bug sozusagen geleakt, weil die Linux-Entwickler das für den Work Around genutzte "Kernel page-table isolation" (ehemals "KAISER") mit der Gießkanne für alle x86-CPUs aktiviert haben. Daraufhin hat AMD einen Patch eingericht, der es auf Intel-CPUs beschränkt und sehr deutlich darauf hingewiesen, dass man doch bitte nicht gar nicht betroffene CPUs verkrüppeln möchte. Das war schon eine recht deutliche Reaktion, die stark dafür spricht, dass die Auswirkungen nennenswert sind. Abschalten kann man es übrigens, indem man dem Linux-Kernel die Option "nopti" übergibt.

Genau wissen wir es aber alles erst, wenn das Embargo gefallen ist. Dann kann man sicher auch besser einschätzen, wie groß das Risiko ist und eine fundierte Entscheidung treffen.

EDIT: Missverständliche Formulierung geändert
 
PCID gibt's ja ab Westmere, also dürfte der Performance Hit sich dann in der Praxis doch in Grenzen halten.
 
mogbo schrieb:
Moin,
Intel hat wohl einen Prozessor-Bug, welcher es unpriviligierten Nutzern ermöglicht im Speicher rumzuspielen:

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/

Hab die Mailinglisten nicht im Blick, gibts dazu schon was aus der *BSD-Welt?
Zum Vergrößern anklicken....

Noch nicht. Soweit ich gelesen habe, sind Details der Sicherheitslücke sind noch nicht veröffentlicht worden und werden unter Verschluss gehalten. Nur ein ausgewählter Kreis hat Zugang dazu. Dazu gehören die BSD's meines Wissens nach nicht. Korrigiert mich bitte, wenn ich falsch liege.
 
midnight schrieb:
Dazu gehören die BSD's meines Wissens nach nicht. Korrigiert mich bitte, wenn ich falsch liege.
Zum Vergrößern anklicken....
Theo ist ja dafür bekannt Patches nicht zurückzuhalten und OpenBSD ist bekannt für schnelle Reaktionen auf Security-Probs. Denke sowas spricht schon alleine gegen die Infoweitergabe an OpenBSD.

kA wies bei anderen *BSDs aussieht
 
Nachdem die OpenBSD'ler die Embargo-Deadline für KRACK nicht eingehalten haben, werden sie vermutlich solche Infos nun später erhalten, wenn die anderen großen Häuser 'genügend' Zeit für ihre Patches hatten. Das war Theo und den anderen auch durchaus bewusst.

Dass FreeBSD aber nicht frühzeitig einbezogen wird, kann ich mir kaum vorstellen. Intel ist gerade zu einem großen Sponsor der Foundation geworden und präsentiert sich als Freund von FreeBSD. Und mit einem Schwergewicht wie Netflix (was waren es: zu Stoßzeiten angeblich über 1/3 des Internet-Traffics in den USA) schiene es törricht, FreeBSD außen vorzulassen (jaja, Netflix macht auch ganz viel über AWS = Linux).

Ich würde jedenfalls tippen, dass FreeBSD mit der Veröffentlichung der Details auch Patches bereit haben wird.
 
Unabhängig davon, ob FreeBSD Patches haben wird oder nicht, könnte dieser Bug aber wieder neuen Wind in die inzwischen sehr verhärtete Diskussion um (K)ASLR in FreeBSD bringen. Und das ist dann sogar ein positiver Nebeneffekt. :)
 
Ich weiß es nicht genau, da ich mich nicht im Detail mit KARL beschäftigt habe, aber es könnte gute mit FreeBSDs Policy stabile APIs anzubieten inkompatibel sein.
 
Yamagi schrieb:
Ich weiß es nicht genau, da ich mich nicht im Detail mit KARL beschäftigt habe, aber es könnte gute mit FreeBSDs Policy stabile APIs anzubieten inkompatibel sein.
Zum Vergrößern anklicken....
KARL heißt der Kernel liegt in einer Randomanordnung immer an der gleichen Position im Speicher (macht wohl der Linker irgendwie)
(K)ASLR heißt der gleiche Kernel liegt an einer Randomposition
Kombination scheint mittlerweile ganz gut machbar

Liegt eventuell auch daran, dass man ein System mit KARL leichter zu einem vollständigen Systemcrash bringen kann (ROB Attacks), was einen Neustart mit neuem Kernel zur Folge hat (gutes Sicherheitskonzept, kann aber in der Praxis sehr schädlich sein)

(K)ASLR scheint wohl nicht so schwer auszuhebeln zu sein, aber definitiv besser als ohne und ein Schritt in die richtige Richtung

Ob das zu instabilen APIs führt entzieht sich völlig meinem Halbwissen :)
 
Die hier angesprochenen Performanceverluste scheinen eher hochspekulativ zu sein, sie werden von Intel vehement bestritten.
 
Die Quelle ist ein Zitat aus einem gesperrten Forum ohne Quellangabe, also man kanns glauben oder nicht:

"Raw numbers are hard to find due to the secretive nature of these patches, but here are some basic benchmark impacts we've seen so far:

Linux, on an i7 6700, calling the getpid syscall 100,000,000 times:

Before the patch: ~3.8 seconds.
After the patch: ~15 seconds.
PostgreSQL, a database application, i7-6820HQ, SELECT 1 benchmark:

Before the patch: 420490.162391 transactions per second
After the patch: 350746.065039 transactions per second"

Intel geht wohl in Richtung:
https://i.imgur.com/Ed2jtn2.jpg
 
Die Details finden sich her: https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html

Das ist schon sehr übel. Meltdown ist sicher deutlich akuter als Spectre, Spectre und Abwandlungen haben aber das Potential noch auf Jahre eine Dauerkatastrophe darzustellen. Ich könnte mir gut vorstellen, dass man in 20 Jahren zurückschaut und sagt, dass der 04. Januar 2018 für die IT-Branche das war, was der 26. April 1986 für die Nuklearindustrie war.

Und Intel. Was sollen sie denn machen außer sich rausreden? Ihr offizielles Statement liest sich, als ob daran 30 Anwälte einen ganz Tag lang formuliert haben. Grundsätzlich zugeben, dass es ein Problem gibt, gefolgt von einer ganzen Reihe Relativierungen und Beschwichtigungen. Meltdown hat das Potential für Intel sehr, sehr teuer bis sogar existenzbedrohend zu werden. De facto alle Intel-CPUs werden durch das nun notwendige Mapping zwischen Kernel- und Userspace drastisch langsamer werden, sowas ist in den USA milliardenschwere Class Action Lawsuits wert. Großabnehmer wie Amazon oder Google werden sich das ebenfalls kaum gefallen lassen und es zum Anlass nehmen hohe Rabatte zu verlangen. Dazu kommt der Image-Schaden, der schnell gigantisch werden kann.

Natürlich ist es unfair. CPUs sind hochkomplex, es hätte jeden anderen Hersteller in dem Maß wie Intel treffen können. Und wird es vielleicht noch. Aber das Leben ist nun mal nicht fair und genauso wie VW die Arschkarte in Sachen Diesel gezogen hat, hat Intel es für löchrige CPUs getan.
 
mogbo schrieb:
KARL heißt der Kernel liegt in einer Randomanordnung immer an der gleichen Position im Speicher (macht wohl der Linker irgendwie)
(K)ASLR heißt der gleiche Kernel liegt an einer Randomposition
Zum Vergrößern anklicken....

Das wurde in OpenBSD ja inzwischen recht ausgiebig ausprobiert. Wie so oft. :)

Yamagi schrieb:
CPUs sind hochkomplex, es hätte jeden anderen Hersteller in dem Maß wie Intel treffen können.
Zum Vergrößern anklicken....

Plot Twist: Von wenigstens Teilen von Meltdown/Spectre sind nach jetzigem Stand Prozessoren von AMD und Intel ebenso betroffen wie ARM und POWER, außerdem wohl auch SPARC (letztere allerdings, wenn ich das richtig verstehe, "nur" Spectre, nicht Meltdown).

Nicht betroffen: VAX. :D
 
Ok, ich habe ja nicht abgestritten, das es ein Problem ist, dessen Ausmaß möglicherweise noch nicht vollumfänglich überblickt werden kann. Auch ist unstrittig, das es Leistungseinbußen geben wird. Ob das aber bis zu 35% sein dürften oder können, werden belastbare Benchmarks ergeben. Und das Großkonzerne gerne beschwichtigen und abwiegeln, dürfte auch der Normalfall sein. Erst wenn sie juristisch in die Enge getrieben werden und der Druck im Kessel zu hoch wird, wird man zu Zugeständnissen mit möglicherweise zweifelhaften Kompromissen bereit sein. Wie gut, das wir nicht alle Fehler kennen ..... wenn ich technisch versierter wäre, stände mir vielleicht auch der Angstschweiß auf der Stirne.;)
 
In meinem Rechner ist dieser Intel i7 4790k 4x4 GHz verbaut, ist der auch betroffen? Ich habe gegoogelt, aber nichts gefunden.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben