Intel microcode

[Wolfgang Bauer]

Servus.

Ich habe mir von

https://downloadcenter.intel.com/download/27591/Linux-Processor-Microcode-Data-File

microcode-20180807.tgz geholt und entpackt. Entpackt daraus
Loading Image...
In der Anleitung steht (übersetzt)

Um das Intel-Code-Paket auf dem System zu aktualisieren, braucht man:
1. Stellen Sie sicher, dass /sys/devices/system/cpu/microcode/reload vorhanden ist

ist vorhanden.

2. Kopieren Sie das Verzeichnis intel-ucode nach
/lib/firmware, überschreiben Sie die Dateien in /lib/Firmware/Intel-Code/

habe ich gemacht.

3. Schreiben Sie die Reload-Schnittstelle auf 1, um die Mikrocodedateien erneut zu laden, z.
echo 1>/sys/devices/system/cpu/microcode/reload

***@Desktop-PC:/home/wolfgang# echo 1>/sys/devices/system/cpu/microcode/reload
bash: echo: Schreibfehler: Das Argument ist ungültig.

Der Befehl ist wohl falsch. Wie müßte es richtig heißen?

KDE neon 64 bit

Wolfgang

[Helmut Waitzmann]

Post by Wolfgang Bauer
3. Schreiben Sie die Reload-Schnittstelle auf 1, um die Mikrocodedateien erneut zu laden, z.
echo 1>/sys/devices/system/cpu/microcode/reload
bash: echo: Schreibfehler: Das Argument ist ungültig.

Ich wundere mich zwar, dass die Fehlermeldung wirklich zum
genannten Kommando gehört (denn einen ungültigen Parameter kann
ich nirgends entdecken), aber das Kommando müsste jedenfalls vor
dem »>« eine Leerstelle haben.

So, wie es da steht, versucht es nicht, eine Zeile, in der eine 1
steht, in die angegebene Datei zu schreiben, sondern es versucht,
eine Leerzeile hineinzuschreiben.

Post by Wolfgang Bauer
Der Befehl ist wohl falsch. Wie müßte es richtig heißen?

echo 1 1>/sys/devices/system/cpu/microcode/reload

oder – was dem gleichkommt (s. u.) –

echo 1 >/sys/devices/system/cpu/microcode/reload

Um zu erklären, was da vor sich geht, versuche ich, Dir den
relevanten Abschnitt »Redirecting Output« aus dem
Bash‐Manual‐Page zu übersetzen:

Die Ausgabe umlenken
Ausgabeumlenkung bewirkt, dass die Datei, deren Name sich
aus der Entwicklung von »word« ergibt, auf dem
Zugriffskanal Nr. n (oder Nr. 1, falls n nicht angegeben
wird) zum Schreiben geöffnet wird. Wenn es die Datei noch
nicht gibt, wird sie erzeugt; wenn es sie bereits gibt,
wird ihr Inhalt auf die Länge 0 gekürzt.

Das allgemeine Format für die Ausgabeumlenkung sieht so
aus:

[n]>word

Wenn der Umlenkungsoperator »>« verwendet wird und die
»noclobber«‐Option des shell‐internen Kommandos »set«
eingeschaltet ist, scheitert die Umlenkung, wenn es die
Datei, deren Name sich aus der Entwicklung von »word«
ergibt, bereits gibt und sie eine gewöhnliche Datei (engl.:
regular file) ist. Wenn der Umlenkungsoperator »>|«
verwendet wird, oder, wenn der Umlenkungsoperator »>« ist
und die »noclobber«‐Option des shell‐internen Kommandos
»set« ausgeschaltet ist, wird die Umlenkung selbst dann
versucht, wenn es die durch »word« bezeichnete Datei
bereits gibt.

Worauf es hier hinausläuft:

echo 1 >Datei

wird gemáß der obenstehenden Erklärung in

echo 1 1>Datei

umgesetzt. Das schreibt eine Zeile, die die Ziffer 1 enthält, in
die Datei.

echo 1>Datei

schreibt eine leere Zeile in die Datei.

Ähnliches gilt auch für die Umlekungsoperatoren »>>«, »<« und
»<<«: Ziffern, die unmittelbar vor dem Operator kleben,
beeinflussen den Operator – sie geben die Kanalnummer an – und
gehören nicht mehr zum davor stehenden Kommando (in Deinem Fall:
dem »echo«‐Kommando).

Dieses Thema ist ein klassisches Shell‐Thema, deswegen schlage ich
ein

Crosspost & Followup-To: de.comp.os.unix.shell

vor.

[Helmut Waitzmann]

Post by Wolfgang Bauer
3. Schreiben Sie die Reload-Schnittstelle auf 1, um die
Mikrocodedateien erneut zu laden, z.
echo 1>/sys/devices/system/cpu/microcode/reload
bash: echo: Schreibfehler: Das Argument ist ungültig.

Ich wundere mich zwar, dass die Fehlermeldung wirklich zum
genannten Kommando gehört (denn einen ungültigen Parameter kann
ich nirgends entdecken), aber das Kommando müsste jedenfalls vor
dem »>« eine Leerstelle haben.

So, wie es da steht, versucht es nicht, eine Zeile, in der eine 1
steht, in die angegebene Datei zu schreiben, sondern es versucht,
eine Leerzeile hineinzuschreiben.

Post by Wolfgang Bauer
Der Befehl ist wohl falsch. Wie müßte es richtig heißen?

echo 1 1>/sys/devices/system/cpu/microcode/reload

oder – was dem gleichkommt (s. u.) –

echo 1 >/sys/devices/system/cpu/microcode/reload

Um zu erklären, was da vor sich geht, versuche ich, Dir den
relevanten Abschnitt »Redirecting Output« aus dem
Bash‐Manual‐Page zu übersetzen:

Die Ausgabe umlenken
Ausgabeumlenkung bewirkt, dass die Datei, deren Name sich
aus der Entwicklung von »word« ergibt, auf dem
Zugriffskanal Nr. n (oder Nr. 1, falls n nicht angegeben
wird) zum Schreiben geöffnet wird. Wenn es die Datei noch
nicht gibt, wird sie erzeugt; wenn es sie bereits gibt,
wird ihr Inhalt auf die Länge 0 gekürzt.

Das allgemeine Format für die Ausgabeumlenkung sieht so
aus:

[n]>word

Wenn der Umlenkungsoperator »>« verwendet wird und die
»noclobber«‐Option des shell‐internen Kommandos »set«
eingeschaltet ist, scheitert die Umlenkung, wenn es die
Datei, deren Name sich aus der Entwicklung von »word«
ergibt, bereits gibt und sie eine gewöhnliche Datei (engl.:
regular file) ist. Wenn der Umlenkungsoperator »>|«
verwendet wird, oder, wenn der Umlenkungsoperator »>« ist
und die »noclobber«‐Option des shell‐internen Kommandos
»set« ausgeschaltet ist, wird die Umlenkung selbst dann
versucht, wenn es die durch »word« bezeichnete Datei
bereits gibt.

Ich füge noch hinzu: Es gibt auch noch den
Ausgabeumlenkungsoperator »[n]>>word«. Der bewirkt, dass der
auszugebende Text an die Datei angehängt wird, statt, dass sie
überschrieben wird. Auch bei ihm wird eine 1 vorne dran ergänzt,
wenn keine Zahl vorne dran klebt.

Worauf es hier hinausläuft:

echo 1 >Datei

wird gemáß der obenstehenden Erklärung in

echo 1 1>Datei

umgesetzt. Das schreibt eine Zeile, die die Ziffer 1 enthält, in
die Datei.

echo 1>Datei

schreibt eine leere Zeile in die Datei.

Ziffern, die unmittelbar vor dem Operator kleben, beeinflussen den
Operator – sie geben die Kanalnummer an – und gehören nicht mehr
zum davor stehenden Kommando (in Deinem Fall: dem
»echo«‐Kommando).

Und dann gibt es auch noch die Eingabeumlekungsoperatoren »<« und
»<<«: Bei ihnen wird im Fall, dass vor ihnen keine Zahl klebt,
die Zahl 0 ergänzt.

