# DNN-Defender: An in-DRAM Deep Neural Network Defense Mechanism for
Adversarial Weight Attack

Ranyang Zhou†§, Sabbir Ahmed‡§, Adnan Siraj Rakin‡ and Shaahin Angizi†
†Department of Electrical and Computer Engineering, New Jersey Institute of
Technology, Newark, NJ, USA
‡Department of Computer Science, State University of New York at Binghamton,
NY, USA
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
§both authors contribute equally

###### Abstract

With deep learning deployed in many security-sensitive areas, machine learning
security is becoming progressively important. Recent studies demonstrate
attackers can exploit system-level techniques exploiting the RowHammer
vulnerability of DRAM to deterministically and precisely flip bits in Deep
Neural Networks (DNN) model weights to affect inference accuracy. The existing
defense mechanisms are software-based, such as weight reconstruction requiring
expensive training overhead or performance degradation. On the other hand,
generic hardware-based victim-/aggressor-focused mechanisms impose expensive
hardware overheads and preserve the spatial connection between victim and
aggressor rows. In this paper, we present the first DRAM-based victim-focused
defense mechanism tailored for quantized DNNs, named DNN-Defender that
leverages the potential of in-DRAM swapping to withstand the targeted bit-flip
attacks. Our results indicate that DNN-Defender can deliver a high level of
protection downgrading the performance of targeted RowHammer attacks to a
random attack level. In addition, the proposed defense has no accuracy drop on
CIFAR-10 and ImageNet datasets without requiring any software training or
incurring additional hardware overhead.

##  I Introduction

The far-reaching development of Deep Neural Networks (DNN) accuracy even with
low-bit-width models has recently triggered various security-associated
attacks in many applications [1, 2, 3]. Recent studies show that an adversary
can identify and manipulate a small number of vulnerable bits of off-the-shelf
well-trained DNN weight parameters to significantly compromise the output
accuracy [4, 2]. Such Bit-Flip Attacks (BFAs) have been enabled mainly due to
a manifestation of a DRAM cell-to-cell interference and failure mechanism
called RowHammer (RH) [5, 6]. RH attack is conducted when a malicious process
activates and pre-charges a specific row (i.e., aggressor row) repeatedly to a
certain threshold ($T_{RH}$) to induce bit-flips on immediate nearby rows
(i.e., victim rows). Unfortunately, by scaling down the size of DRAM chips in
the modern manufacturing process, DRAM becomes increasingly more vulnerable to
RH bit-flips [7]. Figure 1(a) shows that the RH threshold has had a
significant downward trend in recent years, e.g., the attacker needs
$\sim$4.5$\times$ fewer hammer counts on LPDDR4 (new) as opposed to DDR3 (new)
[8]. Such a threshold will almost disappear at DDR5 [9].

To prevent RH attacks, DRAM manufacturers and researchers have proposed
hardware-based victim-focused defense mechanisms to proactively refresh the
victim rows [5, 10]. However, such RH mitigation proposals have faced a huge
overhead both from latency and power consumption perspectives [11]. To
mitigate this, recent aggressor-focused swap-based mechanisms [12, 8]
proactively swap and unswap aggressors with random rows before reaching the RH
threshold. Such mechanisms can be immensely effective when the attacker does
not have knowledge of the internal DRAM organization. Assuming the attacker’s
access to this information, he/she will not track the aggressor row but the
victim row and attacks its adjacent row, making it a new aggressor row. In
this case, swapping the aggressor row with another random row is purposeless.
On the other side, prior works have approached the problem of DNN weight noise
mitigation from a software-training optimization perspective [13, 14, 15] and
DNN architecture modification [16, 17] that impose expensive training overhead
or performance/accuracy degradation.

---
Figure 1: (a) RowHammer thresholds [8], (b) Targeted bit flipping vs. random
bit flipping for an 8-bit quantized ResNet-34 on ImageNet [18] dataset and our
defence performance.

To address the above-mentioned challenges, we develop DNN-Defender as a pure
DRAM-based victim-focused defense mechanism to effectively withstand the
targeted RH bit-flip attacks on DNNs. The main contributions of this work are
as follows. (1) We design the DNN-Defender mechanism with hardware-software
support that utilizes in-DRAM swapping to protect the DNN weight parameters
not requiring any software training or imposing additional hardware overhead;
(2) We develop a partitioning method and parallelism to tailor the
performance-accuracy trade-offs with respect to the system requirements; and
(3) We extensively analyze the DNN-Defender’s applicability and efficiency in
mitigating RH vulnerability compared to recent hardware/software techniques in
the DNN domain over CIFAR-10 and ImageNet datasets. On the CIFAR-10, the
accuracy of the DNN-Defender-supported system is 91.71% while the baseline
indicates only 10.9% under bit-flip attack.

##  II Background & Motivation

###  II-A DRAM

DRAM Organization. The DRAM chip is a hierarchical structure consisting of
several memory banks as shown in Fig. 2. Each bank comprises 2D sub-arrays of
memory bit-cells that are virtually ordered in memory matrices (mats), which
have billions of DRAM cells on modern chips [19]. Each DRAM bit-cell consists
of a capacitor and an access transistor. The charge status of the bit cell’s
capacitor is used to represent binary “1” or “0” [20, 21, 22, 23].

DRAM Refreshing. Due to the DRAM bit-cell’s leakage, the amount of charge
stored on the capacitor may not be enough to correctly discriminate the data,
resulting in data corruption. To secure the data in DRAM, the system recharges
the DRAM bit-cells periodically. All banks must be idle (precharged) before a
refresh [24, 25].

DRAM Commands. In idle mode, the memory controller turns off all enabled DRAM
rows by sending the Precharge (PRE) command on the command bus. This will
precharge the Bit-Line (BL) voltage to $\frac{V_{DD}}{2}$. In the active mode,
the memory controller will send an Activate (ACT) command to the DRAM module
to activate the Word-Line (WL). Then, all DRAM cells connected to the WL share
their charges with the corresponding BL. Through this process, BL voltage
deviates from the precharged $\frac{V_{DD}}{2}$. The sense amplifier then
senses this deviation and amplifies it to $V_{DD}$ or 0 in the row buffer. The
memory controller can then send read (RD)/write (WR) commands to transfer data
to/from the sense amplifier array [20, 26].

---
Figure 2: Organization of a DRAM chip.

RowClone. Exploiting the fact that DRAM transfers an entire row of data to the
corresponding row buffer during the read operation, RowClone [24] has been
developed as a simple and efficient mechanism to enable a bulk in-memory copy
operation ($<$100ns) from a source row to a destination row completely in the
DRAM sub-array. RowClone eliminates the need to transfer data over the memory
channel. The memory controller manages this by issuing two back-to-back ACT
commands first to the source and then the destination without PRE command in
between with almost negligible cost. By using this method, the latency and
power consumption of a bulk copy operation can be reduced by a factor of 11.6
and 74.4, respectively [24].

