Intel - Hardwarebug

Der Patch für FreeBSD ist vorhin in 12-CURRENT angekommen: https://svnweb.freebsd.org/changeset/base/328083

Wie die Commit Message schon sagt, muss PTI derzeit explizit in der /boot/loader.conf per 'vm.pmap.pti=1' eingeschaltet werden. Der Patch nutzt derzeit noch kein PCID, der Performance Hit dürfte daher schon recht groß sein. Das wird aber später noch eingefügt werden. Ich werde heute Abend ein wenig messen. Und MCE sind derzeit defekt, ein weiterer Patch für den Patch wird demnächst kommen.

Die Änderung wird nun 2 Wochen in 12-CURRENT abhängen, dann in 11-STABLE landen. Wahrscheinlich wird es zeitnah eine Errata für das 11.1-RELEASE geben. Mein letzter Stand war, dass man aufgrund des enormen Aufwands und hohen Risikos 10-STABLE, 10.3-RELEASE und 10.4-RELEASE nicht patchen wird, obwohl sie noch nicht EOL sind. Ich weiß nicht, ob das noch aktuell ist.

Und an diese Stelle auch noch mal vielen Dank an Konstantin Belousov und auch alle anderen, die ihren Anteil an diesem Patch haben. Die Änderung ist scheiße-kompliziert (sorry für die Wortwahl), hochriskant, gräbt unendlich tief im maschinenabhängigen Assembler-Teil des Kernels herum und so weiter. Das unter Zeitdruck zu entwickeln war sicher kein Spaß.
 
Yamagi schrieb:
Mein letzter Stand war, dass man aufgrund des enormen Aufwands und hohen Risikos 10-STABLE, 10.3-RELEASE und 10.4-RELEASE nicht patchen wird, obwohl sie noch nicht EOL sind. Ich weiß nicht, ob das noch aktuell ist.
Zum Vergrößern anklicken....

Es werden bekannte, ernste Sicherheitslücken in offiziell supporteten Branches nicht gefixt!? :eek: Also ich mecker ja sonst nicht (zumindest laut), aber was soll das denn bitte?
 
Ich weiß nicht, ob das nun wirklich stimmt. Aber den Patch zurückzuportieren und dann noch ausreichend Tester zu finden - es gibt schon große Unterschiede am VM zwischen 10.x und 11.x / 12 - dürfte schon sehr aufwändig sein. Daher verstehe ich wenn man sagt, dass man sich knappe 9 Monate vor'm endgültigen EOL die Arbeit spart.
 
Man darf auch nicht vergessen: Die Patches für Linux waren schon seit mehreren Monaten in Entwicklung. FreeBSD hatte jetzt... 4 Wochen? Man kann den Leuten echt keinen Vorwurf machen. Jeder sollte einfach auf FreeBSD 11 updaten und gut ist. Ich sehe auch keinen Grund das jetzt noch ewig weit zurück zu portieren.
 
-Nuke- schrieb:
Man darf auch nicht vergessen: Die Patches für Linux waren schon seit mehreren Monaten in Entwicklung. FreeBSD hatte jetzt... 4 Wochen? Man kann den Leuten echt keinen Vorwurf machen.
Zum Vergrößern anklicken....

Ich mache den Entwicklern persönlich auch keine Vorwürfe, aber es macht sich trotzdem schlecht für ein Unix, das mit Sicherheitsvorteilen gegenüber Linux wirbt, offiziell supportete Branches nicht zu pflegen.

-Nuke- schrieb:
Jeder sollte einfach auf FreeBSD 11 updaten und gut ist. Ich sehe auch keinen Grund das jetzt noch ewig weit zurück zu portieren.
Zum Vergrößern anklicken....

Mein Homeserver bleibt mit neuen Kerneln beim Starten hängen. Der Bug ist reportet, wird aber seit anderthalb Jahren nicht gefixt. Ich hatte mich darauf eingestellt den Server noch bis zum EOL von 10 zu nutzen und dann auf andere Hardware auszuweichen :grumble:

edit: ich weiß, hat nicht so viel mit den aktuellen Issues zu tun, aber (auch) wegen sowas gibt es Release-Zyklen. Und ja, ich bin auch der Meinung, dass es davon zu viele bei FreeBSD gibt, und dass man lieber wie bei Debian einen Release-Branch ganz lange pflegen sollte und dann einfach STABLE (oder STABLE und CURRENT) als Rolling-release mit binary updates anbieten sollte. Aber das ist ein anderes Thema :rolleyes:
 
h^2 schrieb:
Ich mache den Entwicklern persönlich auch keine Vorwürfe, aber es macht sich trotzdem schlecht für ein Unix, das mit Sicherheitsvorteilen gegenüber Linux wirbt, offiziell supportete Branches nicht zu pflegen.
Zum Vergrößern anklicken....

Tun sie das? Also ganz objektiv: FreeBSD ist alles, aber nicht sicherer als Linux. Dazu fehlen diverse Sicherheitsfeatures und eine Menge Code-Reviews.