Dieses Thema ist ein klassisches Shell‐Thema, deswegen schlage ich
ein

Crosspost & Followup-To: de.comp.os.unix.shell

vor.

[Helmut Waitzmann]

Post by Wolfgang Bauer
3. Schreiben Sie die Reload-Schnittstelle auf 1, um die
Mikrocodedateien erneut zu laden, z.
echo 1>/sys/devices/system/cpu/microcode/reload
bash: echo: Schreibfehler: Das Argument ist ungültig.

Ich wundere mich zwar, dass die Fehlermeldung wirklich zum
genannten Kommando gehört (denn einen ungültigen Parameter kann
ich nirgends entdecken), aber das Kommando müsste jedenfalls vor
dem »>« eine Leerstelle haben.

So, wie es da steht, versucht es nicht, eine Zeile, in der eine 1
steht, in die angegebene Datei zu schreiben, sondern es versucht,
eine Leerzeile hineinzuschreiben.

Post by Wolfgang Bauer
Der Befehl ist wohl falsch. Wie müßte es richtig heißen?

echo 1 1>/sys/devices/system/cpu/microcode/reload

oder – was dem gleichkommt (s. u.) –

echo 1 >/sys/devices/system/cpu/microcode/reload

Um zu erklären, was da vor sich geht, versuche ich, Dir den
relevanten Abschnitt »Redirecting Output« aus dem
Bash‐Manual‐Page zu übersetzen:

Die Ausgabe umlenken
Ausgabeumlenkung bewirkt, dass die Datei, deren Name sich
aus der Entwicklung von »word« ergibt, auf dem
Zugriffskanal Nr. n (oder Nr. 1, falls n nicht angegeben
wird) zum Schreiben geöffnet wird. Wenn es die Datei noch
nicht gibt, wird sie erzeugt; wenn es sie bereits gibt,
wird ihr Inhalt auf die Länge 0 gekürzt.

Das allgemeine Format für die Ausgabeumlenkung sieht so
aus:

[n]>word

Wenn der Umlenkungsoperator »>« verwendet wird und die
»noclobber«‐Option des shell‐internen Kommandos »set«
eingeschaltet ist, scheitert die Umlenkung, wenn es die
Datei, deren Name sich aus der Entwicklung von »word«
ergibt, bereits gibt und sie eine gewöhnliche Datei (engl.:
regular file) ist. Wenn der Umlenkungsoperator »>|«
verwendet wird, oder, wenn der Umlenkungsoperator »>« ist
und die »noclobber«‐Option des shell‐internen Kommandos
»set« ausgeschaltet ist, wird die Umlenkung selbst dann
versucht, wenn es die durch »word« bezeichnete Datei
bereits gibt.

Ich füge noch hinzu: Es gibt auch noch den
Ausgabeumlenkungsoperator »[n]>>word«. Der bewirkt, dass der
auszugebende Text an die Datei angehängt wird, statt, dass sie
überschrieben wird. Auch bei ihm wird eine 1 vorne dran ergänzt,
wenn keine Zahl vorne dran klebt.

Worauf es hier hinausläuft:

echo 1 >Datei

wird gemáß der obenstehenden Erklärung in

echo 1 1>Datei

umgesetzt. Das schreibt eine Zeile, die die Ziffer 1 enthält, in
die Datei.

echo 1>Datei

schreibt eine leere Zeile in die Datei.

Ziffern, die unmittelbar vor dem Operator kleben, beeinflussen den
Operator – sie geben die Kanalnummer an – und gehören nicht mehr
zum davor stehenden Kommando (in Deinem Fall: dem
»echo«‐Kommando).

Und dann gibt es auch noch die Eingabeumlekungsoperatoren »<« und
»<<«: Bei ihnen wird im Fall, dass vor ihnen keine Zahl klebt,
die Zahl 0 ergänzt.

Dieses Thema ist ein klassisches Shell‐Thema, deswegen schlage ich
ein

Crosspost & Followup-To: de.comp.os.unix.shell

vor.

[Wolfgang Bauer]

Post by Helmut Waitzmann

Post by Wolfgang Bauer
3. Schreiben Sie die Reload-Schnittstelle auf 1, um die
Mikrocodedateien erneut zu laden, z.
echo 1>/sys/devices/system/cpu/microcode/reload
bash: echo: Schreibfehler: Das Argument ist ungültig.

Ich wundere mich zwar, dass die Fehlermeldung wirklich zum
genannten Kommando gehört (denn einen ungültigen Parameter kann
ich nirgends entdecken), aber das Kommando müsste jedenfalls vor
dem »>« eine Leerstelle haben.
So, wie es da steht, versucht es nicht, eine Zeile, in der eine 1
steht, in die angegebene Datei zu schreiben, sondern es versucht,
eine Leerzeile hineinzuschreiben.

Post by Wolfgang Bauer
Der Befehl ist wohl falsch. Wie müßte es richtig heißen?

echo 1 1>/sys/devices/system/cpu/microcode/reload
oder – was dem gleichkommt (s. u.) –
echo 1 >/sys/devices/system/cpu/microcode/reload
Dieses Thema ist ein klassisches Shell‐Thema, deswegen schlage ich
ein
Crosspost & Followup-To: de.comp.os.unix.shell
vor.

Ich sehe mir das morgen genau an wenn ich wieder in Linux bin.
Vielleicht funktioniert es ja so wie Du schreibst.

Fup2 erstmal noch ignoriert.

Wolfgang

[Wolfgang Bauer]

@Absender:Helmut Waitzmann

Post by Helmut Waitzmann

Post by Wolfgang Bauer
3. Schreiben Sie die Reload-Schnittstelle auf 1, um die
Mikrocodedateien erneut zu laden, z.
echo 1>/sys/devices/system/cpu/microcode/reload
bash: echo: Schreibfehler: Das Argument ist ungültig.

Ich wundere mich zwar, dass die Fehlermeldung wirklich zum
genannten Kommando gehört (denn einen ungültigen Parameter kann
ich nirgends entdecken), aber das Kommando müsste jedenfalls vor
dem »>« eine Leerstelle haben.
So, wie es da steht, versucht es nicht, eine Zeile, in der eine 1
steht, in die angegebene Datei zu schreiben, sondern es versucht,
eine Leerzeile hineinzuschreiben.

Post by Wolfgang Bauer
Der Befehl ist wohl falsch. Wie müßte es richtig heißen?

echo 1 1>/sys/devices/system/cpu/microcode/reload
oder – was dem gleichkommt (s. u.) –
echo 1 >/sys/devices/system/cpu/microcode/reload
Dieses Thema ist ein klassisches Shell‐Thema, deswegen schlage ich
ein
Crosspost & Followup-To: de.comp.os.unix.shell
vor.

Ich sehe mir das morgen genau an wenn ich wieder in Linux bin.
Vielleicht funktioniert es ja so wie Du schreibst.

Fup2 erstmal noch ignoriert.

[Wolfgang Bauer]

@Absender:Helmut Waitzmann

Post by Helmut Waitzmann

Post by Wolfgang Bauer
3. Schreiben Sie die Reload-Schnittstelle auf 1, um die
Mikrocodedateien erneut zu laden, z.
echo 1>/sys/devices/system/cpu/microcode/reload
bash: echo: Schreibfehler: Das Argument ist ungültig.

Ich wundere mich zwar, dass die Fehlermeldung wirklich zum
genannten Kommando gehört (denn einen ungültigen Parameter kann
ich nirgends entdecken), aber das Kommando müsste jedenfalls vor
dem »>« eine Leerstelle haben.
So, wie es da steht, versucht es nicht, eine Zeile, in der eine 1
steht, in die angegebene Datei zu schreiben, sondern es versucht,
eine Leerzeile hineinzuschreiben.

Post by Wolfgang Bauer
Der Befehl ist wohl falsch. Wie müßte es richtig heißen?

