Egyes Ubuntu 16.04 felhasználóknál is gondot okozott a Meltdown patch

 ( trey | 2018. január 11., csütörtök - 7:55 )

Miután az Ubuntu kiadta a Meltdown javítást tartalmazó kerneleit, több felhasználó is arra panaszkodott, hogy a 4.4.0-108 jelű kernelt indítva a rendszere bootoláskor összeomlott. A Launchpad-en indított #1742323-as hibajegy is erről számol be. Természetesen az érintett felhasználók bootkor a korábbi kernelt kiválasztva tovább használhatták gépüket. Az Ubuntu 24 órán belül reagált a problémára, kiadta a 4.4.0-109-es kernelt, amely a visszajelzések szerint orvosolta a boot crash problémát.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Hát, a Spectre javítások még tényleg nincsenek benne... :(

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial

$ uname -a
Linux szeimgep 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

$ cat /proc/cpuinfo | grep "model name"
model name : Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz

$ wget https://raw.githubusercontent.com/Eugnis/spectre-attack/master/Source.c
$ gcc -std=c99 Source.c -o spectre.out
$ ./spectre.out
Putting 'The Magic Words are Squeamish Ossifrage.' in memory, address 0x400cf8
Reading 40 bytes:
Reading at malicious_x = 0xffffffffffdfec58... Unclear: 0x54='T' score=934 (second best: 0x01='?' score=724)
Reading at malicious_x = 0xffffffffffdfec59... Unclear: 0x68='h' score=997 (second best: 0x01='?' score=755)
Reading at malicious_x = 0xffffffffffdfec5a... Unclear: 0x65='e' score=997 (second best: 0x01='?' score=773)
Reading at malicious_x = 0xffffffffffdfec5b... Unclear: 0x20=' ' score=995 (second best: 0x01='?' score=738)
Reading at malicious_x = 0xffffffffffdfec5c... Unclear: 0x4D='M' score=995 (second best: 0x01='?' score=723)
Reading at malicious_x = 0xffffffffffdfec5d... Unclear: 0x61='a' score=997 (second best: 0x01='?' score=759)
Reading at malicious_x = 0xffffffffffdfec5e... Unclear: 0x67='g' score=997 (second best: 0x01='?' score=720)
Reading at malicious_x = 0xffffffffffdfec5f... Unclear: 0x69='i' score=999 (second best: 0x01='?' score=703)
Reading at malicious_x = 0xffffffffffdfec60... Unclear: 0x63='c' score=996 (second best: 0x01='?' score=737)
Reading at malicious_x = 0xffffffffffdfec61... Unclear: 0x20=' ' score=996 (second best: 0x01='?' score=779)
[....]

A readme https://github.com/Eugnis/spectre-attack azt mondja, hogy ha ezt látom, akkor sebezhető vagyok.

Ugyanezt egy ősrégi gépen:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial

$ uname -a (régi kernel, még nem frissítettem)
Linux zajos 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ cat /proc/cpuinfo | grep "model name"
model name : Intel(R) Pentium(R) D CPU 2.66GHz

$ wget https://raw.githubusercontent.com/Eugnis/spectre-attack/master/Source.c
$ gcc -std=c99 Source.c -o spectre.out
$ ./spectre.out
Putting 'The Magic Words are Squeamish Ossifrage.' in memory, address 0x400cf8
Reading 40 bytes:
Illegal instruction (core dumped)

http://oscomp.hu/depot/spectre_attack.log

A jelek szerint én nem vagyok érintett, pedig semmit sem frissítettem még. Ezek szerint az AMD-nek igaza volt, hogy ha a BPF JIT ki van kapcsolva, akkor a Spectre sem működik, nem csak a Meltdown.

írd át a CACHE_HIT_THRESHOLD értékét 80-ról 120-ra, és nézd meg úgy is. Egyébként a Spectre ellen ki milyen patchre számít? Ezt nem lehet szoftverből javítani, legfeljebb elfedni a hatását (mondjuk hogy ellenőrizetlen user input ne tudjon kutakodni a memóriában, pl. JS a Firefoxban). A kernel patchek a 3-as variációra szólnak (a Meltdown), hogy userspaceből ne lehessen a kernel memóriában kutakodni (és ez sem javítás, egyszerűen a process címterében nem lesz többé ott a kernel memória).

