Some questions regarding the use of time-based side channels in blacksmith about blacksmith HOT 3 CLOSED

Hi @hariv,
Thanks for your interest in Blacksmith. Let me briefly answer your questions:

If I understood correctly, the find_bank_conflicts() method of DramAnalyzer is using a timing side-channel to find addresses that map to each DRAM bank.

Yes, exactly. We use the bank-conflict timing channel (i.e., two subsequent accesses to different rows of the same bank require a PRECHARGE and are slower than accessing two rows of different banks) to detect same-bank addresses. In this way, we build cluster of addresses that belong to the same bank.

However, since blacksmith also uses DRAMA to figure out the DRAM functions to map physical addresses to the DRAM geometry (channel, rank, bank, row, etc) what is the need for this side channel?

The current version of Blacksmith does not include DRAMA anymore. As we were always running Blacksmith on the same machine (i7-8700K) in our evaluation and running DRAMA takes a bit of time (also, sometimes is unreliable), we decided to hard-code the bank/rank functions (see matrices in DRAMAddr.cpp). However, what you can see in DramAnalyzer.cpp is basically a leftover from this implementation. find_bank_conflicts is still there because later we use these addresses (e.g., in DramAnalyzer::count_acts_per_ref) but it could easily be replaced by using the DramAddr struct instead.

find_bank_conflicts() checks if the time that is taken to access 2 addresses is above a threshold to determine if the 2 addresses belong to the same bank. How did you determine this threshold? My understanding is that the code is looking for Row buffer misses when accessing the 2 addresses (which would take longer implying that they belong to the same bank), but how did you set a value to the threshold?

If you print the time measurements and create a histogram out of it you will see that there are two peaks: one with a low timing for accesses to two different banks and one with a high timing for same-bank accesses. You can then take the value in between these two peaks as the threshold. Of course, you could automate this too but as our determined value worked well on all nodes we just hard-coded it.

Is the threshold dependent on each individual DIMM or does it depend on the microarchitecture?

There might be small differences across DIMMs but if you choose the threshold according to the strategy explained above, you should be fine. Yes, the threshold might be different for other microarchitectures.

Also, why is it that the same pair of addresses is checked twice? Is this done to account for jitter?

Yes, exactly. We just do this to increase the reliability of the results.

Lastly, the hammer_sync() method of TraditionalHammerer uses a timing side-channel to detect the start of a refresh interval to synchronize hammering within the interval. The timing side-channel uses 2 addresses in the same bank in order to do the sync. Is there any reason as to why the method uses 2 addresses? Can detecting the start of a refresh be detected just by accessing a single address?

Note that TraditionalHammerer uses n-sided (TRRespass) patterns and not frequency-based patterns. We use two addresses there to evict each other's data from the row buffer. I think that if you would use only one address, after having accessed it one time you would always see a low timing (even if you flushed it from the CPU caches via clflushopt) because data will be served by the row buffer.

I hope this helps. Thank you, I wish you a happy new year too!
Patrick

from blacksmith.

Thank you for the response @pjattke. This clears most of my questions. I still have a question on using 2 addresses to detect a REFRESH. Say I repeatedly access only one address, a``. After the first access (which does not have be served by the row buffer), all subsequent accesses to a1` would be served by the row buffer, resulting in low timing for all these accesses as you had pointed out.

However, if a particular row (one that does not contain a1) were to be refreshed sometime during these repeated accesses, wouldn't that row now be placed in the row buffer, and thus, the next access to a1 would be slower (i.e. high timing when compared to other accesses when a row was not refreshed)? Thus, wouldn't accessing a single address repeatedly be sufficient to detect a REFRESH?

from blacksmith.

Hi @hariv
Sorry, I misunderstood your last question. Of course, you can also use a single address to detect refreshes. Indeed, you can see in FuzzingParameterSet.cpp::randomize_parameters that there is a parameter num_aggs_for_sync that decides on the number of aggressors to use for synchronization (however, it was always set to 2 as it turned out to not matter).

from blacksmith.