echo 1 1>/sys/devices/system/cpu/microcode/reload
oder – was dem gleichkommt (s. u.) –
echo 1 >/sys/devices/system/cpu/microcode/reload
Dieses Thema ist ein klassisches Shell‐Thema, deswegen schlage ich
ein
Crosspost & Followup-To: de.comp.os.unix.shell
vor.

Ich sehe mir das morgen genau an wenn ich wieder in Linux bin.
Vielleicht funktioniert es ja so wie Du schreibst.

Fup2 erstmal noch ignoriert.

[Wolfgang Bauer]

@Absender:Helmut Waitzmann

Post by Helmut Waitzmann

Post by Wolfgang Bauer
3. Schreiben Sie die Reload-Schnittstelle auf 1, um die
Mikrocodedateien erneut zu laden, z.
echo 1>/sys/devices/system/cpu/microcode/reload
bash: echo: Schreibfehler: Das Argument ist ungültig.

Ich wundere mich zwar, dass die Fehlermeldung wirklich zum
genannten Kommando gehört (denn einen ungültigen Parameter kann
ich nirgends entdecken), aber das Kommando müsste jedenfalls vor
dem »>« eine Leerstelle haben.
So, wie es da steht, versucht es nicht, eine Zeile, in der eine 1
steht, in die angegebene Datei zu schreiben, sondern es versucht,
eine Leerzeile hineinzuschreiben.

Post by Wolfgang Bauer
Der Befehl ist wohl falsch. Wie müßte es richtig heißen?

echo 1 1>/sys/devices/system/cpu/microcode/reload
oder – was dem gleichkommt (s. u.) –
echo 1 >/sys/devices/system/cpu/microcode/reload
Dieses Thema ist ein klassisches Shell‐Thema, deswegen schlage ich
ein
Crosspost & Followup-To: de.comp.os.unix.shell
vor.

Ich sehe mir das morgen genau an wenn ich wieder in Linux bin.
Vielleicht funktioniert es ja so wie Du schreibst.

Fup2 erstmal noch ignoriert.

[Wolfgang Bauer]

@Absender:Helmut Waitzmann

Post by Helmut Waitzmann

Post by Wolfgang Bauer
Der Befehl ist wohl falsch. Wie müßte es richtig heißen?

echo 1 1>/sys/devices/system/cpu/microcode/reload
oder – was dem gleichkommt (s. u.) –
echo 1 >/sys/devices/system/cpu/microcode/reload
Dieses Thema ist ein klassisches Shell‐Thema, deswegen schlage ich
ein
Crosspost & Followup-To: de.comp.os.unix.shell
vor.

Fup2 erstmal noch ignoriert. Cielleicht geht es ja schon so wie Du
schreibt. Ich probiere es morgen wenn ich wieder in Linux bin.

[Andreas Kohlbach]

Post by Wolfgang Bauer
Servus.
Ich habe mir von
https://downloadcenter.intel.com/download/27591/Linux-Processor-Microcode-Data-File
microcode-20180807.tgz geholt und entpackt. Entpackt daraus
http://www.wolfgang-bauer.at/screenshot/intel-code.jpg

Ich würde vermuten, Dein Paketmanager hätte den eh. Starte ihn mal und
suche nach "microcode", ob da etwas für Intel bei ist.

Post by Wolfgang Bauer
3. Schreiben Sie die Reload-Schnittstelle auf 1, um die Mikrocodedateien erneut zu laden, z.
echo 1>/sys/devices/system/cpu/microcode/reload

Meines Erachtens müsste da ein Leerzeichen nach der 1 stehen. Auch wenn
nicht nötig, habe ich auch noch eines nach der 1 gemacht. Sieht hübscher
aus. ;-)

echo 1 > /sys/devices/system/cpu/microcode/reload

Aber versuche das erst über den Paketmanager (Software-Center, oder wie
sich das noch nennen mag). Der sorgt sich auch um dieses.

[Wolfgang Bauer]

Post by Andreas Kohlbach

Post by Wolfgang Bauer
Servus.
Ich habe mir von
https://downloadcenter.intel.com/download/27591/Linux-Processor-Microcode-Data-File
microcode-20180807.tgz geholt und entpackt. Entpackt daraus
http://www.wolfgang-bauer.at/screenshot/intel-code.jpg

Ich würde vermuten, Dein Paketmanager hätte den eh. Starte ihn mal und
suche nach "microcode", ob da etwas für Intel bei ist.

Ist dabei, aber nicht die aktuelle Version 20180807.
Der Paketmanager hat nur die Version 20180425 in der noch Lücken sind.

Post by Andreas Kohlbach

Post by Wolfgang Bauer
3. Schreiben Sie die Reload-Schnittstelle auf 1, um die Mikrocodedateien erneut zu laden, z.
echo 1>/sys/devices/system/cpu/microcode/reload

Meines Erachtens müsste da ein Leerzeichen nach der 1 stehen. Auch wenn
nicht nötig, habe ich auch noch eines nach der 1 gemacht. Sieht hübscher
aus. ;-)
echo 1 > /sys/devices/system/cpu/microcode/reload

Ja so hat es dann auch funktioniert.
Ich bedanke mich bei euch.

Wolfgang

[Andreas Kohlbach]

Post by Wolfgang Bauer

Post by Andreas Kohlbach

Post by Wolfgang Bauer
Ich habe mir von
https://downloadcenter.intel.com/download/27591/Linux-Processor-Microcode-Data-File
microcode-20180807.tgz geholt und entpackt. Entpackt daraus
http://www.wolfgang-bauer.at/screenshot/intel-code.jpg

Ich würde vermuten, Dein Paketmanager hätte den eh. Starte ihn mal und
suche nach "microcode", ob da etwas für Intel bei ist.

Ist dabei, aber nicht die aktuelle Version 20180807.
Der Paketmanager hat nur die Version 20180425 in der noch Lücken sind.

Wenn das kritische Lücken sind, sollten die auch vom Paketmanager
umgehend ausgeliefert werden.

Hast Du das Paket auch nebenher noch installiert? Sonst hast Du nun das
Problem, ständig auf der Intel Webseite schauen zu müssen, ob es wieder
ein Update gibt.

[Wolfgang Bauer]

Post by Andreas Kohlbach

Post by Wolfgang Bauer

Post by Andreas Kohlbach
Ich würde vermuten, Dein Paketmanager hätte den eh. Starte ihn mal und
suche nach "microcode", ob da etwas für Intel bei ist.

Ist dabei, aber nicht die aktuelle Version 20180807.
Der Paketmanager hat nur die Version 20180425 in der noch Lücken sind.

Wenn das kritische Lücken sind, sollten die auch vom Paketmanager
umgehend ausgeliefert werden.

/Sollten/, wird aber nicht. Im Paketmanager wird angeboten
Version 20180425.1~ubuntu0.16.04.2. Aktuell ist aber microcode-20180807
^^^^ ^^^^^

Post by Andreas Kohlbach
Hast Du das Paket auch nebenher noch installiert? Sonst hast Du nun das
Problem, ständig auf der Intel Webseite schauen zu müssen, ob es wieder
ein Update gibt.

Ja das ist wohl so. Solange bis sich mein KDE-neon mal bequemt den
jeweils aktuellen microcode einzupflegen.

Wolfgang

[Dieter Intas]

Am Mon, 27 Aug 2018 11:35:25 +0200

Post by Wolfgang Bauer

Post by Andreas Kohlbach

Post by Wolfgang Bauer

Post by Andreas Kohlbach
Ich würde vermuten, Dein Paketmanager hätte den eh. Starte ihn
mal und suche nach "microcode", ob da etwas für Intel bei ist.

Ist dabei, aber nicht die aktuelle Version 20180807.
Der Paketmanager hat nur die Version 20180425 in der noch Lücken sind.

Wenn das kritische Lücken sind, sollten die auch vom Paketmanager
umgehend ausgeliefert werden.

/Sollten/, wird aber nicht. Im Paketmanager wird angeboten
Version 20180425.1~ubuntu0.16.04.2. Aktuell ist aber
microcode-20180807
^^^^ ^^^^^

Post by Andreas Kohlbach
Hast Du das Paket auch nebenher noch installiert? Sonst hast Du nun
das Problem, ständig auf der Intel Webseite schauen zu müssen, ob
es wieder ein Update gibt.

