On Thu, Jan 18, 2018 at 10:07:17PM +0000, Luca Costantino wrote: > Buonasera lista > > Ho scaricato il tool messo a disposizione su GitHub > https://github.com/speed47/spectre-meltdown-checker/blob/master/spectre-meltdown-checker.sh > per > controllare se il proprio sistema è disponibile. > > Ho installato il l'ultimo pacchetto intel-microcode (datato 8 gennaio > 2018), eppure mi ritrovo ancora il sistema vulnerabile nella parte iniziale > del secondo attacco... > Immagino che per mitigare gli altri attacchi debba aspettare almeno 4.5, > giusto? > > SID
> # ./spectre-meltdown-checker-0.31/spectre-meltdown-checker.sh > Spectre and Meltdown mitigation detection tool v0.31 > > Checking for vulnerabilities against running kernel Linux 4.14.0-1-amd64 #1 > SMP Debian 4.14.2-1 (2017-11-30) x86_64 > CPU is Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz Io non capisco, forse sbaglio qualcosa, non riesco neanche a trovare linux-image-4.14.0-1-amd64 su packages.debian.org https://packages.debian.org/search?keywords=linux-image-4.14.0&searchon=names&suite=unstable§ion=all https://packages.debian.org/search?keywords=linux-image-4.14.0-1-amd64&searchon=names&suite=all§ion=all Detto questo la situazione fra old stable, stable, testing, unstable ed experimental è assolutamente eterogenea. Quello che si osserva in una potrebbe non essere presente in un altra ecc ecc. Penso che questo sia il momento di verificare se ci siano aggiornamenti, di tenere pulito i vari sources.list(.d/*) e i vari preferences(.d/*), riducendo magari il "missaggio" delle release. Del resto spectre-meltdown-checker.sh sembra abbastanza affidabile, esegue diversi controlli per verificare la presenza di soluzioni per la stessa falla. Meltdown ad esempio (l'unico per cui in stretch ad oggi ci sia una soluzione), viene verificato così: if sys_interface_check "/sys/devices/system/cpu/vulnerabilities/meltdown"; then # this kernel has the /sys interface, trust it over everything sys_interface_available=1 else _info_nol "* Kernel supports Page Table Isolation (PTI): " kpti_support=0 kpti_can_tell=0 if [ -n "$opt_config" ]; then kpti_can_tell=1 if grep -Eq '^(CONFIG_PAGE_TABLE_ISOLATION|CONFIG_KAISER)=y' "$opt_config"; then _debug "kpti_support: found option "$(grep -E '^(CONFIG_PAGE_TABLE_ISOLATION|CONFIG_KAISER)=y' "$opt_config")" in $opt_config" kpti_support=1 fi fi if [ "$kpti_support" = 0 -a -n "$opt_map" ]; then # it's not an elif: some backports don't have the PTI config but still include the patch # so we try to find an exported symbol that is part of the PTI patch in System.map kpti_can_tell=1 if grep -qw kpti_force_enabled "$opt_map"; then _debug "kpti_support: found kpti_force_enabled in $opt_map" kpti_support=1 fi fi if [ "$kpti_support" = 0 -a -n "$vmlinux" ]; then # same as above but in case we don't have System.map and only vmlinux, look for the # nopti option that is part of the patch (kernel command line option) kpti_can_tell=1 if ! which strings >/dev/null 2>&1; then pstatus yellow UNKNOWN "missing 'strings' tool, please install it, usually it's in the binutils package" else if strings "$vmlinux" | grep -qw nopti; then _debug "kpti_support: found nopti string in $vmlinux" kpti_support=1 fi fi fi Di tutti questi metodi attualmente solo questo mi da un risultato: grep -E '^(CONFIG_PAGE_TABLE_ISOLATION|CONFIG_KAISER)=y' oltre a dmesg | grep -i isolation. Di recente in testing sono entrati gli aggiornamenti dei microcode, per mitigare Spectre, credo la seconda variante. Possibile che SID non abbia nessuna patch e/o microcode? C'è una tale mole di lavoro generata da queste falle e dalla relativa corsa al rimedio, che sinceramente anche se fosse non riuscirei a fargliene una cola. Ciao -- Felipe Salvador