h^2 schrieb:
Mein Homeserver bleibt mit neuen Kerneln beim Starten hängen. Der Bug ist reportet, wird aber seit anderthalb Jahren nicht gefixt. Ich hatte mich darauf eingestellt den Server noch bis zum EOL von 10 zu nutzen und dann auf andere Hardware auszuweichen :grumble:
Zum Vergrößern anklicken....

Wenn du keinen unbekannten/zweifelhaften Code auf deinem Homeserver ausführst, kannst du eh nicht angegriffen werden.
 
h^2 schrieb:
ich weiß, hat nicht so viel mit den aktuellen Issues zu tun, aber (auch) wegen sowas gibt es Release-Zyklen
Zum Vergrößern anklicken....
Man sollte dabei aber nicht vergessen, dass das 10.4-RELEASE nie geplant war. Der Branch sollte mit 10.3-RELEASE enden. Es ist zustandegekommen, da Teile der Community es explizit angefragt hatten und sich bereit erklärten, einen Großteil der mit einem Jahr weiterer Unterstützung einhergehenden Aufgaben zu übernehmen. Wenn das FreeBSD Projekt sagt, dass es keinen Patch bereitstellt (was ich nicht sicher weiß, ich hörte das nur im IRC), heißt es nicht zwingend, dass es nie einen Patch geben wird. Wenn eine Firma oder auch einzelne Nutzer ein Interesse daran haben, wird es sicher etwas geben. :)
 
Wie angedroht habe ich ein wenig gemessen. Vorweg noch mal zwei Dinge, die wir zwar weiter oben schon hatten, aber die hier trotzdem noch mal erwähnt werden sollen:
  • Der Patch implementiert Page Table Isolation. Mit ihm eingeschaltet liegen der Userland-Teil eines Prozesses und der eingemappte Kernelland-Teil nicht mehr in einem Page Trie, stattdessen sind es zwei getrennte Tries. Ein Sprung zwischen Userland und Kernelland ist daher nicht mehr direkt möglich. Das verteuert solche Sprünge sehr, in der Praxis sind dort vor allem Syscalls relevant. Wie groß der Performance Einfluss des Patches ist, hängt also hauptsächlich von der Anzahl Syscalls des jeweiligen Programmes ab.
  • FreeBSDs Patch ist (noch) eher rudimentär. Er nutzt keine Process Context Identifiers (PCID), wodurch bei jedem Wechsel des Page Trie ein Translation Lookaside Buffer (TLB) Flush notwendig wird. Die sind sehr teuer. Es ist zu erwarten, dass der Performance Einfluss deutlich geringer wird, wenn PCID genutzt wird. Aber Intel hat andererseits auf seiner Reise zu effizienterer Virtualisierung Dinge wie TLB Flushs in den letzten Jahren mit jeder Generation billiger gemacht. Daher ist der Performance Einfluss auf neueren CPUs deutlich geringer als auf älteren. Mein Skylake ist da auf der Sonnenseite des Lebens.
Außerdem sind meine Messungen so schlecht, dass Statistiker heulend vor die Tür laufen würde. Ich habe in einer Virtuellen Maschine gemessen und jeweils nur einen Lauf. Damit es einigermaßen korrekt wäre, müsste man zumindest ohne virtuelle Maschine außen herum und mehrmals messen... Die Zahlen geben also eine Dimension an, in der sich der Performace Einfluss des Patchs bewegt, mehr aber nicht.

Das System war eine Bhvye-VM mit 4 Kernen und 4 GB RAM auf meinem Core i7-6700k mit insgesamt 32 GB RAM. Die VM lief auf einer S-ATA III SSD, das Hostsystem war komplett idle. Getestet habe ich 12.0-CURRENT r328089, der Kernel war ohne Debug-Optionen gebaut.

Code: 
'time make -j6 -DWITH_META_MODE buildworld buildkernel' der r328089 Sourcen auf leerem /usr/obj.

# Ohne PTI:
21862.691u 924.705s 1:37:12.41 390.7%  54609+3477k 147598+148818io 66590pf+0w

# Mit PTI
22541.998u 1144.344s 1:41:06.41 390.4%  54517+3472k 148200+139324io 66911pf+0w

=> 3,86% langsamer

Code: 
'time make -j6 -DWITH_META_MODE buildworld buildkernel' der r328089 Sourcen auf gefülltem /usr/obj.
Dies baut nichts neu, feuert nur jede Menge Syscalls auf die Source- und Object-Dateien ab.

# Ohne PTI
182.007u 70.617s 1:31.65 275.6% 3806+2669k 136114+4308io 54397pf+0w

# Mit PTI
8.654u 85.500s 1:39.88 274.4% 3790+2614k 136610+4466io 54761pf+0w

=> 8,09% langsamer

Code: 
'rm -Rf /usr/obj' auf das gefüllte /usr/obj. Es war ein UFS-Dateisystem, die unlink() Syscalls kehren
also (meist) sofort zurück und warten nicht auf das Dateisystem oder die SSD.

# Ohne PTI
0.139u 5.759s 0:07.91 74.3%  9+170k 248+4989io 0pf+0w

# Mit PTI
0.159u 6.286s 0:08.25 77.9%  10+175k 251+4989io 0pf+0w

=> 4,13% langsamer

