comsec-group / blacksmith

Next-gen Rowhammer fuzzer that uses non-uniform, frequency-based patterns (IEEE S&P '22).
MIT License
223 stars 34 forks source link

Blacksmith terminated: Illegal instruction #3

Closed HxJi closed 2 years ago

HxJi commented 2 years ago

After setting the hugepage size to 1G and build the blacksmith successfully, the program ends with the output "Illegal Instructions" and there is no content in the stdout.log

pjattke commented 2 years ago

Hi @HxJi,

It is hard to debug your issue without any further details. Could you please provide us with some more system details (e.g., CPU [cat /proc/cpuinfo], OS [uname -a], DIMM data [sudo dmidecode -t memory]).

We could imagine that it has something to do with the code jitting we do for the frequency-based patterns. However, our implementation also includes TRRespass-like n-sided patterns for which we don't use code jitting. Hence, could you please try to use n_sided_hammer from the TraditionalHammerer so we can narrow down the issue. For this, you will need to uncomment line 57 in Blacksmith.cpp and comment out line 59. Lastly, you need to set the default value of do_fuzzing to false in line 174 of Blacksmith.cpp. After that, you can recompile and test whether n-sided patterns work. If so, it indicates that code jitting might be a problem.

Regards, Patrick

heechul commented 2 years ago

It seems that the following instruction in include/Utilities/AsmPrimitives.hpp causes the problem on pre-skylake architectures (mine was haswell-e + ddr4).

asm volatile("clflushopt (%0)\n"::"r"(p)

pjattke commented 2 years ago

Thanks, @heechul, for investigating this further. Indeed, it looks like pre-Skylake systems don't support clflushopt. I guess you could just replace it by clflush and then do lfence for serialization. It might be a bit slower as it's not optimized for parallel execution unlike clflushopt but I would assume that it still will work.

HxJi commented 2 years ago

Thanks for the reply @pjattke. I am using pre-skylake architectures and I will try to replace clflushopt with cflush and lfence. Will update the status later. And thanks @heechul for your insightful finding.

MrObvious commented 2 years ago

Can confirm, changing AsmPrimitives.hpp fixed it.

[[gnu::unused]] static inline attribute((always_inline)) void clflushopt(volatile void *p) {

ifdef DDR3

asm volatile("clflush (%0)\n" ::"r"(p) : "memory");

else

asm volatile("clflush (%0)\n"::"r"(p) : "memory"); #

Just started a few minutes ago and it still is running. nothing in stdout yet, but I will wait to see if I encounter the issue.