Microarchitectural Data Sampling (MDS, #ZombieLoad)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Microarchitectural Data Sampling (MDS, #ZombieLoad)

Kevin Price-6
Hi, Ihr Lieben!

Diesmal hat intel einige Betriebssystem-Herstellenden anscheinend etwas
weniger katastrophal spät überrascht als in den von intel verursachten
Desastern Meltdown/Spectre vor bald zwei Jahren. Folglich hat diesmal
linux-upstream, vermutlich Einzelpersonen unter strikten intel-NDAs
mitgespielt, Software-Patches gegen deren wiederholtes Hardware-Versagen
langwierig entwickelt, und zum diesmaligen Disclosure-Tag (der vmtl.
durch Microsoft/Apple oder so dominierend ausgewählt wurde) wahnsinnig
schnell Patches integriert.

Das ist aber eine Schuldumkehr: Ich sehe es schlichtweg nicht ein, dass
Freie, zumeist ehrenamtlich entwickelte Software, auf diese Weise enorm
ressourcenintensive Workarounds bauen muss, um Herstellungsfehler
auszubügeln, nur weil Herstellende bereits viel deren defekten Mists
verkauft haben. Sobald Anbieter/innen (Sicherheits-)Fehler erkennen,
erwarte ich darauf _zeitnah_ aufmerksam gemacht zu werden.

Daß intel den linux-upstream-Entwickler/innen nun Getränke schuldet,
finde ich das Understatement des Jahrzehnts von G. K.-H.

Weil Linux für debian zentral bedeutsam ist, hat auch debian die Patches
super schnell (jedenfalls in stretch und sid) durchgereicht. Was mich
jedoch u. a. entsetzt, ist dass die zur Heilung u. a. _benötigten_ und
laut intel geeigneten (?) Microcode-Patches Monate alt sind. (Bsp. hier:
"microcode updated early to revision 0xb4, date = 2019-04-01"
https://twitter.com/mister_burns/status/1128781132122738690 )

Was bewirkt eine so insgesamt grauenhafte Informationspolitik von intel?
Ist es im Gewinnstreben die Angst davor, an Vertrauen oder Aktienkurs zu
verlieren, und dafür lieber Abermillionen User der Unsicherheit
auszuliefern? Jedenfalls bei mir wirkt das enorm kontraproduktiv: intel
hat IMHO nun so oft so massiv versagt, und zwar besonders auch in der
Fehlerkultur, meine künftigen intel-Kaufentscheidungen überlege ich mir
nun _sehr_ viel genauer. Alternativen existieren ja, und so dermaßen
enttäuscht wurde ich von Letzteren noch nicht.

https://twitter.com/mister_burns/status/1128785896755666945 habe ich
soeben nochmals nachgeprüft: Lenovo's letztes "BIOS"-Update hat
Microcode 0x8E und wurde mir ausgeliefert ab 2019-04-11 bis heute. Das
enthält noch überhaupt keine MDS-Mitigation und wird mir als aktuell
angedreht, WTF, Lenovo. (Sind Andere weniger schlimm?)

Was mich momentan recht dringend interessiert: Weiß jemand von Euch, ob
oder wann stretch-backports (linux-4.19) gepatcht wird?

Liebe Grüße
Kevin

Reply | Threaded
Open this post in threaded view
|

Re: Microarchitectural Data Sampling (MDS, #ZombieLoad)

Alexander Dahl-2
Moin,

On Thu, May 16, 2019 at 02:52:41AM +0200, Kevin Price wrote:
> Weil Linux für debian zentral bedeutsam ist, hat auch debian die Patches
> super schnell (jedenfalls in stretch und sid) durchgereicht. Was mich
> jedoch u. a. entsetzt, ist dass die zur Heilung u. a. _benötigten_ und
> laut intel geeigneten (?) Microcode-Patches Monate alt sind. (Bsp. hier:
> "microcode updated early to revision 0xb4, date = 2019-04-01"
> https://twitter.com/mister_burns/status/1128781132122738690 )

FWIW, es gibt ein Update des Pakets 'intel-microcode' für sid und
stretch-security, siehe DSA-4447-1.

https://security-tracker.debian.org/tracker/source-package/intel-microcode

> https://twitter.com/mister_burns/status/1128785896755666945 habe ich
> soeben nochmals nachgeprüft: Lenovo's letztes "BIOS"-Update hat
> Microcode 0x8E und wurde mir ausgeliefert ab 2019-04-11 bis heute. Das
> enthält noch überhaupt keine MDS-Mitigation und wird mir als aktuell
> angedreht, WTF, Lenovo. (Sind Andere weniger schlimm?)

Ich glaub auf BIOS-Updates kann man lange warten. Gerade für ältere
Hardware geb ich mich da keinen Illusionen mehr hin.

Grüße
Alex

--
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN     | speech censured, the first thought forbidden, the
 X  AGAINST      | first freedom denied, chains us all irrevocably.«
/ \ HTML MAIL    | (Jean-Luc Picard, quoting Judge Aaron Satie)

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Microarchitectural Data Sampling (MDS, #ZombieLoad)

Martin Steigerwald
Alexander Dahl - 16.05.19, 10:53:

> On Thu, May 16, 2019 at 02:52:41AM +0200, Kevin Price wrote:
> > Weil Linux für debian zentral bedeutsam ist, hat auch debian die
> > Patches super schnell (jedenfalls in stretch und sid)
> > durchgereicht. Was mich jedoch u. a. entsetzt, ist dass die zur
> > Heilung u. a. _benötigten_ und laut intel geeigneten (?)
> > Microcode-Patches Monate alt sind. (Bsp. hier: "microcode updated
> > early to revision 0xb4, date = 2019-04-01"
> > https://twitter.com/mister_burns/status/1128781132122738690 )
> FWIW, es gibt ein Update des Pakets 'intel-microcode' für sid und
> stretch-security, siehe DSA-4447-1.
>
> https://security-tracker.debian.org/tracker/source-package/intel-micro
> code

Und ein passendes Kernel-Update und einen aktualisierten spectre-
meltdown-checker.

Debian war sehr schnell.

Und ich bin weiterhin der Meinung: CPUs müssen Open Hardware werden.

Ciao,
--
Martin


Reply | Threaded
Open this post in threaded view
|

Re: Microarchitectural Data Sampling (MDS, #ZombieLoad)

Stefan Baur
Am 16.05.19 um 13:31 schrieb Martin Steigerwald:
> Und ich bin weiterhin der Meinung: CPUs müssen Open Hardware werden.

Debian für ppc64le existiert, OpenPOWER existiert. ;-)

<https://www.heise.de/ix/meldung/Vollstaendig-quelloffen-Linux-mit-einem-OpenPOWER-Server-einsetzen-3875980.html>

(Leider hat sich Thomas Krenn mittlerweile wieder aus dem
OpenPOWER-Vertrieb verabschiedet, mangels Nachfrage. Aber es gibt noch
ein paar andere Anbieter, auch für kleinere, desktoptaugliche Mainboards
mit OpenPOWER. Nur Laptops sind mit aktuell keine bekannt ...)

Gruß
Stefan

Reply | Threaded
Open this post in threaded view
|

Re: Microarchitectural Data Sampling (MDS, #ZombieLoad)

Martin Steigerwald
Stefan Baur - 16.05.19, 13:36:

> Am 16.05.19 um 13:31 schrieb Martin Steigerwald:
> > Und ich bin weiterhin der Meinung: CPUs müssen Open Hardware werden.
>
> Debian für ppc64le existiert, OpenPOWER existiert. ;-)
>
> <https://www.heise.de/ix/meldung/Vollstaendig-quelloffen-Linux-mit-ein
> em-OpenPOWER-Server-einsetzen-3875980.html>
>
> (Leider hat sich Thomas Krenn mittlerweile wieder aus dem
> OpenPOWER-Vertrieb verabschiedet, mangels Nachfrage. Aber es gibt noch
> ein paar andere Anbieter, auch für kleinere, desktoptaugliche
> Mainboards mit OpenPOWER. Nur Laptops sind mit aktuell keine bekannt
> ...)

Ja, und ich weiß, RISC-V existiert auch.

Und ich kenne auch Talor.

Ciao,
--
Martin


Reply | Threaded
Open this post in threaded view
|

Re: Microarchitectural Data Sampling (MDS, #ZombieLoad)

Martin Steigerwald
Martin Steigerwald - 16.05.19, 14:19:

> Stefan Baur - 16.05.19, 13:36:
> > Am 16.05.19 um 13:31 schrieb Martin Steigerwald:
> > > Und ich bin weiterhin der Meinung: CPUs müssen Open Hardware
> > > werden.
> >
> > Debian für ppc64le existiert, OpenPOWER existiert. ;-)
> >
> > <https://www.heise.de/ix/meldung/Vollstaendig-quelloffen-Linux-mit-e
> > in em-OpenPOWER-Server-einsetzen-3875980.html>
> >
> > (Leider hat sich Thomas Krenn mittlerweile wieder aus dem
> > OpenPOWER-Vertrieb verabschiedet, mangels Nachfrage. Aber es gibt
> > noch ein paar andere Anbieter, auch für kleinere, desktoptaugliche
> > Mainboards mit OpenPOWER. Nur Laptops sind mit aktuell keine
> > bekannt ...)
>
> Ja, und ich weiß, RISC-V existiert auch.
>
> Und ich kenne auch Talor.

Talos von RaptorCS.

Das ist mir mit Tabor von A-EON durcheinander geraten (für AmigaOS,
läuft aber auch Linux drauf).

Ciao,
--
Martin