Ja das ist wohl so. Solange bis sich mein KDE-neon mal bequemt den
jeweils aktuellen microcode einzupflegen.

Das liegt nicht an KDE-neon - Intel muss die Lizenz-Bestimmungen
entsprechend anpassen, dass die Distributoren diese auch heraus
gegeben werden können.

Ein jeder (privat) kann aber den Treiber herunterladen und einspielen:
Das hast du doch gemacht - was willst du denn dann noch!?

[Wolfgang Bauer]

Post by Dieter Intas
Am Mon, 27 Aug 2018 11:35:25 +0200

Post by Wolfgang Bauer

Post by Andreas Kohlbach
Wenn das kritische Lücken sind, sollten die auch vom Paketmanager
umgehend ausgeliefert werden.

/Sollten/, wird aber nicht. Im Paketmanager wird angeboten
Version 20180425.1~ubuntu0.16.04.2. Aktuell ist aber microcode-20180807

^^^^^^^^ ^^^^^^^^

Post by Dieter Intas

Post by Wolfgang Bauer
Ja das ist wohl so. Solange bis sich mein KDE-neon mal bequemt den
jeweils aktuellen microcode einzupflegen.

Das liegt nicht an KDE-neon - Intel muss die Lizenz-Bestimmungen
entsprechend anpassen, dass die Distributoren diese auch heraus
gegeben werden können.
Das hast du doch gemacht - was willst du denn dann noch!?

Das habe ich doch nach der Anleitung gemacht.

https://downloadcenter.intel.com/download/27591/Linux-Processor-Microcode-Data-File

Kopieren Sie das Verzeichnis intel-ucode nach
/lib/firmware, überschreiben Sie die Dateien in /lib/Firmware/Intel-Code/

3. Schreiben Sie die Reload-Schnittstelle auf 1, um die Mikrocodedateien
erneut zu laden, e.g.
echo 1 >/sys/devices/system/cpu/microcode/reload

Beim Booten wird aus dem BIOS der /alte/ intel-microcode geladen
bei dem die L1TF alias "L1 Terminal Fault" genannte Luecke nicht
gestopft ist.

Erst wenn ich im aktiven Linux
echo 1 >/sys/devices/system/cpu/microcode/reload
ausführe ist der gepatchte micro-code geladen.

Ich habe schon versucht das mit einem Startscript zu lösen.

In /etc/init.d/local.autostart/
#! /bin/sh
# Aktionen
echo 1 > /sys/devices/system/cpu/microcode/reload

Aber das wird wohl zu früh ausgeführt.

Wolfgang

[Dieter Intas]

Am Mon, 27 Aug 2018 17:19:27 +0200

Post by Wolfgang Bauer

Post by Dieter Intas
Am Mon, 27 Aug 2018 11:35:25 +0200

Post by Wolfgang Bauer

Post by Andreas Kohlbach
Wenn das kritische Lücken sind, sollten die auch vom Paketmanager
umgehend ausgeliefert werden.

/Sollten/, wird aber nicht. Im Paketmanager wird angeboten
Version 20180425.1~ubuntu0.16.04.2. Aktuell ist aber
microcode-20180807

^^^^^^^^
^^^^^^^^

Post by Dieter Intas

Post by Wolfgang Bauer
Ja das ist wohl so. Solange bis sich mein KDE-neon mal bequemt den
jeweils aktuellen microcode einzupflegen.

Das liegt nicht an KDE-neon - Intel muss die Lizenz-Bestimmungen
entsprechend anpassen, dass die Distributoren diese auch heraus
gegeben werden können.
Ein jeder (privat) kann aber den Treiber herunterladen und
einspielen: Das hast du doch gemacht - was willst du denn dann
noch!?

Das habe ich doch nach der Anleitung gemacht.
https://downloadcenter.intel.com/download/27591/Linux-Processor-Microcode-Data-File
Kopieren Sie das Verzeichnis intel-ucode nach
/lib/firmware, überschreiben Sie die Dateien
in /lib/Firmware/Intel-Code/
3. Schreiben Sie die Reload-Schnittstelle auf 1, um die
Mikrocodedateien erneut zu laden, e.g.
echo 1 >/sys/devices/system/cpu/microcode/reload
Beim Booten wird aus dem BIOS der /alte/ intel-microcode geladen
bei dem die L1TF alias "L1 Terminal Fault" genannte Luecke nicht
gestopft ist.
Erst wenn ich im aktiven Linux
echo 1 >/sys/devices/system/cpu/microcode/reload
ausführe ist der gepatchte micro-code geladen.

Solche Halbsachen sind nicht vollständig!

Damit bei einem Neustart dieser neue Microcode geladen wird, muss die
Initial Ramdisk neu erstellt werden:

***@0x8e:~$ sudo update-initramfs -u

https://www.thomas-krenn.com/de/wiki/Intel_Microcode_unter_Linux_aktualisieren

Ist jetzt aber schon gelaufen - schrieb ich aber nur, um dieses zu
vervollständigen!

[Bernd Mayer]

Post by Dieter Intas
Am Mon, 27 Aug 2018 11:35:25 +0200

Post by Wolfgang Bauer
/Sollten/, wird aber nicht. Im Paketmanager wird angeboten
Version 20180425.1~ubuntu0.16.04.2. Aktuell ist aber
microcode-20180807
^^^^ ^^^^^

Post by Andreas Kohlbach
Hast Du das Paket auch nebenher noch installiert? Sonst hast Du nun
das Problem, ständig auf der Intel Webseite schauen zu müssen, ob
es wieder ein Update gibt.

Ja das ist wohl so. Solange bis sich mein KDE-neon mal bequemt den
jeweils aktuellen microcode einzupflegen.

Das liegt nicht an KDE-neon - Intel muss die Lizenz-Bestimmungen
entsprechend anpassen, dass die Distributoren diese auch heraus
gegeben werden können.

Hallo,

offenbar wurden die Lizenzbedingungen von Intel mittlwerweile geändert:

https://it.slashdot.org/story/18/08/23/2041206/intels-reworked-microcode-security-fix-license-no-longer-prohibits-benchmarking

https://linuxnews.de/2018/08/intel-lenkt-ein-bei-lizenz-zu-microcode/


Bernd Mayer

[Gunter Gutzeit]

Post by Juergen Ilse
Hallo,
https://it.slashdot.org/story/18/08/23/2041206/intels-reworked-microcode-security-fix-license-no-longer-prohibits-benchmarking
https://linuxnews.de/2018/08/intel-lenkt-ein-bei-lizenz-zu-microcode/

@debian-&intel-user:

Habe hier in einem aktualisierten dirty Debian Stretch erstmalig
test- und versuchsweise, händisch ein Microcode-Update durch geführt, da
ich zwar den aktuellen Kernel, aber noch den alten Microcode
installiert habe:

sudo apt-get install intel-microcode

Nach dem Reboot hat mein alter Prozessor den neuen Microcode gefressen:

***@hp2:~$ sudo journalctl -b -k | grep "microcode updated early to"
Aug 27 20:02:51 hp2 kernel: microcode: microcode updated early to
revision 0x107, date = 2009-08-25

***@hp2:~$ apt list --installed
...
intel-microcode/stable,now 3.20180703.2~deb9u1 i386 [installiert]
...

Was macht Ihr?

https://linuxnews.de/2018/08/debian-schliesst-intel-luecken/

| Um diese Schwachstellen vollständig zu schließen, ist es neben dem
| veröffentlichten Debian-Kernel 4.9.110-3+deb9u3 erforderlich, dass
| unter Debian »Stretch« der aktualisierte CPU-Microcode in Version
| 3.20180703.2~deb9u1 aus dem unfreien Repository non-free eingespielt
| wird. Dazu müssen Anwender kurzzeitig ihre Quellenliste erweitern.
| Dieser Microcode schließt durch Speculative Store Bypass Disable (SSBD)
| zusätzlich auch die Lücken Spectre Variante 3a und Variante 4
| (CVE-2018-3639).
|
| Anwender von Debian Stable sind aufgerufen, die aktualisierten Pakete
| schnellstmöglich einzuspielen, um gegen die Lücken geschützt zu sein.

