Greg Kroah-Hartman: Meltdown és Spectre Linux Kernel helyzetjelentés

Kernel

A helyzetjelentés elolvasható itt.

Linux párti vagyok, de érdekes hogy míg a W10-re szinte azonnal jött a frissítés, addig a stable
stretch-re még most sincs.
1.5 hete, mikor még ki sem derült a hiba, a legújabb kernelt már akkor pachelték, mikor elvileg már nem is szabadott volna.

"Linus szokatlan módon, a 4.15-ös kernel fejlesztési ciklusának végén olvasztotta be a Kernel page-table isolation patchkészletet. "

https://hup.hu/cikkek/20180102/egy_az_intel_processzorokban_levo_tervez…

"jessie 3.16.51-2 vulnerable
jessie (security) 3.16.51-3+deb8u1 fixed"

Ez mit jelent?

A sima 3.16.51-2 kernelt nem frisítik?
A 3.16.51-3+deb8u1 azt igen?
De az micsoda?

kösz

Kicsit off, de Asus-nál pl. ezt írják:

"To enhance resiliency to the side channel analysis method, ASUS will provide a solution in a forthcoming BIOS update. Together with the latest Windows OS Hot Fix update, your computer will be well protected.
Although applying the BIOS update and OS Hot Fix may mitigate the risk of the side channel analysis method, computer performance might be impacted. However, any performance impacts are workload-dependent and may vary by hardware generation and implementation by the chip manufacturer. For most users, the performance impact should not be significant."

Szóval szerintük az op.rendszer frissítés egy dolog, a megfelelö védelemhez kell a BIOS frissítés is.
Az lesz érdekes, ahol a BIOS nem fog frissülni, az op.rendszer meg igen. Nem tudom, ilyen esetekben mennyire lesz védett az adott rendszer.
Ha Asus-ékból indulok ki, akkor így nem lesz "well protected".

--
robyboy

Azok vegyenek új gépet. Várható volt sajnos.

Szerintem ha a BIOS nincs is frissítve, de az op.rendszer igen, akkor azért nem lehet akkora tragédia, mivel az op.rendszer is frissíthet microcode-ot.

Nagyon kellene egy teljesen új CPU, meg egy teljesen új op.rendszer, ami alól pl. nyugodtan lehet netbankolni. Nomeg teljesen új titkosítási algoritmus sem ártana.

Itt az idö, kukába az összes szarral, és kezdjük elölröl!

--
robyboy

( andrewjsi | 2018. 01. 08., h – 00:10 )

A 2.6.32-es RHEL kernelre épülő OpenVZ-be is bekerült a KPTI.

$ dmesg |grep 'page table isolation'
[ 0.000000] x86/pti: Kernel page table isolation enabled

Két új boot paraméterrel bővült a kernel:

$ cat Documentation/kernel-parameters.txt |grep 'page table isolation'
kpti [X86-64] Enable kernel page table isolation.
nopti [X86-64] Disable kernel page table isolation.

Intel i7-4790 procin nopti-vel 8m1s alatt fordul a kernel (-j8), kpti-vel pedig 9m2s alatt. Ez nem tűnik soknak, viszont érzésre minden sokkal lomhább lett.

12,7%-kal gyengébb a kernelfordulásod. Ez kb. reális lassulás.

Nálam most J1900 out-of-orderes proci van kéznél, Debian 9-cel.
Kapsz egy szélsőséges esetet. Ugyebár az int 80h (kernelhívás) fog lassabban kiváltódni.

Egy kernelhívásra kihegyezett kód, amit az alábbi csúnya eredményre összeütöttem: 

// kpti-speedtest.c
#include <unistd.h>
#include <fcntl.h>

int main() {
    int fd = open("/dev/null", O_WRONLY);
    char pelda = 'a';
    for (int i=0; i<20*1000*1000; i++) {
        write(fd, &pelda, 1);
    }
}

$ gcc -O2 kpti-speedtest.c -o kpti-speedtest

Először egy kpti nélkülit nézzünk, ami a Debián karácsonyi kernele.

$ cat /proc/version
Linux version 4.9.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23)

$ time ./kpti-speedtest

real 0m3,915s
user 0m1,056s
sys 0m2,856s

És következzen aminek jönnie kell: kpti-s kernel.

$ cat /proc/version
Linux version 4.9.0-5-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04)

$ dmesg | grep isol
[ 0.000000] Kernel/User page tables isolation: enabled

$ time ./kpti-speedtest

real 0m14,214s
user 0m4,396s
sys 0m9,812s

Extrém esetben harmada alá is vihető a CPU hatékonysága. Mindez csak attól függ, hogy milyen intenzív a kernelhívás a szoftverben.

Ami szerintem igazán érdekes, hogy a memóriaműveleteket hogyan érinti a dolog, hisz mondjuk a böngészők vagy a Java (Android) vagy a PHP legjobb tudomásom szerint eléggé intenzíven használják a RAM-ot, például egy <div> egy több mint kétszáz elemből álló fát hoz létre a Firefox 57-ben, és nálam a Facebook kezdőlapja 1788 elemből áll.

Épp töltök le egy Debian képfájlt, ki fogom próbálni.

Miert erintene ez a memoria muveleteket? Tudtommal csak a context-switch erintett vagyis a KPTI unmappolja az osszes, a processhez nem tartozo memoria tartomanyt. Vagyis context-switch utan lehet, hogy egy par load lassabb lesz mivel a TLB is flusholva van. De ha nem hivsz kernel kodot akkor minden megy a regibe.
--
:wq

Kipróbáltam a kódodat, köszi:

$ time ./kpti-speedtest # nopti

real 0m1.904s
user 0m0.373s
sys 0m1.516s

$ time ./kpti-speedtest # kpti

real 0m11.387s
user 0m4.741s
sys 0m6.642s

$ cat /proc/version
Linux version 2.6.32-jss.127.2 (root@bentoo) (gcc version 4.4.7 (Gentoo 4.4.7 p1.2, pie-0.4.5) ) #1 SMP Sat Jan 6 23:17:07 CET 2018

/me zokog