Igazad van, így működik. Azt nem tudom tesztelni, hogy patchelve mi a helyzet, mert még nem érkezett új kernel.

Ugyanez lesz a helyzet, ezt nem lehet megoldani egy kernel patch-el.

Az szar ügy. Akkor megszívtuk.

Akkor maximum még több helyen kell tiltani a dzsuvaszkriptet-t, mint eddig.

A Firefoxban pl. úgy orvosolják jelenleg, hogy lerontják a nagy felbontású timerek nagy felbontását, hogy ne lehessen JS-ből memóriahozzáférési-időt mérni. És ezer +1 ilyen hackre lesz szükség minden olyan helyen, ahol user inputnak lehetősége van rávenni a programot, hogy hasonló memóriahozzáférések idejét mérhesse.

Gyönyörű...
Persze lehetne egyszerűen orvosolni, a JS teljes tiltásával, de akkor a mai web java része használhatatlanná válik...

Az RDTSC végrehajtását nem lehet kernel szinten tiltani? Vagy lehet, de akkor egy csomó cucc nem fog menni?

Nem tudom, lehet-e, de akkor meg ott van helyette a HPET. Most minden nagyfelbontású timert tiltsunk be?

Nem tudom. Inkább hagyjunk nyitva egy ekkora rést?

Hát most épp tömködi mindenki, ahogy tudja. Majd meglátjuk, milyen romok maradnak a végén :)

Na ja, csak nehogy mi is a romok alá kerüljünk. :/

Raspberry Pi-t, olcsó Android mobilt meg 2013 előtt gyártott Atom processzoros PC-ket kell használni és a romok felett maradsz. :-)


Normális HUP-ot használok!

Mobilból butafónom van, az tuti mentes ettől a mizériától. A másik kettő biztos nagyon "kellemes" lenne. :P

Én átírtam. Lefordítottam, de nincs változás. Ilyen minden sor:
Reading at malicious_x = 0xffffffffffdfebb6... Success: 0xFF='?' score=0
Gondolom ez jó.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Az jó, de lehet, hogy más értékkel működni fog, elsőre nálam sem ment.

Értem. Kösz. Akkor majd növelem az értéket, aztán meglátjuk hol lesz változás.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Na ha valakinek nem lett volna tiszta: EZÉRT nem megy be 17.04-be, és ezért a legértelmesebb döntés azt úgy hagyni, ahogy van!
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

+1 :)
De mi már tegnap megmondtuk...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Akkor ez lehet az oka a következőnek:
1) Tegnap (jan 10) este az otthoni Ubuntu 16.04-em kernelt frissített. Innen nem látom, milyen verzióra, de szerintem a Meltdown-os volt.
2) Ma (jan 11) reggel a munkahelyemen indítottam a frissítést, de nem talált frissítendőt.

Visszavonták a csomagot?

Amúgy az otthoni masinámon nem volt probléma. Egy Python-NumPy-s cuccomon, amin épp dolgozok, 1.5% lassulást mértem gyorsan.

Ez tényleg érdekes.
Nálam most ez van fenn: 4.4.0.109.114
A packages.ubuntu.com-on: 4.4.0.104.109
--
♙♘♗♖♕♔

Én reggel a 18.04-en jártam így, a 17.10-es verziónál viszont nem tapasztaltam ezt a hibát.

Nem csak az Ubuntu, Mint alatt se leányregény a történet. A gép a frissített a 4.13-as kernelre és magában ugyan rendesen elindult, de ha dokkolóban indítom el, akkor megáll a grub után, mint a cövek. A megoldás végül az előző kernelre (4.10) visszatérés volt.

TP x230, i5, Linux Mint 18.3 Cinnamon

16.04-es Ubuntun a vmlinuz-4.4.0-109-generic image-gel (tehát a patch első patchjével) lefagyott a host gép VirtualBox VM boot induláskor (kétszer is, többször nem próbáltam).

"Megoldásként" az előző kernelre visszatértem grub menűből (nem lett autoremove-olva), és azzal már működik, ahogy régen is. ("sudo dkms autoinstall" után, ami a vbox kernel modul újraforgatása miatt kellett, mert az valamiért le lett törölve időközben.)