4 Commits
v0.28 ... v0.29

Author SHA1 Message Date
b47d505689 AMD now vuln to variant2 (as per their stmt) 2018-01-13 13:35:31 +01:00
4a2d051285 minor is_cpu_vulnerable() changes (#71)
* correct is_cpu_vulnerable() comment

As far as I can tell, the function and usage are correct for the comment
to be inverted.

Add a clarifying note as to why the value choice makes sense.

* exit on invalid varient

If this happens, it's a bug in the script. None of the calling code
checks for status 255, so don't let a scripting bug cause a false
negative.

* no need to set vulnerable CPUs

According to comment above this code:
'by default, everything is vulnerable, we work in a "whitelist" logic here.'
2018-01-13 13:16:37 +01:00
f3551b9734 Only show the name of the script, not the full path (#72) 2018-01-13 13:14:19 +01:00
45b98e125f fix some typos (#73) 2018-01-13 13:13:40 +01:00

View File

@ -8,15 +8,15 @@
#
# Stephane Lesimple
#
VERSION=0.28
VERSION=0.29
# Script configuration
show_usage()
{
cat <<EOF
Usage:
Live mode: $0 [options] [--live]
Offline mode: $0 [options] [--kernel <vmlinux_file>] [--config <kernel_config>] [--map <kernel_map_file>]
Live mode: `basename $0` [options] [--live]
Offline mode: `basename $0` [options] [--kernel <vmlinux_file>] [--config <kernel_config>] [--map <kernel_map_file>]
Modes:
Two modes are available.
@ -103,7 +103,7 @@ __echo()
# strip ANSI color codes
_msg=$(/bin/echo -e "$_msg" | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[m|K]//g")
fi
# explicitely call /bin/echo to avoid shell builtins that might not take options
# explicitly call /bin/echo to avoid shell builtins that might not take options
/bin/echo $opt -e "$_msg"
}
@ -151,15 +151,17 @@ _debug()
is_cpu_vulnerable()
{
# param: 1, 2 or 3 (variant)
# returns 1 if vulnerable, 0 if not vulnerable, 255 on error
# returns 0 if vulnerable, 1 if not vulnerable
# (note that in shell, a return of 0 is success)
# by default, everything is vulnerable, we work in a "whitelist" logic here.
# usage: is_cpu_vulnerable 2 && do something if vulnerable
variant1=0
variant2=0
variant3=0
if grep -q AMD /proc/cpuinfo; then
variant1=0
variant2=1
# AMD revised their statement about variant2 => vulnerable
# https://www.amd.com/en/corporate/speculative-execution
variant3=1
elif grep -qi 'CPU implementer\s*:\s*0x41' /proc/cpuinfo; then
# ARM
@ -174,28 +176,26 @@ is_cpu_vulnerable()
# arch 7? 7? 7 7 7 8 8 8 8
if [ "$cpuarch" = 7 ] && echo "$cpupart" | grep -Eq '^0x(c09|c0f|c0e)$'; then
# armv7 vulnerable chips
variant1=0
variant2=0
:
elif [ "$cpuarch" = 8 ] && echo "$cpupart" | grep -Eq '^0x(d07|d08|d09|d0a)$'; then
# armv8 vulnerable chips
variant1=0
variant2=0
:
else
variant1=1
variant2=1
fi
# for variant3, only A75 is vulnerable
if [ "$cpuarch" = 8 -a "$cpupart" = 0xd0a ]; then
variant3=0
else
if ! [ "$cpuarch" = 8 -a "$cpupart" = 0xd0a ]; then
variant3=1
fi
fi
fi
[ "$1" = 1 ] && return $variant1
[ "$1" = 2 ] && return $variant2
[ "$1" = 3 ] && return $variant3
return 255
echo "$0: error: invalid variant '$1' passed to is_cpu_vulnerable()" >&2
exit 1
}
show_header()
@ -609,7 +609,7 @@ check_variant1()
status=UNK
pstatus yellow UNKNOWN
else
# here we disassemble the kernel and count the number of occurences of the LFENCE opcode
# here we disassemble the kernel and count the number of occurrences of the LFENCE opcode
# in non-patched kernels, this has been empirically determined as being around 40-50
# in patched kernels, this is more around 70-80, sometimes way higher (100+)
# v0.13: 68 found in a 3.10.23-xxxx-std-ipv6-64 (with lots of modules compiled-in directly), which doesn't have the LFENCE patches,