###  II-B Row Hammer-based DNN Weight Attack & Mitigation

The BFA progressively searches for vulnerable bits by first performing a bit
ranking within each layer based on gradient [2]. Considering a weight
quantized DNN, the weight matrix can be parameterized by two complement
representations $\\{{\bm{\mathsfit{B}}}_{l}\\}_{l=1}^{L}$, where
$l\in\\{1,2,...,L\\}$ is the layer index. BFA computes the gradient w.r.t.
each bit of the model ($|\nabla_{{\bm{\mathsfit{B}}}_{l}}\mathcal{L}|$) where
$\mathcal{L}$ is the inference loss function. At each iteration, the attacker
performs two key attack steps: i) Inter-layer search and ii) intra-layer
search; where the goal is to identify a vulnerable weight bit and flip it.
Given a sample input $x$ and label $t$, the BFA [2] algorithm tries to
maximize the following loss function ($\mathcal{L}$):

$\begin{gathered}\max_{\\{\hat{{\bm{\mathsfit{B}}}}_{l}\\}}~{}\mathcal{L}\Big{(}f\big{(}{\bm{x}};\\{\hat{{\bm{\mathsfit{B}}}}_{l}\\}_{l=1}^{L}\big{)},{{\bm{t}}}\Big{)},\end{gathered}\vspace{-5pt}$
(1)

while ensuring the hamming distance between the perturbed weight tensor by BFA
($\hat{{\bm{\mathsfit{B}}}}_{l=1}^{L}$) and initial weight tensor
($\\{{\bm{\mathsfit{B}}}_{l}\\}_{l=1}^{L}$) remains minimum. Finally, the
attack efficiency can be measured by the number of bit-flips required to cause
DNN malfunction.

---
Figure 3: Adversarial weight RowHammer attack in the $k_{th}$ layer of a DNN.

Figure 1(b) illustrates how the DNN accuracy degrades under a few (less than
5) targeted bit-flips using DeepHammer attack [27] in an 8-bit quantized
ResNet-34 running the ImageNet [18] dataset as opposed to over 100 random bit-
flip attacks. Figure 3 illustrates how such an adversarial weight attack is
conducted in an $L$-layer DNN on the target $W_{l_{k1}}$ = 1001, i.e., the
weight located in the $l_{k}$ layer. The malicious process continuously
hammers the aggressor row in $a$-address and induces bit-flips on adjacent
victim rows ($a-1$ and $a+1$) holding $W_{l_{k1}}$. As a result, such a
single-sided RH attack changes the weight value (herein,
1001$\rightarrow$0011).

Both hardware-level and software-level mitigation mechanisms have been
actively followed to eliminate, control, or reduce RH vulnerability on next-
generation DDRx systems. The hardware-based efforts can be classified into two
categories, i.e., victim-focused and aggressor-focused mechanisms. The system
manufacturers consider victim-focused RH defense solutions such as increased
refresh rates and hardware RHP [28, 29, 7]. Along this line, Target Row
Refresh (TRR) [10] and other counter-based detection methods [30, 31, 32]
require add-on hardware to calculate rows’ activation and record it to other
fast-read-memory (SRAM [33]/CAM [34]). The controller will then refresh the
target row if the number reaches the RH threshold ($T_{RH}$) [10]. However,
such proactive refreshing proposals have faced a huge overhead both from
latency and power consumption perspectives. Moreover, the system yet relies on
a fast-read memory such as SRAM or CAM for storing the activation count table.
Recent RH protection mechanisms [8, 34] consider a uniform attack pattern and
set the number of activation needed for bit-flip to a certain value for every
row in DRAM. In fact, certain attacks can flip victim rows with significantly
fewer activations. Besides, the hardware overhead increases linearly based on
the DRAM capacity and the number of protected rows. To solve this issue, the
recent literature suggests protecting only a critical part of the memory
rather than the complete data [11].

---
Figure 4: The eight-step RowHammer mitigation based on RRS mechanism [12]. 1-
Copy the aggressor row to the buffer, 2- Send the buffer data to the Cache, 3-
Copy the random row to the buffer, 4- Send the buffer data to Cache, 5- Write
the aggressor row back from Cache, 6- Copy the data in the Cache to the
original random row, 7- Write the random row back from the Cache, 8- Copy the
data in the Cache to the original aggressor row.

Among the aggressor-focused RH mitigation mechanism, the Randomized Row-Swap
(RRS) [12] swaps the aggressor row with a random row within the same bank in
the memory as shown in Fig. 4. A method called Secure Row-Swap (SRS) [8] has
demonstrated the use of fewer counters for crucial data and implemented
associated threat mitigation using the swap operation. This approach reduces
the swap rate while maintaining security, resulting in higher efficiency and
lower latency. The six-step SRS mechanism secures the DRAM not only against
the RH attack but also the Juggernaut attack. RRS [12] and SRS [8] mechanisms
can be immensely effective when the attacker does not have knowledge of the
internal DRAM organization. Assuming the attacker’s access to this
information, he/she will not track the aggressor row but the victim row and
attacks its adjacent row, making it a new aggressor row. In this case,
swapping the aggressor row with another random row is heedless. Therefore,
_our idea is to stop tracking the aggressor row and instead protect the victim
row directly when the attacker is capable of tracking the essential data
(i.e., the victim row)_. With this, we not only save the tracking cost in
prior works but also ignore the attacker’s tracking and directly protect the
victim row.

Prior software-based efforts have approached the problem of weight noise
mitigation from a software-training optimization perspective, including weight
binarization [13], piece-wise weight clustering [13], weight encoding [14,
15], and DNN architecture modification [16, 17]. Among them, the binarization
of the weight and activation [13, 16] have shown significant improvement in
limiting the efficacy of BFA but sacrificing clean accuracy. _While our
proposed method will not require any software training, it is not a competing
method against DNN training algorithms._ In other words, any training
algorithm or software optimization can be readily incorporated into our
protection scheme to boost defense performance.

##  III White Box Threat Model

---
Figure 5: Threat model about hackers’ known information about DNN and the
attack process.

Hardware Threat Model. We assume the following threat model: 1) Each row has a
threshold $T_{RH}$ after becoming an aggressor row, and once exceeded within
the refresh interval ($T_{ref}$), it will impose a bit-flip to two adjacent
victim rows; 2) We assume that all vulnerable data rows are neither
concentrated in one/two sub-arrays nor evenly distributed in each sub-array.
Experimentally, most sub-arrays store several data rows simultaneously; some
may store multiple or none; and 3) The attacker has a detailed mapping file as
shown in Fig. 5 that can locate the physical address of the target data in the
neural network and is aware of the initial static mapping of the DRAM rows
(i.e., physical adjacency information between rows) [35, 19, 36]. Therefore,
the attacker can perform an RH attack on the targeted content.

Software Threat Model. We assume a standard white-box threat model for the
bit-flip attack adopted across multiple attack domains in prior works [2, 37,
38]. In a white-box threat model (summarized in Table I), the attacker is
aware of the internal structure of the DNN models, e.g., the number of layers
and the width of each layer. On top of that, the attacker has complete
knowledge of the DNN model parameters, their values, and bit representation
for inference. This assumption is practical due to the recent advancement of
side-channel information leakage and the reverse-engineering of DNN models
[39, 40] that can recover the DNN model configuration at the inference stage.
However, the attacker can not access the training stage configuration (e.g.,
learning rate, batch size) and training data even in a white-box setting. The
attacker has a sample batch of test data to launch the attack. The attacker is
co-located with the victim, which enables the attacker to run user-space
unprivileged processes. Finally, the attacker has complete knowledge of the
DRAM addressing scheme. In this work, two types of white-box attack threat
models are considered. A semi-white-box attack, as a weak version of the BFA,
where the attacker is unaware of our proposed defense scheme, and a complete
white-box attack, where the attacker is aware of the defense and takes
necessary actions to circumvent the mitigation.

TABLE I: Standard threat model for BFA [2, 27]. Information | Attackers Access
---|---
Model architecture and parameters | $\checkmark$
Small batch (e.g., 128) of test data | $\checkmark$
Address of parameter cached in DRAM | $\checkmark$
Model training data and configuration | $\times$
Memory read & write permission | $\times$

##  IV DNN-Defender

The DNN-Defender mechanism is developed to utilize the minimum number of swap
operations and to optimize latency overheads to protect the DRAM against the
targeted RH in the adversarial weight attack. Our mechanism makes traceability
very difficult for the attacker. Even if the attacker can precisely locate the
target data, DNN-Defender only requires to perform multiple swap operations to
the victim (/wanted) rows to secure the memory. The memory instruction-based
swap allows us to avoid concerns regarding invalid refreshes that may result
from a communication delay between the counter and the counter table [32].
DNN-Defender prioritizes versatility over assessing the potential impact of
swap operations on data in different scenarios and determining the worst-case
scenario. The focus is on preventing all threats regardless of the
circumstances. However, since an aggressor row is typically accompanied by
more than one victim row, one can inevitably ignore the other victim rows when
focusing on the target data since the impact of such data on the final result
is far less than that of important data. However, to minimize the adverse
effect, DNN-Defender uses the lowest resources possible to ensure their
security as well.

###  IV-A Framework

The existing swap-based mechanisms such as RRS [12] involve transferring
original and random data into the cache and then writing them back in an
eight-step procedure across the memory channel, which indirectly impacts the
performance of concurrently running applications that share the memory
bandwidth. Although the SRS [8] mechanism reduces the swap rate, we can
further reduce the latency overhead if we could rely only on DRAM for swap
operation. Unlike SRS and RRS, which focus on the aggressor row, DNN-Defender
focuses on protecting the victim row. As shown in Fig. 6, we virtually
partition the protected data region in each memory sub-array into the wanted
and innocent rows according to their protection priority. The wanted row
holding the targeted DNN weight is the row with the highest priority to be
protected. In other words, if a bit(s) within a wanted row is flipped, the
final DNN accuracy will significantly drop. The innocent rows however show a
certain degree of tolerance to errors as they have no/negligible effect on the
final result as illustrated in Fig. 1(b). However, in extreme continuous
attack scenarios, it is not ruled out that innocent rows may also contain
important data that would adversely reduce the DNN accuracy. Therefore, DNN-
Defender not only needs to guarantee the security of the targeted row but also
furnishes a low-cost safeguard for the innocent row.

The DNN-Defender’s swap operations are accomplished in four steps. As depicted
in Fig. 6, in step 1, the memory controller selects a random row in the sub-
array and leverages the RowClone mechanism [24] to copy it to the reserved
row. In step 2, the wanted row is copied to the random row in the same way.
This in-memory operation will refresh the wanted row and reset the attacker’s
target. The rationale is that even though the wanted row is copied to another
position, the malicious process knows the new location, so it will move to the
latest row beside the swapped wanted row and make it a new aggressor row. In
step 3, the random row in the reserved row is copied back to the original
location of the wanted row. Aiming to refresh the innocent row by knowing that
the capacity of the reserved row is limited, in step 4, the innocent row is
copied to the reserved row until the next random row overwrites it. Finally,
the original wanted row and random row are swapped, and the innocent row is
refreshed. It is noteworthy that the attacker can track the wanted rows and
attack the updated addresses, while they will no longer attack the innocent
and random rows.

---
Figure 6: The four-step swap mechanism in DNN-Defender framework. TABLE II:
Parameters Table

Parameter | Definition
---|---
$T_{ref}$ | System refresh interval (64ms)
$N$ | Total # of swap operations in single $T_{ref}$
$T_{n}$ | Time of each RH mitigation round
$S_{bit}$ | # of bits under attack
banks | # of banks in DRAM (16)
$T_{AAP}$ | Time for ACT-ACT-PRE operation
$T_{ACT}$ | Time for Activation per row
$T_{swap}$ | Time for swap operations
$N_{s}$ | Estimated # of bits need to be protected per bank
$T_{RH}$ | Threshold # of BFA
$T_{total}$ | Time for the attacker to break the system

###  IV-B Swap Algorithm & Timing Considerations

With the proposed mechanism, DNN-Defender can only focus on protecting the
victim rows holding the crucial weight data. From the design perspective, DNN-
Defender is developed to protect DNN weight parameters considering a white box
threat model. The RRS and SRS mechanisms assume that the attacker uses a
random-guess strategy during the attack. Besides, unlike the conventional
methods, DNN-Defender does not rely on any counters and activation tables to
enable tracking. The absence of the counter means that we need frequently
perform the swap operations on the wanted row. Table II lists the parameters
used in this work. Considering $T_{RH}$ is set to 4,800 in LPDDR4 [8], the
victim rows must be refreshed before the activation number reaches the
threshold. Therefore, it is necessary for DNN-Defender to complete swapping
operations within the threshold window ($<$4800)$\times T_{ACT}$.