[Wolfgang Bauer]

Post by Gunter Gutzeit
...
intel-microcode/stable,now 3.20180703.2~deb9u1 i386 [installiert]
...

Das ist aber /nicht/ der gepatchte microcode.

Das ist der microcode-20180807 der die Lücken schließt.
Der aber von Debian bisher nicht angeboten wird.
(wegen Lizenzgeplänkel)

Post by Gunter Gutzeit
Was macht Ihr?
https://linuxnews.de/2018/08/debian-schliesst-intel-luecken/
| Um diese Schwachstellen vollständig zu schließen, ist es neben dem
| veröffentlichten Debian-Kernel 4.9.110-3+deb9u3 erforderlich, dass
| unter Debian »Stretch« der aktualisierte CPU-Microcode in Version
| 3.20180703.2~deb9u1 aus dem unfreien Repository non-free eingespielt
| wird. Dazu müssen Anwender kurzzeitig ihre Quellenliste erweitern.
| Dieser Microcode schließt durch Speculative Store Bypass Disable (SSBD)
| zusätzlich auch die Lücken Spectre Variante 3a und Variante 4
| (CVE-2018-3639).
|
| Anwender von Debian Stable sind aufgerufen, die aktualisierten Pakete
| schnellstmöglich einzuspielen, um gegen die Lücken geschützt zu sein.

Ich habe ihn /eingespielt/. Muß aber, weil beim Boot der alte micro-code
aus dem BIOS geladen wird, erst mit
echo 1 > /sys/devices/system/cpu/microcode/reload
im Rootterminal den aktuellen Code laden.

Wolfgang

[Gunter Gutzeit]

Post by Wolfgang Bauer

Post by Gunter Gutzeit
...
intel-microcode/stable,now 3.20180703.2~deb9u1 i386 [installiert]
...

Das ist aber /nicht/ der gepatchte microcode.
Das ist der microcode-20180807 der die Lücken schließt.
Der aber von Debian bisher nicht angeboten wird.
(wegen Lizenzgeplänkel)

Ja, aus den sid-Quellen wird mir dies angeboten:

intel-microcode/stable,now 3.20180703.2~deb9u1 i386
[Installiert,aktualisierbar auf: 3.20180807a.1]
^^^^^^^^^^^^^

Post by Wolfgang Bauer

Post by Gunter Gutzeit
Was macht Ihr?
https://linuxnews.de/2018/08/debian-schliesst-intel-luecken/
| Um diese Schwachstellen vollständig zu schließen, ist es neben dem
| veröffentlichten Debian-Kernel 4.9.110-3+deb9u3 erforderlich, dass
| unter Debian »Stretch« der aktualisierte CPU-Microcode in Version
| 3.20180703.2~deb9u1 aus dem unfreien Repository non-free eingespielt
| wird. Dazu müssen Anwender kurzzeitig ihre Quellenliste erweitern.
| Dieser Microcode schließt durch Speculative Store Bypass Disable (SSBD)
| zusätzlich auch die Lücken Spectre Variante 3a und Variante 4
| (CVE-2018-3639).
|
| Anwender von Debian Stable sind aufgerufen, die aktualisierten Pakete
| schnellstmöglich einzuspielen, um gegen die Lücken geschützt zu sein.

Ich habe ihn /eingespielt/. Muß aber, weil beim Boot der alte micro-code
aus dem BIOS geladen wird, erst mit
echo 1> /sys/devices/system/cpu/microcode/reload
im Rootterminal den aktuellen Code laden.

Mir scheint, Du hast alles richtig gemacht :-)

https://www.redhat.com/en/blog/speculative-store-bypass-explained-what-it-how-it-works

Das Filmchen ist klasse :-)

[Gunter Gutzeit]

Post by Gunter Gutzeit

Post by Wolfgang Bauer

Post by Gunter Gutzeit
...
intel-microcode/stable,now 3.20180703.2~deb9u1 i386 [installiert]
...

Das ist aber /nicht/ der gepatchte microcode.
Das ist der microcode-20180807 der die Lücken schließt.
Der aber von Debian bisher nicht angeboten wird.
(wegen Lizenzgeplänkel)

intel-microcode/stable,now 3.20180703.2~deb9u1 i386
[Installiert,aktualisierbar auf: 3.20180807a.1]

Habe hier testweise die Aktualisierung aus dem sid gemacht:

Scheint aber funktioniert zu haben:

intel-microcode/now 3.20180807a.1 i386 [Installiert,lokal]
Warum jetzt ^^^^^ ?

***@hp2:~$ sudo journalctl -b -k | grep "microcode updated early to"
hm - jetzt keine Ausgabe!

***@hp2:~$ sudo dmesg | grep microcode
[ 1.779626] microcode: sig=0x106ca, pf=0x4, revision=0x107
[ 1.779859] microcode: Microcode Update Driver: v2.01
<***@aivazian.fsnet.co.uk>, Peter Oruba
Auch hier fehlt jetzt die Zeile: microcode updated early to revision!

Debian stellt hier wohl den aktuellsten Intel-Microcode im sid zu
Verfügung!

[Patrick Rudin]

Post by Gunter Gutzeit
Debian stellt hier wohl den aktuellsten Intel-Microcode im sid zu
Verfügung!

https://tracker.debian.org/pkg/intel-microcode


Gruss

Patrick

[Gunter Gutzeit]

Post by Patrick Rudin

Post by Gunter Gutzeit
Debian stellt hier wohl den aktuellsten Intel-Microcode im sid zu
Verfügung!

https://tracker.debian.org/pkg/intel-microcode

Da schimpfen die Leute immer, wegen der angeblich angestaubten Software
in Debian. Stimmt nach meiner Erfahrung aber überhaupt nicht.

Wenn ich mich denn aus den sid-Paketquellen bedienen will (und bereit
bin die möglichen Konsequenzen in Kauf zu nehmen), bin ich in der Regel
genau so aktuell wie mit Arch oder Manjaro.

[Gunter Gutzeit]

Post by Patrick Rudin

Post by Gunter Gutzeit
Debian stellt hier wohl den aktuellsten Intel-Microcode im sid zu
Verfügung!

https://tracker.debian.org/pkg/intel-microcode

Ja, hier ist der intel-mirocode für den bei mir verbauten Prozessor-Typ:

Intel Atom® Processor N455 (512K Cache, 1.66 GHz) [vgl. Sig des Test-Pc]

https://downloadcenter.intel.com/product/49491/Intel-Atom-Processor-N455-512K-Cache-1-66-GHz-

Es gibt nix Aktuelleres, als das von Debian zur Verfügung gestellte und
jetzt bei mir geupdatete Paket.

[Gunter Gutzeit]

Post by Gunter Gutzeit
hm - jetzt keine Ausgabe!
[ 1.779626] microcode: sig=0x106ca, pf=0x4, revision=0x107
[ 1.779859] microcode: Microcode Update Driver: v2.01
Auch hier fehlt jetzt die Zeile: microcode updated early to revision!

Ah ja hier steht die Erklärung:

| Please note that it is entirely possible that there is no microcode
| update available for your CPU. In that case it will look as follows:

https://www.cyberciti.biz/faq/install-update-intel-microcode-firmware-linux/

Dann hat ja alles seine Richtigkeit :-)

[Gunter Gutzeit]

Post by Gunter Gutzeit
intel-microcode/now 3.20180807a.1 i386 [Installiert,lokal]
Warum jetzt ^^^^^ ?

Nachdem ich jetzt diverse Testkapazitäten auch auf meinen anderen
Rechnern freigezogen habe, werde ich jetzt auch auf meinen anderen
Rechnern die sinnvollen Möglichkeiten und ggf. Performance-Einbußen
durch händische Microcode-Updates austesten.

Hierbei habe ich jetzt festgestellt, dass der 'lokal'-Zusatz durch apt
erst dann gesetzt wird, wenn die Sid-Paketquellen nach der Installation
wieder deaktiviert werden. Der Zusatz ist also harmlos.

