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