A DRAM bank can store several important data rows, which means that several
swap operations are needed to protect these rows. Using a random function to
generate the random row for each swap operation can impose software/hardware
overheads and delays. Therefore, as illustrated in Algorithm 1, DNN-Defender
only needs one random row generation to support all swap operations. Figure 7
illustrates the DNN-Defender’s defense timeline and parallelism for a sample
DNN with multiple swap operations. In swap 1, it requires a Random Number
Generator (RNG) to define the initial random row for step 1. The remaining
three steps then follow that as we discussed before in Fig. 6. After
completing step 4, DNN-Defender stores the innocent row data of swap 1 in the
reserved row, which means that the innocent row 1 at this time can be used as
a new random row. Therefore, as shown in Fig. 7, step 1 of swap 2 can overlap
with step 4 of swap 1. Then it finishes the remaining three steps ( 2 to 4).
This method is readily applied to the next swap operations.

Algorithm 1 DNN-Defender’s Swap Algorithm

1:Procedure: Protection

2:$\textbf{If}\hskip 4.0ptDD\\_Start$

3:$\hskip 16.0ptDefine\ \ random\\_row=rand(DRAM)$

4:$\hskip 16.0ptreserved\\_row\leftarrow random\\_row$

5:$\hskip 16.0ptrandom\\_row\leftarrow targe\\_row[row]$

6:$\hskip 16.0pttarge\\_row[row]\leftarrow reserved\\_row$

7:$\hskip 32.0pt\textbf{If}\hskip 4.0pt(Target\\_rows==1)\hskip 4.0ptbreak;$

8:$\hskip 32.0pt\textbf{else}\hskip 4.0pt\textbf{For}\hskip 4.0ptrow\hskip
4.0ptin\hskip 4.0ptTarget\\_rows\hskip 4.0pt\textbf{do}$

9:$\hskip 48.0ptreserved\\_row\leftarrow non\\_target\\_row[row];$

10:$\hskip 48.0ptnon\\_target\\_row[row]\leftarrow targe\\_row[row+1];$

11:$\hskip 48.0pttarge\\_row[row+1]\leftarrow non\\_target\\_row[row];$

12:$\textbf{else}\hskip 4.0pt\textbf{if}\hskip 4.0ptDD\\_Interrup$

13:$\hskip 16.0ptbreak;$

14:$\textbf{else}\hskip 4.0ptcontinue();$

15:end Procedure

---
Figure 7: Timeline of a sample DNN with multiple swap operations.

###  IV-C Software/Hardware Support

We summarize the modifications to the ISA and controller that will facilitate
DNN-Defender performance. In order for the DNN-Defender to periodically swap
memory rows, it is necessary to grant the memory controller direct access to
read from and write data to DRAM, bypassing the on-chip cache. Such access can
be given by adding two instructions to the ISA: copy and control. DNN-Defender
supports copy operation taking the operands $src$, $dst$, $size$ which
activates the source row and the destination row to execute a row-aligned row-
sized bulk in-memory copy operation. control instructions include simple
control operations for loops and termination in the control flow. Also, it can
jump to a specific position, which depends on the results given by the swap
operation. For example, in step 1, the memory controller first translates the
source row address into the physical address of the ACT command, then an RNG
located in the controller generates a random row number as the destination
row. Such a number can be securely stored beforehand in the DNN-Defender
controller to conceal the RNG latency. To enable this, two key hardware cost
factors need to be considered, first, the DRAM chip’s I/O logic must be
enhanced to separate the internal DRAM bus from the memory channel during a
transfer using MUXes; and second, the memory controller needs to support the
new ISA and RNG unit. This incurs $\sim$0.02% die area cost.

###  IV-D Partition of Wanted and Innocent Rows

As shown in Fig. 6, one key step to our proposed defense is virtually
partitioning each memory sub-array into wanted and innocent rows. To select
the wanted rows requiring high-priority protection from DNN-Defender, we
propose using the same attack searching algorithm adopted by an attacker for
BFA [2]. We use a copy of the victim model with identical model architecture
and weights to compute the gradient of the loss function w.r.t each weight bit
($|\nabla_{{\bm{\mathsfit{B}}}_{l}}\mathcal{L}|$). Similar to the BFA attack,
we rank the gradients and only flip the highest gradient bit of a specific
layer which causes the largest increase in loss function as shown in Eqn. 1.
We run the software search algorithms until the model accuracy drops close to
the random guess level (e.g., 10 % for CIFAR-10). After performing one
complete round of BFA, we record the target bit location $R_{1}\in(l,k)$ ($l$
is the layer number, $k$ is the index at a specific layer) that were flipped
in the current attack round. Next, we flip back all the targeted bits and
perform another round of BFA but this time skip flipping the bits from the
previous round $R_{1}$. Hence for round $R_{2}$, if we encounter any bits from
the previous round $R_{1}$, we skip it and select the next bit candidate based
on gradient. In this way, we keep performing the bit-search algorithm for
multiple rounds ($R_{c},c=1,2,...,r$), where each round skips all the bits
from the previous rounds of the attack. The total number of rounds $r$ depends
on the number of bits the defender wants to secure, and increasing $r$ will
increase the level of protection from DNN-Defender. After profiling all the
vulnerable bits to BFA for multiple rounds, we select these bit sets as the
priority bits requiring more protection. Our proposed DNN-Defender will
prioritize protecting these vulnerable bit sets by selecting them as the
wanted row in their corresponding sub-array.

##  V Experimental Results

We present a cross-layer evaluation framework to demonstrate the benefits of
DNN-Defender. Firstly, we developed DNN-Defender’s sub-arrays with peripherals
using Cadence Spectre in the 45nm NCSU PDK library [41] at the circuit-level
to verify functionality, attain performance parameters, and measure the row-
shuffle time. The memory controller and registers were designed and
synthesized by Design Compiler with a 45nm industry library. Afterward, we
incorporated the results from circuit-level assessments and extensively
modified CACTI [42] at the architecture-level. Next, we implemented DNN-
Defender’s ISA in gem5 [43], and exported the memory statistics and
performance to an in-house C++ DNN-Defender optimizer, taking the CACTI output
and application netlist as the inputs. At the application-level, we evaluated
the performance of our proposed technique in defending against adversarial BFA
using two commonly-used visual datasets: CIFAR-10 [44] and ImageNet [18],
which are often used for assessing image recognition performance. CIFAR-10
consists of 60,000 RGB images sized 32×32, divided into 10 distinct classes,
while the ImageNet dataset contains 1.2 million training images divided into
1000 distinct classes. Experiments on the CIFAR-10 dataset were carried out
using VGG-11 [45] network. For the ImageNet dataset, experiments were
performed on ResNet-18 [46] and ResNet-34 [46] networks. In all cases, the
weights of the networks were quantized to 8-bit width. To carry out the BFA,
we randomly sampled images from the test/validation set, with a default sample
size of 128 for both datasets.

###  V-A Hardware Overhead Analysis

We compare the DNN-Defender’s hardware overhead with the latest RH mitigation
mechanisms in the literature in Table III. From a hardware utilization
perspective, these efforts can be classified into three groups: 1) frameworks
that utilize CAM, SRAM, or both along with one counter; 2) frameworks that
rely exclusively on DRAM resources and employ many counters; and 3) frameworks
that rely on DRAM and SRAM resources and employ swap operations. For this
experiment, our strategy is to consider the same 32GB: 16-bank of DDR4 DRAM
for all frameworks and normalize the capacity overhead and area overhead
across different frameworks. In Table III, i) the involved memory indicates
the type of memory used by the framework for RH protection. As discussed,
certain frameworks rely on a counter to monitor intrusions and store tracking
information in the system using CAM/SRAM. Nonetheless, because of the
considerably higher cost of CAM and SRAM in comparison to DRAM, selecting a
framework with such supplementary resources may be controversial. For example,
Table III shows that only Graphene [34] and TWiCE [33] occupy two fast storage
resources simultaneously. At the same time, Hydra [31], SRS [8], and RRS [12]
rely on SRAM in addition to DRAM. ii) Capacity overhead refers to the memory
resources utilized by RH in a framework. Such resources are dedicated solely
to RH and not for other purposes. Take Graphene [34] as an example, it
requires storing counting tables in SRAM (1.12 MB), and the space occupied by
these tables can no longer be used as a shared storage space to store data.
Graphene also requires 0.53 MB CAM to track vulnerable rows. Take SHADOW [36]
as an example, 0.16 MB capacity of DRAM is dedicated to enabling RH
mitigation. Our framework stands out from others as it does not utilize any
additional memory resources for RH mitigation. Unlike Graphene [34], TWiCE
[33], SRS [8], and RRS [12], DNN-Defender does not require any fast-read
memory. Furthermore, in contrast to SHADOW [36] and P-PIM [47], DNN-Defender
does not even sacrifice DRAM resources, where all rows can be used for storing
data in the same way as ordinary rows. iii) Some frameworks not only require
storage device resources but also additional components for RH mitigation. We
listed the additional hardware components required by various frameworks in
the area overhead column. We can find that DNN-Defender offers one of the most
area-efficient solutions compared to other frameworks. Among DRAM-only
frameworks, the best counter-based approach [32], that optimizes the number of
counters per row to reduce both DRAM usage and the total count significantly,
still imposes over 1000 counters. Besides, SHADOW [36] and P-PIM [47] require
modifying the DRAM circuitry, where they indicate 0.6% and 0.34% overheads.
Our framework only requires $\sim$0.02% area to support the new ISA and
controller with the RNG unit.

TABLE III: Comparison with prior RowHammar mitigation frameworks.

Framework | involved memory | capacity overhead | area overhead
---|---|---|---
Graphene [34] | CAM-SRAM | 0.53MB‡+1.12MB† | 1 counter
Hydra [31] | SRAM-DRAM | 56KB†+4MB∗ | 1 counter
TWiCE [33] | SRAM-CAM | 3.16MB†+1.6MB‡ | 1 counter
Counter per Row | DRAM | 32MB∗ | 16384 counters
Counter Tree [32] | DRAM | 2MB∗ | 1024 counters
RRS [12] | DRAM-SRAM | 4MB∗+NR† | NULL
SRS [8] | DRAM-SRAM | 1.26MB∗+NR† | NULL
SHADOW [36] | DRAM | 0.16MB∗ | 0.6%
P-PIM [47] | DRAM | 4.125MB∗ | 0.34%
_DNN-Defender_ | _DRAM_ | _0_ | _0.02%_

NR = Not Reported
∗The capacity overhead of DRAM. †The capacity overhead of SRAM. ‡The capacity
overhead of CAM.

###  V-B Security Level Analysis

In security analysis, we establish that the system’s security level is
directly proportional to the time taken by an attacker to breach it, i.e., the
longer it takes to breach the system, the higher the security level. As
previously stated in the threat model, the attacker has full knowledge of the
model and will modify the attack pattern after every unsuccessful attempt,
continuing to do so until either the system is broken or the attacker ceases
his/her efforts. Table II defines the simulation parameters for the attacker
and the defense system. The first assumption is that the data has no unique
mapping, so we consider the vulnerable data rows to be evenly distributed in
all banks. Therefore, the number of data rows we need to protect in each bank
is given by $N_{s}=S_{bit}/banks$, where $N_{s}$ is finite. In other words,
when the number of under-attack rows increases, $N_{s}$ will exceed the
defendable threshold. It is, therefore, essential to identify the threshold
that our framework can withstand. Assuming the worst-case scenario in which a
row contains only a single target weight bit, the maximum number of defended
BFA corresponds to the number of wanted rows. As DNN-Defender doesn’t modify
the circuitry of the original DRAM array, we can utilize the timing baseline
of DRAM without any alterations as given in [36] to calculate the time
required for swap operation, where $T_{swap}=3\times T_{AAP}$, $T_{AAP}$ =
90ns. As discussed, $T_{RH}$ depends on the DRAM process node as the minimum
number of activations that can impose bit-flip. So the time constraint for
DNN-Defender to perform the swap operations is given by $T_{ACT}\times
T_{RH}$, and the maximum number of swap operations can be calculated as
$\frac{T_{ACT}\times T_{RH}}{T_{swap}}$. We can calculate $T_{n}=T_{ACT}\times
T_{RH}+T_{swap}\times N_{s}$, and then find the total number of swap
operations in single $T_{ref}$ by $N=\frac{T_{ref}}{T_{n}}\times N_{s}$. Our
experiments showed that DNN-Defender and SHADOW [36] are the only frameworks
that can withstand the white-box attacks, therefore, we only report their
security level analysis. Our results indicate that even the SRS mechanism [8]
cannot defend against white-box attacks for a period of one day. Fig. 8
reports the time-to-break in days for various $T_{RH}$s and the corresponding
number of the defended BFAs. We observe that our framework outperforms SHADOW
in 1k, 2k, 4k, and 8k thresholds. For example, for $T_{RH}$=4000, the attacker
will require $\sim$1200 days to break a DNN-Defender-supported system, while
SHADOW stands up for $\sim$900 days.

---
Figure 8: Time-to-break DNN-Defender (DD) and SHADOW in different RowHammer
thresholds.
---
Figure 9: Latency of DNN-Defender (DD) and SHADOW [36] in different numbers of
BFA.

###  V-C Performance Analysis

Our performance analysis comprises two key components: latency and power
consumption. The former pertains to delays incurred during system operation
and the latter represents power consumed only by the DRAM module. Figure 9
shows DNN-Defender and SHADOW [36] with 1k, 2k, 4k, and 8k RH thresholds. We
picked SHADOW as one of the best RH mitigation mechanisms over others for this
comparison as explained in the previous subsection. The figure illustrates
that with an increase in the number of BFAs, the rate of latency increase
decelerates and eventually reaches a limit for both frameworks. When compared
to SHADOW operating at the same threshold, our framework exhibits lower
latency in all cases.

We consider the power consumption of a standard DRAM process as a benchmark to
fully reveal all aspects of our proposed framework. It is noteworthy that Fig.
10 doesn’t report the considerable power consumed by fast-read SRAMs and only
focuses on the DRAM side. Since DNN-Defender’s swap operation relies on the
RowClone technique [24] and does not entail circuit-level modifications, we
utilize our framework as the baseline. Compared with other frameworks, DNN-
Defender indicates no significant power-saving. For instance, even when SHADOW
is set with a threshold of 1k, DNN-Defender shows a negligible 1.6% power-
saving. However, considering the power consumption by SRAM-based frameworks
such as SRS and RRS and off-chip memory communication in such systems, DNN-
Defender offers a significant improvement.

---
Figure 10: Normalized power consumption of different RH mitigation frameworks
to DNN-Defender (DD).
---
Figure 11: Proposed DNN-Defender evaluation for different amounts of Secured
Bits (SB) for (a) VGG-11 trained on CIFAR-10, (b) ResNet-18 trained on
Imagenet, and (c) ResNet-34 trained on Imagenet against BFA. The degradation
in performance is shown for 100 iterations of the attack, with each curve on
the plots representing the extent of degradation after securing a certain
number of bits using DNN-Defender. Increasing the number of secured bits makes
it increasingly difficult for the attacker to cause performance degradation.
Note that each curve on the x-axis starts from SB since we will not observe
any accuracy degradation up to the secured number of bits by DNN-Defender.

###  V-D Defense Evaluation

Evaluation of DNN-Defender against Semi-White-Box BFA. To evaluate the
performance of DNN-Defender, first, we consider a naive BFA attack [2] where
the attacker is not aware of our defense strategy (Semi-White-box). Such a
naive attack will fail since the targeted bit-flip sequence is not optimized
to bypass our defense. A naive attacker will generate a small sequence of
target bits and will attempt to flip them. However, our proposed defense will
eliminate the impact of bit-flips via the proposed swap operation, and the
attacker will not achieve any success (i.e., accuracy degradation) using the
existing BFA algorithm.

Evaluation of DNN-Defender against White-Box BFA. Next, we consider an
advanced attacker with complete white-box knowledge where the attacker is
aware of our proposed defense and tries to evade it through adaptive search.
To bypass DNN-Defender, the attacker can generate multiple sequences of
targeted bits offline using a copy of the target model and evaluate the
attack’s success by launching the attack to the victim space. However, if a
specific chain of bit sequences fails to degrade model accuracy, the attacker
can skip this sequence to generate a new set of bit sequences for the next
attack round. This way, the attacker will iterate through all the Secured Bits
(SB) protected by DNN-Defender and still observe no success i.e., accuracy
drop at the output.

Next, in Fig. 11, we demonstrate the effectiveness of our proposed DNN-
Defender in mitigating the performance degradation caused by BFA when the
attacker further adapts the search and attempts to flip more bits than
protected by our defense (denoted as SB + # of additional bit-flips). The
plots show multiple curves of performance degradation on each of the
evaluation models (e.g., VGG-11, ResNet-18, ResNet-34), with each curve
representing the degradation after securing a specific number of bits using
DNN-Defender denoted as Secured Bits (SB). The plots reveal that as the SB
increases, it takes the attacker an increasing number of iterations to cause
the same performance degradation, gradually deteriorating the performance of
BFA near the random attack level. For example, in Fig. 11, for the VGG-11
model, increasing the secured bits from 2k to 8k increases the number of
additional bit-flips required to achieve the same attack efficacy by $\sim
6\times$. Eventually, even this adaptive white-box BFA attack loses its
potency after securing 24k bits (still only $\sim$ 4% of the total model
bits). In conclusion, our proposed DNN-Defender will increase the attack time
and effort by requiring increasing amount of bit-flips to achieve the same
attack efficacy as the baseline (no defense). If we secure a large number of
bits (e.g., $\sim$ 24k for VGG-11), then even after increasing the bit-flip,
the effect of BFA can be reduced to a random attack level.

###  V-E Comparison to SOTA Defenses against BFA

In Table IV, we compare our proposed defense against the existing model
training-based defenses [16, 13, 14]. A general approach among the prior
defense work is to reduce model weight bit-width precision [4, 13] and
increase the model size to reduce the impact of weight noise on accuracy [16].
Among them, a binary neural network [16] with both binary weight and
activation achieves the best defense performance against the BFA, requiring
over 1000 bit-flip to reduce the model accuracy close to random guesses. When
protecting the exact required number of (e.g., 1150) vulnerable bits, DNN-
Defender can easily resist the BFA attack better than the binary model.
However, our attack incurs slight hardware (e.g., latency & energy) overhead
which is not the case for software-based training algorithms [16, 13, 14]. In
contrast, all the software-based training methods suffer from high training
overhead and model accuracy drop. Our proposed DNN-Defender is an effective
defense against BFA w/o requiring any training overhead or performance drop
with minimal hardware overhead. Additionally, any software protection [48, 49]
or DNN training algorithm [13, 16] is not necessarily a competing method
against our defense; prior training-based defenses can further boost the
protection against BFA on top of our proposed DNN-Defender.

TABLE IV: Comparison to other competing software defense methods on CIFAR-10
dataset evaluated attacking a ResNet-20 model.

| Models
---
| Clean Acc.(%)
---
| Post-Attack acc.(%)
---
| Bit-Flips #
---
Baseline ResNet-20 [2] | 91.71 | 10.90 | 20
Piece-wise Clustering [13] | 90.02 | 10.09 | 42
Binary weight [13] | 89.01 | 10.99 | 89
Model Capacity $\times$ 16 [16] | 93.7 | 10.00 | 49
Weight Reconstruction [14] | 88.79 | 10.00 | 79
RA-BNN [16] | 90.18 | 10.00 | 1150
_DNN-Defender_ | _91.71_ | _91.71_ | _1150_

##  VI conclusions

In this work, we proposed a stand-alone and powerful DRAM-based defense
mechanism called DNN-Defender that leverages the potential of in-DRAM swapping
to protect quantized DNNs from targeted RowHammer bit-flip attacks. Our
results indicate that DNN-Defender is capable of providing robust protection
against consecutive targeted RowHammer attacks on CIFAR-10 and ImageNet
datasets downgrading its performance to a random attack level without any loss
of accuracy. Remarkably, this protection does not require any software
training or involve additional hardware overhead.

## References

  * [1] Y. Adi, C. Baum, M. Cisse, B. Pinkas, and J. Keshet, “Turning your weakness into a strength: Watermarking deep neural networks by backdooring,” in _27th $\\{$USENIX$\\}$ Security Symposium ($\\{$USENIX$\\}$ Security 18)_, 2018, pp. 1615–1631.
  * [2] A. S. Rakin, Z. He, and D. Fan, “Bit-flip attack: Crushing neural network with progressive bit search,” in _Proceedings of the IEEE/CVF International Conference on Computer Vision_ , 2019, pp. 1211–1220.
  * [3] V. Van Der Veen, Y. Fratantonio, M. Lindorfer, D. Gruss, C. Maurice, G. Vigna, H. Bos, K. Razavi, and C. Giuffrida, “Drammer: Deterministic rowhammer attacks on mobile platforms,” in _Proceedings of the 2016 ACM SIGSAC conference on computer and communications security_ , 2016, pp. 1675–1689.
  * [4] S. Hong, P. Frigo, Y. Kaya, C. Giuffrida, and T. Dumitras, “Terminal brain damage: Exposing the graceless degradation in deep neural networks under hardware fault attacks.” in _USENIX Security Symposium_ , 2019, pp. 497–514.
  * [5] Y. Kim, R. Daly, J. Kim, C. Fallin, J. H. Lee, D. Lee, C. Wilkerson, K. Lai, and O. Mutlu, “Flipping bits in memory without accessing them: An experimental study of dram disturbance errors,” _ACM SIGARCH Computer Architecture News_ , vol. 42, no. 3, pp. 361–372, 2014.
  * [6] O. Mutlu, A. Olgun, and A. G. Yağlıkcı, “Fundamentally understanding and solving rowhammer,” in _Proceedings of the 28th Asia and South Pacific Design Automation Conference_ , 2023, pp. 461–468.
  * [7] J. S. Kim, M. Patel, A. G. Yağlıkçı, H. Hassan, R. Azizi, L. Orosa, and O. Mutlu, “Revisiting rowhammer: An experimental analysis of modern dram devices and mitigation techniques,” in _2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA)_. IEEE, 2020, pp. 638–651.
  * [8] J. Woo, G. Saileshwar, and P. J. Nair, “Scalable and secure row-swap: Efficient and safe row hammer mitigation in memory systems,” _arXiv preprint arXiv:2212.12613_ , 2022.
  * [9] M. Marazzi, F. Solt, P. Jattke, K. Takashi, and K. Razavi, “Rega: Scalable rowhammer mitigation with refresh-generating activations,” in _44rd IEEE Symposium on Security and Privacy (SP 2023)_. IEEE, 2023.
  * [10] P. Frigo, E. Vannacc, H. Hassan, V. Van Der Veen, O. Mutlu, C. Giuffrida, H. Bos, and K. Razavi, “Trrespass: Exploiting the many sides of target row refresh,” in _2020 IEEE Symposium on Security and Privacy (SP)_. IEEE, 2020, pp. 747–762.
  * [11] R. Zhou, S. Tabrizchi, A. Roohi, and S. Angizi, “Lt-pim: An lut-based processing-in-dram architecture with rowhammer self-tracking,” _IEEE Computer Architecture Letters_ , vol. 21, no. 2, pp. 141–144, 2022.
  * [12] G. Saileshwar, B. Wang, M. Qureshi, and P. J. Nair, “Randomized row-swap: mitigating row hammer by breaking spatial correlation between aggressor and victim rows,” in _Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems_ , 2022, pp. 1056–1069.
  * [13] Z. He, A. S. Rakin, J. Li, C. Chakrabarti, and D. Fan, “Defending and harnessing the bit-flip based adversarial weight attack,” in _Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition_ , 2020, pp. 14 095–14 103.
  * [14] J. Li, A. S. Rakin, Y. Xiong, L. Chang, Z. He, D. Fan, and C. Chakrabarti, “Defending bit-flip attack through dnn weight reconstruction,” in _2020 57th ACM/IEEE Design Automation Conference (DAC)_. IEEE, 2020, pp. 1–6.
  * [15] L. Liu, Y. Guo, Y. Cheng, Y. Zhang, and J. Yang, “Generating robust dnn with resistance to bit-flip based adversarial weight attack,” _IEEE Transactions on Computers_ , 2022.
  * [16] A. S. Rakin, L. Yang, J. Li, F. Yao, C. Chakrabarti, Y. Cao, J.-s. Seo, and D. Fan, “Ra-bnn: Constructing robust & accurate binary neural network to simultaneously defend adversarial bit-flip attack and improve accuracy,” _arXiv preprint arXiv:2103.13813_ , 2021.
  * [17] J. Wang, Z. Zhang, M. Wang, H. Qiu, T. Zhang, Q. Li, Z. Li, T. Wei, and C. Zhang, “Aegis: Mitigating targeted bit-flip attacks against deep neural networks,” _arXiv preprint arXiv:2302.13520_ , 2023.
  * [18] J. Deng, W. Dong, R. Socher, L.-J. Li, K. Li, and L. Fei-Fei, “Imagenet: A large-scale hierarchical image database,” in _2009 IEEE conference on computer vision and pattern recognition_. Ieee, 2009, pp. 248–255.
  * [19] H. Hassan, Y. C. Tugrul, J. S. Kim, V. Van der Veen, K. Razavi, and O. Mutlu, “Uncovering in-dram rowhammer protection mechanisms: A new methodology, custom rowhammer patterns, and implications,” in _MICRO-54_ , 2021, pp. 1198–1213.
  * [20] V. Seshadri, D. Lee, T. Mullins, H. Hassan, A. Boroumand, J. Kim, M. A. Kozuch, O. Mutlu, P. B. Gibbons, and T. C. Mowry, “Ambit: In-memory accelerator for bulk bitwise operations using commodity dram technology,” in _2017 50th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO)_. IEEE, 2017, pp. 273–287.
  * [21] R. Zhou, A. Roohi, D. Misra, and S. Angizi, “Red-lut: Reconfigurable in-dram luts enabling massive parallel computation,” in _Proceedings of the 41st IEEE/ACM International Conference on Computer-Aided Design_ , 2022, pp. 1–8.
  * [22] S. Angizi and D. Fan, “Redram: A reconfigurable processing-in-dram platform for accelerating bulk bit-wise operations,” in _2019 IEEE/ACM International Conference on Computer-Aided Design (ICCAD)_. IEEE, 2019, pp. 1–8.
  * [23] F. Zhang, S. Angizi, J. Sun, W. Zhang, and D. Fan, “Aligner-d: Leveraging in-dram computing to accelerate dna short read alignment,” _IEEE Journal on Emerging and Selected Topics in Circuits and Systems_ , vol. 13, no. 1, pp. 332–343, 2023.
  * [24] V. Seshadri, Y. Kim, C. Fallin, D. Lee, R. Ausavarungnirun, G. Pekhimenko, Y. Luo, O. Mutlu, P. B. Gibbons, M. A. Kozuch _et al._ , “Rowclone: Fast and energy-efficient in-dram bulk data copy and initialization,” in _Proceedings of the 46th Annual IEEE/ACM International Symposium on Microarchitecture_ , 2013, pp. 185–197.
  * [25] R. Zhou, A. Roohi, D. Misra, and S. Angizi, “Flexidram: A flexible in-dram framework to enable parallel general-purpose computation,” in _Proceedings of the ACM/IEEE International Symposium on Low Power Electronics and Design_ , 2022, pp. 1–6.
  * [26] S. Angizi and D. Fan, “Graphide: A graph processing accelerator leveraging in-dram-computing,” in _Proceedings of the 2019 on Great Lakes Symposium on VLSI_ , 2019, pp. 45–50.
  * [27] F. Yao, A. S. Rakin, and D. Fan, “Deephammer: Depleting the intelligence of deep neural networks through targeted chain of bit flips,” in _29th $\\{$USENIX$\\}$ Security Symposium ($\\{$USENIX$\\}$ Security 20)_, 2020.
  * [28] TQ-Systems. (2020) Tqmx80uc user’s manual. [Online]. Available: https://www.tq-group.com/ filedownloads/files/products/embedded/manuals/x86/embedded-modul/ COM-Express-Compact/TQMx80UC/TQMx80UC.UM.0102.pdf
  * [29] Omron. (2019) “ny-series industrial box pc - hardware user’s manual. [Online]. Available: https://assets.omron.eu/downloads/manual/en/v6
  * [30] A. G. Yağlikçi, M. Patel, J. S. Kim, R. Azizi, A. Olgun, L. Orosa, H. Hassan, J. Park, K. Kanellopoulos, T. Shahroodi _et al._ , “Blockhammer: Preventing rowhammer at low cost by blacklisting rapidly-accessed dram rows,” in _2021 IEEE International Symposium on High-Performance Computer Architecture (HPCA)_. IEEE, 2021, pp. 345–358.
  * [31] M. Qureshi, A. Rohan, G. Saileshwar, and P. J. Nair, “Hydra: enabling low-overhead mitigation of row-hammer at ultra-low thresholds via hybrid tracking,” in _Proceedings of the 49th Annual International Symposium on Computer Architecture_ , 2022, pp. 699–710.
  * [32] S. M. Seyedzadeh _et al._ , “Counter-based tree structure for row hammering mitigation in dram,” _CAL_ , vol. 16, 2016.
  * [33] E. Lee _et al._ , “Twice: Preventing row-hammering by exploiting time window counters,” in _ISCA_ , 2019, pp. 385–396.
  * [34] Y. Park _et al._ , “Graphene: Strong yet lightweight row hammer protection,” in _MICRO_. IEEE, 2020, pp. 1–13.
  * [35] P. Jattke, V. Van Der Veen, P. Frigo, S. Gunter, and K. Razavi, “Blacksmith: Scalable rowhammering in the frequency domain,” in _2022 IEEE Symposium on Security and Privacy (SP)_. IEEE, 2022, pp. 716–734.
  * [36] M. Wi, J. Park, S. Ko, M. J. Kim, N. S. Kim, E. Lee, and J. H. Ahn, “Shadow: Preventing row hammer in dram with intra-subarray row shuffling,” in _2023 IEEE International Symposium on High-Performance Computer Architecture (HPCA)_. IEEE, 2023, pp. 333–346.
  * [37] A. S. Rakin, Z. He, J. Li, F. Yao, C. Chakrabarti, and D. Fan, “T-bfa: Targeted bit-flip adversarial weight attack,” _IEEE Transactions on Pattern Analysis and Machine Intelligence_ , vol. 44, no. 11, pp. 7928–7939, 2021\.
  * [38] A. Madry, A. Makelov, L. Schmidt, D. Tsipras, and A. Vladu, “Towards deep learning models resistant to adversarial attacks,” in _International Conference on Learning Representations_ , 2018. [Online]. Available: https://openreview.net/forum?id=rJzIBfZAb
  * [39] Y. Zhang, R. Yasaei, H. Chen, Z. Li, and M. A. Al Faruque, “Stealing neural network structure through remote fpga side-channel analysis,” _IEEE Transactions on Information Forensics and Security_ , vol. 16, pp. 4377–4388, 2021\.
  * [40] M. Yan, C. Fletcher, and J. Torrellas, “Cache telepathy: Leveraging shared resource attacks to learn dnn architectures,” in _USENIX Security Symposium_ , 2020.
  * [41] (2011) Ncsu eda freepdk45. [Online]. Available: http://www.eda.ncsu.edu/wiki/FreePDK45:Contents
  * [42] S. Thoziyoor _et al._ , “Cacti 5.1,” Technical Report HPL-2008-20, HP Labs, Tech. Rep., 2008.
  * [43] N. Binkert _et al._ , “The gem5 simulator,” _ACM SIGARCH computer architecture news_ , vol. 39, pp. 1–7, 2011.
  * [44] A. Krizhevsky, V. Nair, and G. Hinton, “Cifar-10 (canadian institute for advanced research),” 2010.
  * [45] K. Simonyan and A. Zisserman, “Very deep convolutional networks for large-scale image recognition,” _arXiv preprint arXiv:1409.1556_ , 2014.
  * [46] K. He, X. Zhang, S. Ren, and J. Sun, “Deep residual learning for image recognition,” in _Proceedings of the IEEE conference on computer vision and pattern recognition_ , 2016, pp. 770–778.
  * [47] R. Zhou, M. Morsali, S. Tabrizchi, A. Roohi, and S. Angizi, “P-pim: A parallel processing-in-dram framework enabling rowhammer protection,” 2023.
  * [48] J. Li, A. S. Rakin, Z. He, D. Fan, and C. Chakrabarti, “Radar: Run-time adversarial weight attack detection and accuracy recovery,” _arXiv preprint arXiv:2101.08254_ , 2021.
  * [49] Q. Liu, J. Yin, W. Wen, C. Yang, and S. Sha, “Neuropots: Realtime proactive defense against bit-flip attacks in neural networks,” 2023.