comsec-group / blacksmith

Next-gen Rowhammer fuzzer that uses non-uniform, frequency-based patterns (IEEE S&P '22).

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Could not find conflicting address sets

DominikBucko opened this issue · comments

I'm not able to get past this error even when recompiling with different NUM_BANKS value - I tried 4, 8, 16 and even 32. Always the same output. I'm not sure what other parameters to adjust as the error message doesn't suggest anything else.

My output is:

[+] General information about this fuzzing run:
Start timestamp:: 1637333603
Hostname: ubuntu
Commit SHA: c8e65b709a83665f9528efdedcf064abdb04859f
Run time limit: 21600 (6 hours 0 minutes 0 seconds)
[+] Printing run configuration (GlobalDefines.hpp):
DRAMA_ROUNDS: 1000
CACHELINE_SIZE: 64
HAMMER_ROUNDS: 1000000
THRESH: 495
NUM_TARGETS: 10
MAX_ROWS: 30
NUM_BANKS: 32
DIMM: 1
CHANNEL: 1
MEM_SIZE: 1073741824
PAGE_SIZE: 4096

[+] Initializing memory with pseudorandom sequence.
[-] Could not find conflicting address sets. Is the number of banks (32) defined correctly?

My kernel is 5.13.0-19-generic on ubuntu 21.10

Any help is appreciated.

Please note this comment that I just added to the README:

NOTE: The DRAM address functions that are hard-coded in DRAMAddr.cpp assume an Intel Core i7-8700K. For any other microarchitecture, you will need to first reverse-engineer these functions (e.g., using DRAMA or TRResspass' DRAMA) and then update the matrices in this class accordingly.

For these hard-coded functions, we only consider 16 banks (1 rank) or 32 banks (2 ranks). The number of ranks can be controlled via the --ranks <value> parameter passed to Blacksmith. This means, based on the number of ranks we load the proper DRAM addressing functions.

The error you observe, however, happens one step before and is probably due to a (system-specific) threshold (#define THRESH 495 in GlobalDefines.hpp) that does not seem to work on your machine. This threshold is a leftover from a previous implementation of DRAMA within Blacksmith. However, as the implementation was rudimentary and we always use the same evaluation machine, we removed this dead code. You should be able to determine this threshold with the DRAMA tool linked above.

Thank you, I will give it a try