Minor issue with confusing output

[dlenski]

In ac2c4350a5669495e2e92f993b3897937ffec23e, if meltdown-checker reads all-zero values, it will print out a "match" to whatever the first all-zero symbol is, but then follow this up with so far so good.

$ sudo ./meltdown-checker 
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 0xffffffff81801400 ...
0xff10000000000000 -> That's unknown
so far so good...
0x0000110000000000 -> That's unknown
so far so good...
0x0000000000000000 -> That's irq_stack_union
so far so good...
0x0000000000000000 -> That's irq_stack_union
so far so good...
0xff00830000000000 -> That's unknown
so far so good...

I think that "matches" to zero values should probably be ignored. The technical paper explains that there's a bias towards reading zeroes. It appears to be a rather pronounced one on at least one of my cloud boxes.

[raphaelsc]

@dlenski actually that means it's unable to exploit meltdown. I think I need to rephrase that. Would it work if it doesn't print things like "0x0000000000000000 -> That's irq_stack_union" when there's not an actual match? Is your system patched? Because from your output, it seems your system isn't affected by meltdown

[dlenski]

Is your system patched? Because from your output, it seems your system isn't affected by meltdown

Well… I don't know in this case. It's a cloud box that reports Haswell Xeon in /proc/cpuinfo (so it should be susceptible) and it's running an ancient, unpatched Xen as PV.

I suspect that it is susceptible in theory, but that the privileged instructions required to execute meltdown-checker run sooooo slowly that it's impractical to really carry out.

[raphaelsc]

@dlenski I'll leave this issue opened for me to reproduce it and see what I can do about it. Thanks for the report!

[raphaelsc]

BTW, the output is now:

$ ./meltdown-checker 
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 0xffffffffa2a001c0 ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...

[raphaelsc]

@dlenski could please check if https://github.com/paboldin/meltdown-exploit works for you? I may consider getting closer to its approach if it does.

[dlenski]

I gave it a shot! It runs much faster on the cloud box and outputs gibberish, suggesting that it's not vulnerable. Huh! :+1:

(On the other hand, on my vulnerable laptop, it runs much slower…)

[UnserKapitaen]

@raphaelsc I tried https://github.com/paboldin/meltdown-exploit with my G4400 and it states my CPU is vulnerable whereas your script says it is not.

[raphaelsc]

@UnserKapitaen what's exactly the output of meltdown-exploit to you? i'll see what's wrong with the checker for some specific environments, maybe the lack of dynamic calculation of cache hit threshold. thanks for the report

[UnserKapitaen]

~/MeltdownTest/Am-I-affected-by-Meltdown$ ./meltdown-checker
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 0xffffffff81a00200 ...
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).

~/MeltdownTest/meltdown-exploit$ ./run.sh

looking for linux_proc_banner in /proc/kallsyms
cached = 35, uncached = 380, threshold 115
read ffffffff81a00060 = 25 %
read ffffffff81a00061 = 73 s
read ffffffff81a00062 = 20
read ffffffff81a00063 = 76 v
read ffffffff81a00064 = ff
read ffffffff81a00065 = 72 r
read ffffffff81a00066 = 73 s
read ffffffff81a00067 = 69 i
read ffffffff81a00068 = 6f o
read ffffffff81a00069 = 6e n
read ffffffff81a0006a = 20
read ffffffff81a0006b = 25 %
read ffffffff81a0006c = 73 s
read ffffffff81a0006d = 20
read ffffffff81a0006e = 28 (
read ffffffff81a0006f = 62 b
VULNERABLE
VULNERABLE ON
4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x86_64
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 94
model name      : Intel(R) Pentium(R) CPU G4400 @ 3.30GHz
stepping        : 3
microcode       : 0xba
cpu MHz         : 2000.109
cache size      : 3072 KB
physical id     : 0

If there is anything else I can do please let me know.