Spectre/meltdown kernelfrissítés...

 ( zslaszlo | 2018. január 25., csütörtök - 10:48 )

Nos gondoltam teszek egy próbát a kisgépemmel, ami igen régi és gyenge. (Asus EEE PC 1001) (Intel) Íme az eredmények:


$ sudo sh spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.23

Checking for vulnerabilities against live running kernel Linux 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:50 UTC 2017 i686
spectre-meltdown-checker.sh: 442: spectre-meltdown-checker.sh: /vmlinuz-4.4.0-104-generic=/boot//vmlinuz-4.4.0-104-generic: not found

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel: YES (745 opcodes found, which is >= 70)
> STATUS: NOT VULNERABLE (heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
* Hardware (CPU microcode) support for mitigation: NO
* Kernel support for IBRS: NO
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* Mitigation 2
* Kernel compiled with retpoline option: NO
* Kernel compiled with a retpoline-aware compiler: NO
> STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): NO
* PTI enabled and active: NO
> STATUS: VULNERABLE (PTI is needed to mitigate the vulnerability)

A false sense of security is worse than no security at all, see --disclaimer

És a frissítés után:


sudo sh spectre-meltdown-checker.shSpectre and Meltdown mitigation detection tool v0.32

Checking for vulnerabilities on current system
Kernel is Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:07 UTC 2018 i686
CPU is Intel(R) Atom(TM) CPU N450 @ 1.66GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: NO
* CPU indicates IBRS capability: NO
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: NO
* CPU indicates IBPB capability: NO
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: NO
* CPU indicates STIBP capability: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: NO
* Vulnerable to Variant 3: NO

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel: YES
> STATUS: NOT VULNERABLE (744 opcodes found, which is >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: NO
* Currently enabled features
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* IBPB enabled: NO
* Mitigation 2
* Kernel compiled with retpoline option: NO
* Kernel compiled with a retpoline-aware compiler: NO
* Retpoline enabled: NO
> STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): NO
* PTI enabled and active: NO
* Running under Xen PV (64 bits): NO
> STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)

A false sense of security is worse than no security at all, see --disclaimer

És az idők. Persze nem tudományos számításokat végzek a gépen, csak napi használatra van. Így ezeket mértem. Íme:

Rendszerindítás: 50sec
Chromium megnyitása: 8sec
Youtube oldal betöltése: 14sec
Videó indítása: 7sec

És a frissítés után:

Rendszerindítás: 47sec !!! :)
Chromium megnyitása: 8sec
Youtube oldal betöltése: 11sec !!! :)
Videó indítása: 5sec !!! :)

Mint látszik, a frissítés után gyorsabb lett a rendszer...

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

a blog oldalt szetnyomja a code resz.

____________________
http://szoftvervasarlas.co.hu - szoftverek legjobb áron

Valóban, csak nem tudom miért. Szabályosan helyeztem el a tag-eket, szóval nem értem. Javítanám, de hogyan?

Biztos nem felejtettél el valamit lezárni? Szerintem vedd ki őket mind, jobb anélkül :)

Ez még régi inorder atom, nem? Csak out-of-order esetén lehet egyáltalán sebezhető.

Jaja, ez még nem out-of-orderes, amiről az egész cirkusz szól. Ez még Bonnell.

Az intel az Atom vonalon a Silvermont-nál vezette be az out-of-order execution-t, érintett is az összes mindhárom variant-ban.

A Pentium vonalon pedig a P6 mikroarchitektúra hozta be az out-of-order-t, innentől potenciálisan mindegyik érintett lehet, de az Intel csak a Nehalem-től kezdve ismerte el, a közte levő ~10 évnyi generációról kussol. Mindenesetre igyencsak valószínű, hogy minden intel CPU a Pentium Pro ill. Pentium II óta érintett mindhárom sérülékenységben.

Igen.
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 28
model name : Intel(R) Atom(TM) CPU N450 @ 1.66GHz
stepping : 10
microcode : 0x107
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dtherm
bugs :
bogomips : 3332.70
clflush size : 64
cache_alignment : 64
address sizes : 32 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 28
model name : Intel(R) Atom(TM) CPU N450 @ 1.66GHz
stepping : 10
microcode : 0x107
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 1
initial apicid : 1
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dtherm
bugs :
bogomips : 3332.70
clflush size : 64
cache_alignment : 64
address sizes : 32 bits physical, 48 bits virtual
power management:

Gondolom, egy nem sebezhető gép esetében, azaz.., ha a patch lassítana a processzor azon "elágazás becslésén", azaz annak működésén - és amely technológia egyébként a műveleti sebesség gyorsítására lett kitalálva, és ugye, ennél a processzornál nem létezik, - nem vitatható, hogy nem okoz lassulást. (Lassú dög az születése óta, szép, hogy nincs hova lassulnia...)

Szimplán nincs rajta bekapcsolva a javítás.

Igazából nem a foltok miatt gyorsabb, hanem az új verziók gondolom optimalizáltak, emiatt van egy alapvető gyorsulás, amiből a patch levesz ugyan egy kicsit, de még így is pozitív az egyenleg.

A másik, hogy az ilyen checker és tester progikban nem lehet megbízni, mivel nem a sérülékenységet tesztelik azt kihasználó kóddal, hanem csak azt nézik meg, hogy milyen kernel, mikrokód, stb. van fent, és abból számolják vissza, hogy elvileg sebezhető-e. A kettő nagyon nem ugyanaz.

Túl régi verziót használsz ebből a Spectre-Meltdown-tester-ből (0.23), már kint van a 0.32-es is, klónozd újra gitről: git clone https://github.com/speed47/spectre-meltdown-checker.git). Főleg a Spectre1 elleni legacy (opcode) detektálása nagyon megbízhatatlan, megszámolja, hogy a kernelben a vonatkozó opkódot száma 70 felett van-e, és a 69-nél is azt jelzi, hogy sebezhető, ami pedig bullshit (nálam 63 a megfelelő opcode-ok száma, így azt írja, hogy VULNERABLE, de nagyon az az érzésem, hogy hibásan következtet, és már védve vagyok Spectre1 ellen is). Az újabb verziók már a /sys/-ből kérdezik le a kerneltől, hogy milyen foltozás van fent és be van-e kapcsolva.


„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum