Oprezno sa CPU patchevima!

Izlazak prvih zakrpa za Intelov (pokazalo se i dijelom AMD-ov i ARM-ov) propust u arhitekturi mikroprocesora pokazao se zabrinjavajućim: prvo su stigla izvješća o tome kako Microsoftova zakrpa ruši (https://gizmodo.com/microsoft-pauses-meltdown-patches-for-some-amd-processo-1821906738) neka računala opremljena AMD procesorom, a zatim i njima slična izvješća o nemogućnosti pokretanja Linux računala (specifično, Ubuntu 16 - https://www.bleepingcomputer.com/news/software/meltdown-and-spectre-patches-causing-boot-issues-for-ubuntu-16-04-computers/) nakon instalacije sigurnosne zakrpe.


Windows administratori trebali bi prije pokretanja instalacije napraviti restore point ili još bolje presliku Windows particije (tako se brže i lakše stroj vraća u funkcionalno stanje), dok Linux administratori trebaju provjeriti imaju li prilikom pokretanja stroja mogućnost izbora starije verzije Linux kernela: ako novi kernel zablokira računalo, izbor starijeg kernela prilikom pokretanja riješit će problem.

Imate li ranjive Windows ili Linux poslužitelje, to su načini da ih održite na životu dok ne stigne odgovarajuća zakrpa koja ih neće rušiti.

Vote: 
5
Vaša ocjena: Nema Average: 5 (1 vote)

Komentari

Imam AMD procesor na svom Debian Jessie Desktop računalu.

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 21
model           : 2
model name      : AMD FX(tm)-4300 Quad-Core Processor
stepping        : 0
microcode       : 0x600084f
cpu MHz         : 1400.000
cache size      : 2048 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2

Instalirao sam spomenuti kernel. Nema problema sa bootom.

uname -a
Linux nnn 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08) x86_64 GNU/Linux

Ali je nalaz "negativan"

dmesg | grep isolation && echo "patched :)" || echo "unpatched :("
unpatched :(

Nije jasan status AMD u cijeloj ovoj priči. Mislim da je Intel ovdje ključan, naročito zbog servera koji su večinom Intel. Još zanimljivija je situacija sa virtualizacijom.

 https://www.cnbc.com/2018/01/03/amd-rebukes-intel-says-flaw-poses-near-zero-risk-to-its-chips.html

https://www.networkworld.com/article/3245766/virtualization/intels-processor-flaw-is-a-virtualization-nightmare.html

 

Zanimljivo je gore pročitati da će Inteli trebati do 9 mjeseci da popravi grešku na procesorima. A u ovih prvih 10 mjeseci će prodavati robu sa greškom ? Ovdje je velika šansa AMD-u, ali pošto su i njih proglasili ranjivima, teško će se i oni izvući od lažnih optužbi. Izgleda da AMD nije dosta radio na PR-u.

 

 

 

Sljedeći test samo pokazuje da u kernelu nije aktivan PTI:

$ dmesg | grep "Kernel/User page tables isolation"
[    0.000000] Kernel/User page tables isolation: disabled

Na sustavima s AMD-ovim procesorima ta opcija neće biti omogućena jer ti procesori nisu ranjivi na Meltdown.

Za stvarno testiranje ranjivosti bolje je pokrenuti test koji bi pokušao iskoristiti ranjivost procesora. Jedan takav programčić može se naći na https://github.com/raphaelsc/Am-I-affected-by-Meltdown.

Na PC-u s Intelovim 64-bitnim procesorom i Debianom 8 te starim kernelom dobije se sljedeći izlaz:

$ ./meltdown-checker
Unable to find symbol sys_call_table in /proc/kallsyms
Falling back on the alternative symbol map file (usually requires root permission): /boot/System.map-3.16.0-4-amd64...
Checking whether system is affected by Variant 3: rogue data cache load (CVE-2017-5754), a.k.a MELTDOWN ...
Checking syscall table (sys_call_table) found at address 0xffffffff81601440 ...
0xffffffff811ab370 -> That's SyS_read

System affected! Please consider upgrading your kernel to one that is patched with KPTI/KAISER
Check https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html for more details

Nakon nadogradnje kernela na v. 3.16.51-3+deb8u1 (2018-01-08), program daje sljedeće:

$ ./meltdown-checker
Unable to find symbol sys_call_table in /proc/kallsyms
Falling back on the alternative symbol map file (usually requires root permission): /boot/System.map-3.16.0-5-amd64...
Checking whether system is affected by Variant 3: rogue data cache load (CVE-2017-5754), a.k.a MELTDOWN ...
Checking syscall table (sys_call_table) found at address 0xffffffff81601440 ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...

System not affected (take it with a grain of salt though as false negative may be reported for specific environments; Please consider running it once again).