Erste Laufzeittests auf meinem Pc2 haben bei mir übrigens ergeben, dass
die Performance-Einbußen, verursacht durch den aktuellen Microcode sehr
gering sind. Viel geringer als bei den grundsätzlichen Laufzeit-
Vergleichen zwischen Debian Stretch und Debian Testing, wobei ich dann
später doch noch einmal prüfen muss, ob ich den apparmor-Klimbim
endgültig aus Debian Buster eliminieren werde; spätestens dann, wenn
Buster Stable wird.

[Gunter Gutzeit]

Post by Gunter Gutzeit
Nachdem ich jetzt diverse Testkapazitäten auch auf meinen anderen
Rechnern freigezogen habe, werde ich jetzt auch auf meinen anderen
Rechnern die sinnvollen Möglichkeiten und ggf. Performance-Einbußen
durch händische Microcode-Updates austesten.

Die erste Überraschung, die ich jetzt feststellen muss ist folgende:

Auf meinen Debian-Stretch-Systemen ist jetzt offenbar ein händisches
Microcode-Update gar nicht mehr notwendig:

***@hp1:~$ sudo dmesg | grep 'microcode'
[ 1.056732] microcode: sig=0x6fd, pf=0x1, revision=0xa3
[ 1.056826] microcode: Microcode Update Driver: v2.01 <***@aivazian.fsnet.co.uk>, Peter Oruba

Das Microcode-Update (für die aktuellste Intel-Version) hat sich
offenbar zwischenzeitlich schon ohne mein Zutun vollzogen.

Systemd meldet mir beim Booten überall folgendes:
...
Aug 31 13:02:35 hp1 kernel: Spectre V2 : Mitigation: Full generic retpoline
Aug 31 13:02:35 hp1 kernel: Spectre V2 : Spectre v2 mitigation: Filling RSB on context switch
Aug 31 13:02:35 hp1 kernel: Speculative Store Bypass: Vulnerable
...

Versteht das jemand?

[Gunter Gutzeit]

Post by Gunter Gutzeit

Post by Gunter Gutzeit
Nachdem ich jetzt diverse Testkapazitäten auch auf meinen anderen
Rechnern freigezogen habe, werde ich jetzt auch auf meinen anderen
Rechnern die sinnvollen Möglichkeiten und ggf. Performance-Einbußen
durch händische Microcode-Updates austesten.

Auf meinen Debian-Stretch-Systemen ist jetzt offenbar ein händisches
[ 1.056732] microcode: sig=0x6fd, pf=0x1, revision=0xa3

Gilt für Debian Testing im Prinzip genauso, aber:

Microcode Update Driver: v2.2

Post by Gunter Gutzeit
Das Microcode-Update (für die aktuellste Intel-Version) hat sich
offenbar zwischenzeitlich schon ohne mein Zutun vollzogen.
...
Aug 31 13:02:35 hp1 kernel: Spectre V2 : Mitigation: Full generic retpoline
Aug 31 13:02:35 hp1 kernel: Spectre V2 : Spectre v2 mitigation: Filling RSB on context switch
Aug 31 13:02:35 hp1 kernel: Speculative Store Bypass: Vulnerable
...

Debian-Testing-Kernel meldet dasselbe.

Post by Gunter Gutzeit
Versteht das jemand?

Na ja, da soll noch einmal jemand etwas gegen Debian sagen :-)

Intel Microcode-Updates machen Windows 10 Update Probleme
http://winfuture.de/news,104753.html

[Wolfgang Bauer]

Post by Gunter Gutzeit
Na ja, da soll noch einmal jemand etwas gegen Debian sagen :-)

Da war Debian wirklich auf Zack.

Post by Gunter Gutzeit
Intel Microcode-Updates machen Windows 10 Update Probleme
http://winfuture.de/news,104753.html

Weil das von Microsoft angebotenen KB4346084: Intel microcode update
nicht das gepatchte Intel microcode *ist*

Wolfgang

[Gunter Gutzeit]

Post by Wolfgang Bauer

Post by Gunter Gutzeit
Na ja, da soll noch einmal jemand etwas gegen Debian sagen :-)

Da war Debian wirklich auf Zack.

Ja, in puncto Sicherheit ist Debian wirklich sehr gut, auch
Debian-Testing.

Debian ist nicht immer am schnellsten; die Entwickler arbeiten dafür
aber in der Regel äußerst zuverlässig und gewissenhaft.

Da KDE neon aber auch auf Debian bzw. Ubuntu basiert, solltest
mittlerweile auch Du mit Deinem Paket-Manager davon profitieren :-)

Wird bei Dir in Deinem Synaptic mittlerweile auch der aktuellste
Intel-Microcode als eigenständiges Paket mit entsprechender
Intel-Versionsnummer aufgeführt?

Post by Wolfgang Bauer

Post by Gunter Gutzeit
Intel Microcode-Updates machen Windows 10 Update Probleme
http://winfuture.de/news,104753.html

Weil das von Microsoft angebotenen KB4346084: Intel microcode update
nicht das gepatchte Intel microcode *ist*

Ja, sollte nur ein Beispiel sein, dass es selbst bei Microsoft mit
seinen Update-Mechanismen nicht immer problemlos funktioniert.

[Wolfgang Bauer]

@Absender:Gunter Gutzeit

Post by Gunter Gutzeit
Da KDE neon aber auch auf Debian bzw. Ubuntu basiert, solltest
mittlerweile auch Du mit Deinem Paket-Manager davon profitieren :-)
Wird bei Dir in Deinem Synaptic mittlerweile auch der aktuellste
Intel-Microcode als eigenständiges Paket mit entsprechender
Intel-Versionsnummer aufgeführt?

Ja, ist auch schon installiert.

Post by Gunter Gutzeit

Post by Wolfgang Bauer
Weil das von Microsoft angebotenen KB4346084: Intel microcode update
nicht das gepatchte Intel microcode *ist*

Ja, sollte nur ein Beispiel sein, dass es selbst bei Microsoft mit
seinen Update-Mechanismen nicht immer problemlos funktioniert.

Mal sehen wann die sich entschließen das zu machen.

[Gunter Gutzeit]

Post by Gunter Gutzeit

Post by Wolfgang Bauer
Da war Debian wirklich auf Zack.

Wird bei Dir in Deinem Synaptic mittlerweile auch der aktuellste
Intel-Microcode als eigenständiges Paket mit entsprechender
Intel-Versionsnummer aufgeführt?

Habe mich dann gestern entschieden, iucode-tool (2.3.1-1) in die Master-
Versionen meiner Debiane einzupflegen, um nicht nur die krypischen
Kernel-Versionsnummern, sondern auch die allgemeinen Intel-Versions-
nummern des aktuellen Intel-Microcodes mit apt oder Sysnaptic angezeigt
zu bekommen. Denn ich möchte eigentlich immer gerne im Klartext wissen,
was auf meinen Systemen eigentlich los ist. Und wer weiß schon, was die
da zukünftig noch alles für Sicherheitslöcher in den Intel-Prozessoren
finden werden :-)

Ok, wie sich meine Debiane jetzt bei weiteren regulären Pflege-Updates
in puncto Microcodes verhalten werden, kann ich nicht ganz abschätzen.

https://wiki.debian.org/Microcode

| It is very difficult to know for sure whether you need a microcode
| update or not, but it is not safe at all to just ignore them. You might
| not notice their effect and have precious data silently corrupted, or
| an important program silently misbehave. Or you could experience one of
| those unexplainable and infrequent software issues (such as kernel
| oops, application segfaults) or hardware issues (including sudden
| reboots and hangs).
|
| Releases of new microcode updates are more frequent on young
| processors, but the release of new microcode updates for older
| processors do happen.

Das Risiko ist hoffentlich überschaubar.

| Very rarely, it is possible for a kernel or a microcode update bug to
| cause boot issues (hangs or resets at the very beginning of the boot
| process) on specific processor models.

Nichts gelangt völlig ungeprüft in die Debian-Quellen.

| Microcode packages are first uploaded to non-free unstable, and after
| one or two weeks, if no issues are reported, are automatically migrated
| to non-free testing.

Nur als Testing-Nutzer, bin ich selbst ein Debian-Versuchskarnickel!

So, damit ist das Thema für mich jetzt erst einmal mit einem Ergebnis
abgeschlossen.

Meine alte Hardware werde ich auch jetzt nicht auf den Müll schmeißen,
da selbst diese alten Prozessoren noch unterstützt werden und Debian
finde ich wirklich gut.

Schönen Sonntag noch und ganz besonderes liebe Grüße an Wolfgang

[Wolfgang Bauer]

Post by Gunter Gutzeit
Ok, wie sich meine Debiane jetzt bei weiteren regulären Pflege-Updates
in puncto Microcodes verhalten werden, kann ich nicht ganz abschätzen.

Das wird man dann erfehren.

Post by Gunter Gutzeit
https://wiki.debian.org/Microcode

Ich habe die Site besucht und

CPU Microcode
CPU microcode non-freeness

Updating CPU microcode within Debian (Intel or AMD)

Microcode update support for current and older Debian releases
Debian 9 "Stretch" (stable)
aufgerufen weil ich denke KDE-neon basiert darauf. Die repository
habe ich, soweit sich noch nicht vorhanden waren in
/etc/apt/sources.list hinzugefügt.

Da ich in letzter Zeit aber mehr in Windows 10 bin, muß ich da wohl noch warten.

Da Du überwiegend in Linuxgruppen bist, wirst Du Stefan Kanthak kaum lesen. Wenn man ihn in den Windowsgruppen liest ist man wegen seiner grenzwertigen Ausdrucksweise erstmal schockiert. Wenn man ihn aber besser kennenlernt kann man ihm das verzeihen. Stefan ist ein absoluter
Kenner was auch die Hardware angeht. (mit /Röntgenblick/ in die Tiefen des BIOS und der CPU).

Stefan hat erkannt, daß ich noch eine alte BIOS Version habe, und mir
geschrieben wie ich das updaten kann. Und daß der AMD-/ Intel-microcode
für Windows immer noch nicht gepatcht ist.

Post by Gunter Gutzeit
Schönen Sonntag noch und ganz besonderes liebe Grüße an Wolfgang

Danke, das gebe ich gerne zurück.

Wolfgang

[Wolfgang Bauer]

Post by Gunter Gutzeit
Ok, wie sich meine Debiane jetzt bei weiteren regulären Pflege-Updates
in puncto Microcodes verhalten werden, kann ich nicht ganz abschätzen.

Das wird man dann erfehren.

Post by Gunter Gutzeit
https://wiki.debian.org/Microcode

Ich habe die Site besucht und
CPU Microcode
CPU microcode non-freeness

Updating CPU microcode within Debian (Intel or AMD)

Microcode update support for current and older Debian releases
Debian 9 "Stretch" (stable)

aufgerufen weil ich denke KDE-neon basiert darauf. Die repository
habe ich, soweit sie noch nicht vorhanden waren in
/etc/apt/sources.list hinzugefügt.

Da ich in letzter Zeit aber mehr in Windows 10 bin, muß ich da wohl noch
warten.

Da Du überwiegend in Linuxgruppen bist, wirst Du Stefan Kanthak kaum
lesen. Wenn man ihn in den Windowsgruppen liest ist man wegen seiner
grenzwertigen Ausdrucksweise erstmal schockiert. Wenn man ihn aber
besser kennenlernt kann man ihm das verzeihen. Stefan ist ein absoluter
Kenner was auch die Hardware angeht. (mit /Röntgenblick/ in die Tiefen
des BIOS und der CPU).

Stefan hat erkannt, daß ich noch eine alte BIOS Version habe, und mir
geschrieben wie ich das updaten kann. Und daß der AMD-/ Intel-microcode
für Windows immer noch nicht gepatcht ist.

Post by Gunter Gutzeit
Schönen Sonntag noch und ganz besonderes liebe Grüße an Wolfgang

Danke, das gebe ich gerne zurück.

Wolfgang

[Gunter Gutzeit]

Post by Gunter Gutzeit

Post by Gunter Gutzeit

Post by Wolfgang Bauer
Da war Debian wirklich auf Zack.

Wird bei Dir in Deinem Synaptic mittlerweile auch der aktuellste
Intel-Microcode als eigenständiges Paket mit entsprechender
Intel-Versionsnummer aufgeführt?

Habe mich dann gestern entschieden, iucode-tool (2.3.1-1) in die Master-
Versionen meiner Debiane einzupflegen, um nicht nur die krypischen
Kernel-Versionsnummern, sondern auch die allgemeinen Intel-Versions-
nummern des aktuellen Intel-Microcodes mit apt oder Sysnaptic angezeigt
zu bekommen. Denn ich möchte eigentlich immer gerne im Klartext wissen,
was auf meinen Systemen eigentlich los ist. Und wer weiß schon, was die
da zukünftig noch alles für Sicherheitslöcher in den Intel-Prozessoren
finden werden :-)
Ok, wie sich meine Debiane jetzt bei weiteren regulären Pflege-Updates
in puncto Microcodes verhalten werden, kann ich nicht ganz abschätzen.

Jou, die Zeit der Ungewissheit ist vorbei!

Falls es noch jemanden interessieren sollte: Heute kam das Microcode-
Update ganz schmerzlos im Rahmen eines regulären Pflege-Updates auch in
Debian Stable rein:

| Auflistung... Fertig
| intel-microcode/stable,now 3.20180703.2~deb9u1 i386 [installiert]
|
| [...]
|
| Die folgenden Pakete werden aktualisiert (Upgrade):
| ghostscript intel-microcode libgs9 libgs9-common palemoon
| 5 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht
| aktualisiert. Es müssen 51,2 MB an Archiven heruntergeladen werden.
|
| Holen:5 http://security.debian.org/debian-security
| stretch/updates/non-free i386 intel-microcode i386 3.20180807a.1~deb9u1
| [1.435 kB]
|
| Vorbereitung zum Entpacken
| von .../intel-microcode_3.20180807a.1~deb9u1_i386.deb ... Entpacken von
| intel-microcode (3.20180807a.1~deb9u1) über (3.20180703.2~deb9u1) ...
|
| intel-microcode (3.20180807a.1~deb9u1) wird eingerichtet ...
|
| intel-microcode: microcode will be updated at next boot
|
| [...]
|
| Auflistung... Fertig
| intel-microcode/stable,now 3.20180807a.1~deb9u1 i386 [installiert]

Klasse :-)

[Andreas Kohlbach]

Post by Dieter Intas
Am Mon, 27 Aug 2018 11:35:25 +0200

Post by Wolfgang Bauer
Ja das ist wohl so. Solange bis sich mein KDE-neon mal bequemt den
jeweils aktuellen microcode einzupflegen.

Das liegt nicht an KDE-neon - Intel muss die Lizenz-Bestimmungen
entsprechend anpassen, dass die Distributoren diese auch heraus
gegeben werden können.
Das hast du doch gemacht - was willst du denn dann noch!?

Ich hatte geraten, besser den Paketmanager zu nehmen. Aber wenn es
kritisch ist, und das Update sich heraus zögert, hat er es richtig gemacht.

[Juergen Ilse]

Hallo,

Post by Wolfgang Bauer
3. Schreiben Sie die Reload-Schnittstelle auf 1, um die Mikrocodedateien erneut zu laden, z.
echo 1>/sys/devices/system/cpu/microcode/reload

Fuege zwischen der Ziffer 1 und dem ">" Zeichen ein Leerzeichen ein.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Andreas Kohlbach]

Post by Juergen Ilse
Hallo,

Post by Wolfgang Bauer
3. Schreiben Sie die Reload-Schnittstelle auf 1, um die Mikrocodedateien erneut zu laden, z.
echo 1>/sys/devices/system/cpu/microcode/reload

Fuege zwischen der Ziffer 1 und dem ">" Zeichen ein Leerzeichen ein.