Und wenn ich gerade dabei bin mich aufzuregen: Es ist zum Kotzen, dass Clang mit jeder neuen Version gefühlt doppelt so fett wird. Den seit einigen Tagen mit 12-CURRENT ausgelieferten LLVM und Clang 6.0.0 zu bauen, macht einfach keinen Spaß mehr. Noch zwei Versionen und das Ding entwickelt Gravitation.
 
Ich frag mich immer noch, ob die ganzen Fehler nur auftreten, wenn das OS die von Intel damit bereitgestellten Features benutzt. Also Windows und ein paar Non-Standard Linux-Distributionen. Weil weder FreeBSD noch Mainline Linux benutzen die hinzugekommenen Features. FreeBSD hat dafür nämlich noch gar keinen Schutz und Mainline Linux benutzt Retpoline, was unabhängig vom Microcode-Update funktioniert.
 
Ich zitiere Linux Torvalds,

"Diese Patches sind absoluter Müll", stellte er fest. "Sie machen buchstäblich wahnsinnige Dinge. Dinge, die keinen Sinn machen."

Die Kernschmelze scheint außer Kontrolle zu geraten.
 
ralli schrieb:
Die Kernschmelze scheint außer Kontrolle zu geraten.
Zum Vergrößern anklicken....
Nein, weil Linus da etwas missverstanden hat bzw. eher Missfallen gegenüber der Politik von Intel ausdrückt, als rein technisch zu bleiben . Es zahlt sich aus, auch den restlichen Thread (z.B. das) zu lesen und nicht einfach die Phrase zu kopieren und wiederzukäuen, die Schlagzeilen macht. :rolleyes:
 
.not schrieb:
Nein, weil Linus da etwas missverstanden hat bzw. eher Missfallen gegenüber der Politik von Intel ausdrückt, als rein technisch zu bleiben .
Zum Vergrößern anklicken....

Es geht wohl auch wirklich hauptsächlich darum, dass Intel wohl nicht plant in Zukunft das Spectre V2 Problem in Hardware zu fixen (in der Art wie es bei AMD der Fall ist), sondern es bei den entsprechenden Workarounds bleibt.
 
Achtung, OT.

.not schrieb:
Es zahlt sich aus, auch den restlichen Thread (z.B. das) zu lesen und nicht einfach die Phrase zu kopieren und wiederzukäuen, die Schlagzeilen macht.
Zum Vergrößern anklicken....
Du sprichst mir damit aus dem Herzen. Ich finde es zunehmend befremdlich, dass die Heise-Redaktion offenbar von Fefe "abschreibt" und dann auch noch die nötige Medienkompetenz vermissen lässt.

Rob
 
Ich habe mich bei heise schon daran gewöhnt, dass die es mit journalistischer Sorgfalt nicht so ernst nehmen.
 
FreeBSD 12-CURRENT optimiert PTI nun per PCID: https://svnweb.freebsd.org/changeset/base/328470 Das sollte den Performance-Einfluss stark senken. Ich kann gerne noch mal messen, allerdings wird das vor morgen Abend eher nichts werden. Die Revision hat ein recht langes MFC-Intervall von 3 Wochen. Ob sie per Errata in die RELEASEs gepatcht wird, weiß ich nicht.

Code: 
Author: kib
Date: Sat Jan 27 11:49:37 2018
New Revision: 328470
URL: https://svnweb.freebsd.org/changeset/base/328470

Log:
  Use PCID to optimize PTI.
 
  Use PCID to avoid complete TLB shootdown when switching between user
  and kernel mode with PTI enabled.
 
  I use the model close to what I read about KAISER, user-mode PCID has
  1:1 correspondence to the kernel-mode PCID, by setting bit 11 in PCID.
  Full kernel-mode TLB shootdown is performed on context switches, since
  KVA TLB invalidation only works in the current pmap. User-mode part of
  TLB is flushed on the pmap activations as well.
 
  Similarly, IPI TLB shootdowns must handle both kernel and user address
  spaces for each address.  Note that machines which implement PCID but
  do not have INVPCID instructions, cause the usual complications in the
  IPI handlers, due to the need to switch to the target PCID temporary.
  This is racy, but because for PCID/no-INVPCID we disable the
  interrupts in pmap_activate_sw(), IPI handler cannot see inconsistent
  state of CPU PCID vs PCPU pmap/kcr3/ucr3 pointers.
 
  On the other hand, on kernel/user switches, CR3_PCID_SAVE bit is set
  and we do not clear TLB.
 
  I can imagine alternative use of PCID, where there is only one PCID
  allocated for the kernel pmap. Then, there is no need to shootdown
  kernel TLB entries on context switch. But copyout(3) would need to
  either use method similar to proc_rwmem() to access the userspace
  data, or (in reverse) provide a temporal mapping for the kernel buffer
  into user mode PCID and use trampoline for copy.
 
  Reviewed by:   markj (previous version)
  Tested by:   pho
  Discussed with:   alc (some aspects)
  Sponsored by:   The FreeBSD Foundation
  MFC after:   3 weeks
  Differential revision:   https://reviews.freebsd.org/D13985
[/code9
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben