Your cpu doesn't support TSX (Transactional Synchronization Extensions)

[dandrei]

When getting the message above, does this mean that the CPU isn't affected or that Am-I-affected-by-Meltdown not able to check? I presume the latter from the note in README.md, but I figured I'd better check.

[raphaelsc]

The latter. I'll improve the checker to work without TSX

[benoitjpnet]

What is a modern CPU? Because I have a Intel(R) Core(TM) i7-4510U CPU and I have this error.

[NuclearPhoenixx]

Same problem here +1 👍

[Serphentas]

Same here with Core i7 990X

[jandrusk]

Ditto for me. Running it against Intel Pentium G6950.

[Ian321]

Same with Intel Core i7-6500U

[dlenski]

Ditto with Haswell Xeon.

I'm trying to use this excellent tool to figure out whether my bargain-basement Xen-PV VPS provider has patched around this. :worried:

[raphaelsc]

Working on it... :)

On Jan 5, 2018 5:20 PM, "Dan Lenski" notifications@github.com wrote:

Ditto with Haswell Xeon.

I'm trying to use this excellent tool to figure out whether my bargain-basement Xen-PV VPS provider has patched around this. 😟

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/raphaelsc/Am-I-affected-by-Meltdown/issues/4#issuecomment-355641574, or mute the thread https://github.com/notifications/unsubscribe-auth/ABWAc7yDB_ffnlP5IsDHfJ2VjDQVSwR9ks5tHnXWgaJpZM4RUPlu .

[diegorivera]

https://software.intel.com/en-us/blogs/2013/06/23/tsx-fallback-paths

Other fallbacks for transactions are also possible. For example gcc 4.8+ with -fgnu-tm supports falling back to a software transactional memory code path. The programmer uses the __transaction_relaxed keyword to specify transactional regions (see the specification)

[raphaelsc]

@diegorivera that's very interesting. thanks for sharing it!

[raphaelsc]

@diegorivera, @benpro, @Phoenix1747, @dlenski, @Serphentas, @jandrusk, @dandrei: fixed the issue, please pull latest changes, retry it and tell me if it worked

[diegorivera]

It works! Thanks man!

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 ... 0xffffffff812114d0 -> That's SyS_read

System affected! Please consider upgrading your kernel to one that is patched with KAISER Check https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html for more details

[dlenski]

It's working! It's so slowwwwwwwwww on Xen-PV though :-D

[raphaelsc]

@dlenski i think it may have something to do with clock source. BTW, the checker is indeed slow now when proving that a system isn't affected by meltdown. But if system is affected by meltdown, it's actually relatively fast to prove it. I need to work on that

[Serphentas]

@raphaelsc It's working now. Got MELTDOWN here.

[NuclearPhoenixx]

@raphaelsc Now experiencing another issue:

error in line:             (null) A irq_stack_union

After executing make and then ./meltdown-checker 🤔

[raphaelsc]

@Phoenix1747 what does cat /proc/kallsyms return? I think the program expects 0 address, it returns (null) which cannot be converted to number and thus the exception. Let me write a patch to ignore lines with (null). does any entry in /proc/kallsyms return a valid address (without running cat as root)?

[raphaelsc]

@Phoenix1747 program patched, pleaase pull changes and try again

[NuclearPhoenixx]

@raphaelsc It's working now, although I have to run it as root but not to worry. Thanks for the quick fix!