Btw. die Webseite hat es auch richtig. Ich fürchte, Wolfgang hat die von
Hand eingetippt. Und sollte besser "Kopieren und Einfügen" machen.

[Wolfgang Bauer]

Post by Andreas Kohlbach

Post by Juergen Ilse
Hallo,

Post by Wolfgang Bauer
3. Schreiben Sie die Reload-Schnittstelle auf 1, um die Mikrocodedateien erneut zu laden, z.
echo 1>/sys/devices/system/cpu/microcode/reload

Fuege zwischen der Ziffer 1 und dem ">" Zeichen ein Leerzeichen ein.

Btw. die Webseite hat es auch richtig. Ich fürchte, Wolfgang hat die von
Hand eingetippt. Und sollte besser "Kopieren und Einfügen" machen.

Ich habe meinen Fehler erkannt und es dann richtig gemacht.

Wolfgang

[Andreas Kohlbach]

Post by Wolfgang Bauer

Post by Andreas Kohlbach

Post by Juergen Ilse

Post by Wolfgang Bauer
3. Schreiben Sie die Reload-Schnittstelle auf 1, um die Mikrocodedateien erneut zu laden, z.
echo 1>/sys/devices/system/cpu/microcode/reload

Fuege zwischen der Ziffer 1 und dem ">" Zeichen ein Leerzeichen ein.

Btw. die Webseite hat es auch richtig. Ich fürchte, Wolfgang hat die von
Hand eingetippt. Und sollte besser "Kopieren und Einfügen" machen.

Ich habe meinen Fehler erkannt und es dann richtig gemacht.

Was ist damit sagen wollte ist, es besser nicht von Hand einzugeben.

[Bastian Blank]

Post by Wolfgang Bauer
bash: echo: Schreibfehler: Das Argument ist ungültig.
Der Befehl ist wohl falsch. Wie müßte es richtig heißen?

Der Befehl ist schon richtig. Nur das was du damit versuchst aufzurufen
mag halt keine "1" als Argument. Mein Linux mag das z.B. auch nicht.

/sys ist kein normales Dateisystem. Es werden dort direkt irgendwelche
Funktionen im Kernel aufgerufen. Deshalb können dort aber auch komische
Fehler zurückkommen.

Zu deinem Problem: Microcode will man nicht einfach im Betrieb ändern.
Es geht zwar, aber es ist undefiniert ob dein System das lange überlebt.
Nimm lieber den von deiner Distribution bereitgestellten Weg diesen
direkt beim Booten laden zu lassen.

Bastian

[Holger Marzen]

Post by Wolfgang Bauer
echo 1>/sys/devices/system/cpu/microcode/reload
bash: echo: Schreibfehler: Das Argument ist ungültig.
Der Befehl ist wohl falsch. Wie müßte es richtig heißen?

Die Kombination „Nummer“ mit „>“, also „1>“ oder „2>“ hat eine
Sonderbedeutung bei der Ausgabeumlenkung in der Bash, daher musst Du
hinter der 1 ein Leerzeichen einfügen:

echo 1 >/sys/devices/system/cpu/microcode/reload

[Bernd Mayer]

Post by Wolfgang Bauer
Ich habe mir von
https://downloadcenter.intel.com/download/27591/Linux-Processor-Microcode-Data-File
microcode-20180807.tgz geholt und entpackt. Entpackt daraus
http://www.wolfgang-bauer.at/screenshot/intel-code.jpg

Hallo,

"A newer version of this software is available. Click here to get the
latest version of this software."

https://downloadmirror.intel.com/28087/eng/microcode-20180807a.tgz


Bernd Mayer

[Wolfgang Bauer]

Post by Juergen Ilse
Hallo,
"A newer version of this software is available. Click here to get the
latest version of this software."
https://downloadmirror.intel.com/28087/eng/microcode-20180807a.tgz

Den habe ich ja nun.
Aber ich muß den Intel-microcode, nachdem Linux gestartet ist,
erst laden. Im BIOS ist eben der alte der beim Booten geladen wird.

Wolfgang

[Hergen Lehmann]

Post by Wolfgang Bauer
Den habe ich ja nun.
Aber ich muß den Intel-microcode, nachdem Linux gestartet ist,
erst laden. Im BIOS ist eben der alte der beim Booten geladen wird.

Wenn der Microcode an der richtigen Stelle installiert ist (spätestens
der aus dem Repository bezogene sollte das eigentlich sein), wird er
normalerweise beim Booten vom Kernel automatisch geladen. Mach' doch mal:

dmesg | grep microcode

und schau was da steht.

[Wolfgang Bauer]

Post by Hergen Lehmann
Wenn der Microcode an der richtigen Stelle installiert ist (spätestens
der aus dem Repository bezogene sollte das eigentlich sein), wird er
dmesg | grep microcode
und schau was da steht.>

Geladen aus dem Kernel wird

***@Desktop-PC:~$ dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0x8e, date = 2018-03-24
[ 0.879064] microcode: sig=0x906e9, pf=0x2, revision=0x8e
[ 0.879277] microcode: Microcode Update Driver: v2.2.

cat /proc/cpuinfo
zeigt an mehreren Stellen an

bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf

Wolfgang

[Andreas Kohlbach]

Post by Wolfgang Bauer

Post by Hergen Lehmann
Wenn der Microcode an der richtigen Stelle installiert ist (spätestens
der aus dem Repository bezogene sollte das eigentlich sein), wird er
dmesg | grep microcode
und schau was da steht.>

Geladen aus dem Kernel wird
[ 0.000000] microcode: microcode updated early to revision 0x8e, date = 2018-03-24

^^^^^^^^^^
Das ist der Alt.

Gibt es denn keine Intel-Repos für Linux, die immer schnell die neueste
Version haben?

[Gunter Gutzeit]

Post by Gunter Gutzeit

Post by Wolfgang Bauer

Post by Hergen Lehmann
Wenn der Microcode an der richtigen Stelle installiert ist (spätestens
der aus dem Repository bezogene sollte das eigentlich sein), wird er
dmesg | grep microcode
und schau was da steht.>

Geladen aus dem Kernel wird
[ 0.000000] microcode: microcode updated early to revision 0x8e, date = 2018-03-24

^^^^^^^^^^
Das ist der Alt.
Gibt es denn keine Intel-Repos für Linux, die immer schnell die neueste
Version haben?

Der updated early to revision microcode ist doch relativ frisch! Meiner
- in meinem Testlauf - war von 2009-08-25. Ich hatte ja auch noch nie
zuvor ein Mirocode-Update auf meiner veralteten Hardware gemacht!

vgl. Message-ID: <***@gunter.gutzeit.news.arcor.de>

[Hergen Lehmann]

Post by Wolfgang Bauer
[ 0.000000] microcode: microcode updated early to revision 0x8e, date = 2018-03-24
[ 0.879064] microcode: sig=0x906e9, pf=0x2, revision=0x8e
[ 0.879277] microcode: Microcode Update Driver: v2.2.

cpuid=0x906e9 ist Kaby Lake, und laut
https://downloadcenter.intel.com/download/28039/Linux-Processor-Microcode-Data-File
ist die neueste Microcode-Revision für diese Familie gerade die 0x8e.
Stimmt also. Nicht vom Datum irre führen lassen, dank langer Beta-Phasen
liegen oft viele Monate zwischen Build und Release!

Post by Wolfgang Bauer
cat /proc/cpuinfo
zeigt an mehreren Stellen an
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf

Das ist vermutlich irreführend. Die Bugs werden durch die
Microcode-Updates ja nicht behoben, sondern es werden lediglich die
Grundlagen (u.a. neue Befehle) dafür geschaffen, das Betriebssystem und
Applikationen dies tun können.

Hergen

[Wolfgang Bauer]

Post by Juergen Ilse
Hallo,
"A newer version of this software is available. Click here to get the
latest version of this software."
https://downloadmirror.intel.com/28087/eng/microcode-20180807a.tgz

Ich sehe gerade, daß der gepatchte microcode nun auch über den
Paketmanager angeboten wird, habe ihn gleich installiert.

Wolfgang