HTML表格的構建中，<tr>標簽（表格行）扮演著基礎而關鍵的角色。正確使用表格行不僅能夠提升數據展示的清晰度，還可以通過各種技巧增強表格的功能性和交互性。本文將深入探討如何高效利用<tr>標簽，從而在網頁設計中實現更精細、更專業的布局和表現。

1. 理解<tr>標簽的基本用途

1.1 <tr>標簽概述

在HTML中，<tr>標簽用于定義表格的行。每個<tr>元素內部可以包含一或多個<td>（表格單元格）或<th>（表頭單元格）元素，用于展示具體的數據或標題。

1.2 創建基本的表格行

一個典型的表格行示例如下：

<table>
    <tr>
        <th>編號</th>
        <th>姓名</th>
        <th>職位</th>
    </tr>
    <tr>
        <td>1</td>
        <td>王小明</td>
        <td>前端開發</td>
    </tr>
</table>

這個例子展示了如何使用<tr>來創建包含標題和一行數據的表格。

2. 樣式化表格行

2.1 改善行的視覺效果

通過CSS，我們可以對表格行進行樣式化，例如設置斑馬線效果（條紋表格）、行懸停顏色等，以提升可讀性和用戶體驗。

tr:nth-child(even) {
    background-color: #f2f2f2;
}
tr:hover {
    background-color: #ddd;
}

2.2 使用類和ID優化樣式控制

給表格行添加類或ID，可以更細致地控制特定行的樣式，這對于突出顯示某些數據非常有用。

3. 動態交互的實現

3.1 使用JavaScript處理行事件

可以通過JavaScript為表格行添加點擊事件，達到如彈出詳細信息、修改數據等交互效果。

document.querySelectorAll("tr").forEach(row => {
    row.addEventListener("click", function() {
        alert("你點擊了一行！");
    });
});

3.2 動態添加和刪除行

在需要動態修改表格內容的場景下，可以通過JavaScript動態地添加或刪除表格行。

function addRow() {
    const table = document.getElementById("myTable");
    const row = table.insertRow(-1);  // 插入到表格末尾
    const cell1 = row.insertCell(0);
    const cell2 = row.insertCell(1);
    cell1.innerHTML = "新行單元格1";
    cell2.innerHTML = "新行單元格2";
}

4. 結語

通過深入了解和運用<tr>標簽，你可以大幅提升HTML表格的功能性和視覺吸引力。無論是數據密集型網站還是需要高度定制的用戶界面，精通這些技巧將使你在網頁開發中更加得心應手。

結尾部分：
希望本文的分享能幫助你更好地掌握HTML中的<tr>使用技巧，無論是基礎的數據展示還是復雜的用戶交互，都能通過你的代碼得到完美的實現。不斷實踐，不斷創新，讓我們在編程的路上一起進步！

管它們的 DRAM 內目標行刷新 (TRR，Target Row Refresh) 緩解，一些最新的 DDR4 模塊仍然容易受到多行 Rowhammer 位翻轉的影響。 雖然這些位翻轉可以從本機代碼中利用，但在瀏覽器中從 JavaScript 觸發它們面臨三個重大挑戰。鑒于 JavaScript 中缺少緩存刷新指令，現有的基于驅逐（eviction-based）的 Rowhammer 攻擊對于較舊的單行（single-sided）或雙行（double-sided）變體來說已經很慢，因此并不總是有效。 使用多行Rowhammer，發起有效攻擊更具挑戰性，因為它需要從 CPU 緩存中驅逐許多不同的攻擊者地址，最有效的多行（n-side）需要大量物理連續的內存區域，這在 JavaScript 中是不可用的。

本文克服了這些挑戰，構建了SMASH（Synchronized MAny-Sided Hammering），這是一種在現代 DDR4 系統上從 JavaScript 成功觸發 Rowhammer 位翻轉的技術。 為了發起有效的攻擊，SMASH 利用緩存替換策略的高級知識為基于驅逐的多行Rowhammer 生成最佳訪問模式。 為了取消對大型物理連續內存區域的要求，SMASH 將n行 Rowhammer 分解為多個雙行對，使用切片著色來識別它們。 最后，為了繞過 DRAM TRR 緩解措施，SMASH 仔細安排緩存命中和未命中，以成功觸發同步的多行 Rowhammer 位翻轉。 本研究展示了具有端到端 JavaScript 漏洞的 SMASH，該漏洞平均可以在 15 分鐘內完全破壞 Firefox 瀏覽器。

0x01 Introduction

在本文中展示了在現實假設下，確實可以直接從 JavaScript 繞過 TRR，從而允許攻擊者利用瀏覽器中重新出現的 Rowhammer 漏洞。此外，分析揭示了實際規避 TRR 的新要求。例如，TRRespass所示快速連續激活多行可能并不總是足以產生位翻轉。 DRAM 訪問的調度也起著重要作用。

目標行刷新：2014 年 Rowhammer 漏洞的發現 導致了一種全新的攻擊類別，這些攻擊都利用了該漏洞：跨越安全邊界的位翻轉。特別是研究人員已經證明了對瀏覽器、虛擬機、服務器和移動系統的實際攻擊，這些攻擊從本機代碼、JavaScript 甚至網絡發起 。除了這些內存損壞攻擊之外，Rowhammer 還可以作為泄漏信息的側信道。

為應對錘擊，制造商使用 in-DRAM TRR 增強了 DDR4 芯片，這是一種 Rowhammer “修復”，可監控 DRAM 訪問以減輕類似 Rowhammer 的活動。 TRR 由兩部分組成：sampler和inhibitor。sampler負責對內存請求進行采樣，以在它們造成危害之前檢測潛在的 Rowhammer 誘導序列。inhibitor試圖通過主動刷新受害者行來避免攻擊。不幸的是，最近TRRespass表明緩解是不夠的，可以通過從雙行移動到多行 Rowhammer 來繞過，即根據特定的 TRR 實現，不僅激活兩行，而且最多激活 19 行。

問題的癥結在于內存芯片的sampler。一個可靠的sampler會采集足夠的樣本來為inhibitor提供足夠準確的信息，以便在 Rowhammer 攻擊的情況下刷新所有必要的受害者行。不幸的是，常見的sampler實現監視有限數量的攻擊者，并且總是在同一時間 ，隱含地依賴于內存請求將以不協調、混亂的方式到達的假設。然而，如果通過大的物理連續內存區域精確控制要錘擊的行，并通過顯式緩存刷新（使用 CLFLUSH 指令）積極錘擊多行，多行 Rowhammer 可以壓倒sampler并觸發位翻轉，即使在啟用 TRR 的 DRAM。

從 JavaScript 繞過 TRR：雖然本機代碼 Rowhammer 在現代 DDR4 系統上的復活確實很嚴重，尤其是在云和類似環境中，但它不會立即影響暴露于 JavaScript 攻擊的 Web 用戶。在沒有 CLFLUSH 和對物理連續內存的控制的情況下，如果沒有新的發現，就不可能通過緩存逐出以足夠高的速度誘導位翻轉同時繞過 DRAM TRR 來控制大量行.請注意，與雙行 Rowhammer 相比，多行 Rowhammer 模式加劇了這些挑戰，因為它們需要更多的物理連續內存和更多的驅逐。

0x02 Threat Model

假設攻擊者控制了受害者訪問的惡意網站（或良性網站上的惡意廣告）。 攻擊者不依賴任何軟件漏洞，而僅利用 JavaScript 沙箱內觸發的 Rowhammer 位翻轉來控制受害者的瀏覽器。 假設受害者的系統部署了針對 Rowhammer 和側信道攻擊的所有最先進的緩解措施，即現代 DRAM 內 Rowhammer 緩解措施和針對微架構攻擊的瀏覽器緩解措施，包括low-resolution、jittery timers 和針對推測執行攻擊的緩解措施。SMASH 依賴透明大頁內存(THP，transparent huge page) 來制定其訪問模式。 有關Linux 發行版上默認 THP 設置的概述，見下表。

0x03 Rowhammering DDR4 in the Browser

從 JavaScript 內部執行 Rowhammer 攻擊從來都不是一件小事。 攻擊者需要找到一種方法來從緩存中刷新攻擊者，而不依賴于緩存刷新指令。 JavaScript 中缺乏內存尋址信息使此類攻擊進一步復雜化。 DRAM 內 TRR 緩解的競爭對手只會加劇此類挑戰。 由于緩解，普通的雙行 Rowhammer 將不再足夠。 要攻擊啟用 TRR 的 DDR4，攻擊者需要多方面的訪問模式。

挑戰1：要構建多行訪問模式，攻擊者需要大量的物理內存，這在JavaScript中很難獲得。

多行模式由許多相鄰的行組成。由于DRAM行地址是由高物理地址位決定的，收集相鄰行需要相對大量的物理內存。如后所示，SMASH 通過應用有關多行 Rowhammer 的新見解來應對這一挑戰，這允許它收集所需的攻擊者或地址，而無需大量連續的物理內存塊。

攻擊者面臨的下一個障礙是：如何確保每個內存訪問都進入 DRAM（而不是其中一個緩存）？攻擊者可以嘗試采用已知的解決方案，例如 Rowhammer.js提出的技術。這些方法使用驅逐集來創建 CLFLUSH 自由訪問模式。

挑戰2：攻擊者需要找到一種策略，生成能夠有效地執行多行漫游器的模式，而不會引入太多額外的緩存命中。

如下所示，SMASH 通過設計最佳訪問模式來解決這一挑戰，以確保所有緩存未命中都落在攻擊者行上并有助于錘擊。

所做的下一個重要觀察是關于緩存命中和緩存未命中的順序。普遍的看法是，只要在給定的時間內向內存發送了足夠多的請求，就有可能觸發 Rowhammer 位翻轉。上圖中總結的另一個實驗表明，這不適用于具有 in-DRAM TRR 的 DDR4 設備。在一種情況下，為 18行模式批量發送 18 個內存請求，然后是從緩存中刷新攻擊者的 CLFLUSH 指令。確認此模式會觸發位翻轉，但是如果將 CLFLUSH 指令與對攻擊者行的內存請求交錯，盡管在給定時間段內發送了相同數量的請求，也無法再觸發位翻轉。正如稍后展示的，這是由于 TRR 緩解的特性。

挑戰3：攻擊者必須仔細安排緩存命中順序，才能成功繞過DRAMTRR緩解。

如下所示，SMASH 通過將 DRAM 訪問與 TRR 緩解同步來解決這一挑戰。

0x04 Minimal Rowhammer Pattern

TRRespass 需要比現代操作系統提供的更大的連續內存分配，以控制每個攻擊者的位置。這是物理內存和 DRAM 地址之間映射的結果——以及操作系統向用戶空間應用程序提供物理內存范圍的方式（參見下圖）。例如，為了構建一個 19 行的模式，TRRespass 發現該模式對本文的一個測試有效，攻擊者需要 2^(17+log2^37) = 4.63MB 的連續物理因為 DRAM 行地址從高階物理地址位 17 開始，總共需要 2 · 19-1 = 37 行，包括受害者行，以形成 19行模式。從 JavaScript 沙箱的受限環境中獲取此類分配并非易事。

JavaScript 中的連續內存：為了從 JavaScript 中獲得對 DRAM 行地址的控制，先前的工作依賴于兩種技術來獲得連續分配：(i) 2 MB 透明大頁 (THP) 或 (ii) massaging buddy allocator以獲得高階分配（最大 4 MB）。這兩種技術都不允許獲得執行 19行Rowhammer 所需的 4.63 MB 連續物理內存。

放寬限制：在最初的一項實驗中，試圖了解在嘗試繞過 DRAM TRR 時行位置的影響。從輔助雙行模式開（即由任意行“護送”的雙行對）。本研究實現了它的概括：N-輔助雙行。即，單個雙行對伴隨著 N 個虛擬行的模式。這意味著 19行模式變為雙行模式，N = 19-2 = 17 個傀儡。在特定的 DIMM 上，這些傀儡的位置很重要，在測實驗中，沒有觀察到同一組內任意位置傀儡行的翻轉次數有任何明顯差異。這意味著攻擊者只需要形成一個雙行對和 N 個虛擬行映射到同一個存儲體——將展示一個更容易滿足的要求。

最小可行分配：DRAM 行地址由應用于物理地址的線性函數的結果決定。這些函數只是將高位物理地址位映射到行地址（見上圖）。由于 N 輔助雙行的發現，現在只需要控制三個相鄰的 DRAM 行：兩個侵略者行和中間的受害者行。換句話說，只需要控制 DRAM 行地址的兩個 LSB。

為了找出需要多少連續物理內存（或這兩個 LSB 在物理地址中的位置），對大多數現代英特爾 CPU 的 DRAM 尋址函數進行了逆向工程。 它們可以在上表中找到。

鑒于這些特定函數，上表顯示了控制一對雙行需要多少連續物理內存。如前所述，大頁面提供了 2 MB 的連續物理內存，通過massaging伙伴系統內存分配器，可以獲得 4 MB。因此得出結論，在大多數情況下，大頁面就足夠了。它們僅適用于大型配置，例如使用兩個以上 DRAM 通道的系統。

0x05 Self-Evicting Rowhammer

Rowhammer 的有效性在很大程度上取決于攻擊者激活率的最優性（即，固定時間間隔內的激活次數）。正如前文中所解釋的，先前工作中描述的基于驅逐的 Rowhammer 技術雖然在 DDR3 系統上有效，但不會產生足夠的內存訪問來觸發 DDR4 系統上的位翻轉需要 Rowhammer 模式。這需要更新的驅逐策略來最大化錘擊吞吐量。

例如一種基于驅逐的 Rowhammer 的方法通過利用 LLC的類似 LRU 的替換策略，為每個攻擊者引入了一個緩存未命中。在雙行 Rowhammer 的情況下，這轉化為對 DRAM 的兩次額外訪問。然而，每個額外的攻擊者都會引入另一個額外的訪問，因此該方法不能擴展到多方面的模式。

前文中解釋了虛擬行（即用于分散 TRR 緩解的行）的位置無關緊要。在本節中，將展示也可以通過使用虛擬行進行逐出來消除所有額外的 DRAM 訪問。

A.選擇雙行對

本文的自驅逐 Rowhammer 模式的目標是使用傀儡繞過 in-DRAM TRR sampler，同時驅逐緩存。為了便于討論，首先定義將在本文其余部分使用的術語。

術語：如前所述，雙行對是映射到同一銀行中第三行（即受害者）周圍的兩行（即攻擊者）的一對地址。讓 (a,b) 表示具有虛擬地址 a 和 b 的雙行對。如果虛擬地址 d 與 a 位于同一組中，則虛擬地址 d 是 (a,b) 的虛擬地址，因此也與 b 位于同一組中，并且不等于任何一個。建立這些定義后，按訪問順序排列的 N 輔助雙行模式如下所示：

其中 di 表示 (a,b) 的第 (i + 1) 個傀儡。在 dN-1 之后，再次訪問 a。將使用術語 aggressor 來指代 a、b 或一個虛擬地址。此外，使用 A 和 B 分別指代 a 和 b 的緩存集。

現在能夠更準確地說明本研究意圖，使用虛擬對象 di 來從 CPU 緩存中逐出 a 和 b。為此，將它們分成大小相等的兩組，如下所示：d2k虛擬映射到 A，d2k+1 虛擬映射到 B，k 是從 0 到 N/2 的整數?；旧鲜窃趧摻ㄒ粋€類似zebra的模式，其中每個其他地址都映射到同一組。

構建驅逐集：為了實現自我驅逐的目標，需要確保虛擬地址不僅與 (a,b) 位于同一存儲體，而且還與 a 或 b 一致，即它們映射到相同的緩存集。不幸的是，能夠分配 2 MB 連續物理內存的攻擊者無法控制用于索引 CPU 緩存切片的高階物理地址位（即位 20 以上的位）。在頁面著色算法的幫助下解決了這個問題，該算法允許發現看似無法訪問的高階切片位。

大頁面著色：考慮一個攻擊者可以使用一組 2 MB 大頁面。然后，大頁面的顏色由僅應用于大頁面偏移量上方的切片位的切片散列函數的結果給出。由于攻擊者已經控制了頁面偏移內的切片位，使用已知的頁面顏色，攻擊者可以完全控制切片索引。

為了揭示大頁面的顏色，攻擊者利用基于緩存驅逐的側信道。舉例來說，假設 LLC 的結合性是 W = 1。有兩個大頁面 P 和 Q，想知道它們的顏色是相同還是不同。為了找出答案，選擇一個任意的頁面偏移 f 并創建兩個地址 p 和 q，每個頁面一個，但都在頁面偏移 f 處，以確保它們在頁面內的設置索引和切片位相等。然后訪問 p，然后是 q，再次是 p。如果對 p 的第二次訪問導致（慢速）緩存未命中，則高位切片位的散列或 P 和 Q 的等效頁面顏色相等，否則它們不同。

首先選擇雙行對（a，b）。為了找到一個，攻擊者在已知的彩色大頁面之一中選擇任意偏移量。然后，為了找到 b，將 a 的行地址加二（或減二）。還更改了 b 中的一些附加位，以確保添加后 a 和 b 仍映射到同一組。 接下來選擇虛擬地址在與 (a,b) 相同的頁面偏移量處，但來自相同顏色的不同大頁面。在相同顏色的頁面上使用相同的偏移量，確保與 a 映射到 A 的偏移量相同的傀儡，以及 b 偏移量處的傀儡映射到 B。此外，傀儡將自動位于同一位置與 (a,b) 相同的存儲體。

B.處理更換策略

現在有了雙行對 (a,b) 和傀儡。原則上，假設傀儡映射到 A 或 B，N 輔助雙行模式是自驅逐的。然而在實踐中，如果虛擬對象不都適合它們的緩存集，它們只會相互驅逐或驅逐雙行對。特別是，長度 L = N +2 的 N 輔助雙行模式僅在 L/2 > W 時才會自驅逐，其中 W 是 LLC 的關聯性。這將嚴重限制 SMASH 只能使用非常多的 N。

命中：必須引入另一種地址，將其稱為命中（如緩存命中）。命中是永遠不應該離開 LLC 的地址，并且像傀儡一樣，它們要么映射到 A 要么映射到 B。也就是說，h2k 與 a 和 d2k 是一致的，而 h2k+1 與 b 和 d2k+1 一致對于某些整數k。命中用于有效地將 LLC 的感知關聯性降低到 W’ < W。例如，使用命中，即使 LLC 的關聯性更大，輔助雙行模式（每組有四個攻擊者）也可以自驅逐比四個，實際情況就是這樣。對于命中，這種 6 輔助雙行模式可能如下所示：

每行正好包含填滿 A 和 B 的 2W 次訪問。每行上的前四次訪問進入 DRAM，并逐出另一行上的前四次。例如，在等式 2 中，d2 驅逐 A 中的 a，d3 驅逐 B 中的 b，d4 再次驅逐 A 中的 d0，等等。下圖顯示了另一個示例，W’ = 3 的 16 輔助雙行模式。

隨著命中的引入，還引入了一個新參數，即在模式中引入了多少。至少需要確保模式不適合 A 和 B（否則將不會有驅逐），因此必須至少將 W-L/2 添加到長度為 L 的模式中。 其次，它不會使引入超過 2(W-1) 的意義，因為 A 和 B 中沒有空間留給攻擊者。第三，請注意，如果 W’ 不劃分 L/2（它在等式 2 中進行，其中 W’ = 2 和 L/2 = 4），訪問順序變得有點復雜，例如如果 W’ = 3 得到：

處理 QLRU：到目前為止，已經隱含地假設了一個類似 LRU 的替換策略。現在演示如何放寬這一假設以創建使用 Quad-age LRU (QLRU) 自我驅逐的模式，這是現代英特爾 CPU 的 LLC 使用的實際替換策略。下圖顯示了自驅逐下緩存集 A 的演變，說明了降低關聯性 W’ = 1 下的 QLRU 行為3，這意味著在每個集訪問一個攻擊者后，立即轉向命中。將從 1 開始，在 5 結束，6 表示下一輪的開始。

首先1訪問 a，它被帶入集合 A 并替換最舊和最左邊的緩存行。 2 由于此時所有行的時間都為 3（可能是最舊），因此 a 會在最左邊的位置結束。因為 a 是新的，所以它的時間變成1。 3繼續造成五個緩存命中，訪問當前在緩存中但時間為 3 的每個其他緩存行。 4 訪問它們會使他們的時間回到原來的水平。 5 最后，因為現在所有時間都是一，所以替換策略說他們都應該變成三個，這是通過時間更新來完成的。 6 現在回到開頭，a 位于 LRU 位置，準備在攻擊者訪問到 A 的第一個虛擬映射即 d0 時被驅逐。

C.雙指針雕鏤

最后為了使模式更快，使用雙指針雕鏤(Pointer chase)來執行訪問，而不是更常見的單指針雕鏤。 在單個（寄存器）指針雕鏤中，攻擊者指向的內存位置提供下一個攻擊者的地址（或者有時是命中，就像例子中一樣）。 然而，這種方法并沒有最大限度地提高內存吞吐量，因為每第二次內存訪問都需要等到第一次訪問完成，從而降低了內存控制器級別的并行度。

為此沒有使用一個寄存器，而是使用了兩個。 自然地將模式分成兩半，每一半中的地址映射到 A 或 B。然后將兩半鏈接到相互關聯的兩個單指針雕鏤中。 結果是這樣的
每條指令從內存加載，而不是存儲。 實驗表明與使用單指針追逐相比，雙指針追逐提高了 80% 的內存吞吐量。

0x06 Synchronized Rowhammer

本節中介紹的自驅逐模式不能直接觸發位翻轉，即使雙行對包含已知易受攻擊的行也不能。這意味著單靠多行 Rowhammer 并不總是足以繞過 TRR。為了對此進行研究，必須了解可以觸發位翻轉中基于“收集”CLFLUSH 的模式（即基準模式）與不能觸發位翻轉的自驅逐模式之間的區別。

在本節中，將闡明攻擊者如何以 S0 為案例研究來制作 Rowhammer 誘導的同步自驅逐模式。一種系統配置通常容易受到多種多行模式的影響。這一事實簡化了最終實現，因為攻擊者可以選擇具有最佳攻擊者行數的模式，以改進驅逐過程。因此，選擇使用 18 行（或者更確切地說，16 行輔助雙行） 。如上圖-a 所示，基準模式遍歷攻擊者，連續發出內存請求，然后使用 x86 64 CLFLUSH 指令刷新這些地址。測試機配備了 Intel i7-7700K CPU，具有 16 路組關聯 LLC（即 W = 16）。選擇設置約化關聯性 W’ = 3。作為示例，自驅逐模式如下所示（雙行對、八對傀儡和 26 次命中，見上圖-b）：

鑒于此模式比基準模式快約 30%，令人驚訝的是它不會產生位翻轉。因此嘗試減慢此模式以使其以與基準模式相同的速度執行。

A.硬同步自驅逐

為了研究這種現象，通過在 (a,b) 前面添加額外的 NOP 來減緩模式。這樣，激活間隔增加。結果如下圖所示：

1.首先，能夠將內存請求與發送到 DRAM 的刷新命令同步。確切地說，當 t（即迭代公式 4 的模式一次的時間）或 2t 除以 tREFI 時，盡管 NOP 數量增加，但兩種模式都停止減速并且曲線變平。

2.其次，如果模式太快，即tREFI/t > 5，則不會觸發位翻轉。

in-DRAM TRR對每個刷新命令起作用，并且sampler的每個刷新間隔可以采樣多個攻擊者。在所有實驗中，只在與第一個 nnS 攻擊者相鄰的受害者行中發現位翻轉，其中 n 始終是攻擊者的總數，S 是sampler的可疑容量，就其跟蹤的攻擊者數量而言。只是通過減少攻擊者的數量來學習 S，直到不再能夠重現特定的位翻轉。

存儲器控制器需要平均每 tREFI = 7.8 μs 調度一次刷新命令?，F代內存控制器試圖通過在沒有 DRAM 活動時機會性地發送刷新命令來提高性能。為了成功觸發 Rowhammer 位翻轉，模式需要重復數萬次，在此期間內存控制器必須發出許多刷新命令。當沒有 NOP 時，內存控制器將嘗試在具有許多緩存命中的區域之一期間安排刷新命令。這意味著，當刷新命令到達緩存命中的三個不同區域時，TRR 機制將能夠成功地采樣和刷新公式 4 模式中的 18 個攻擊者行中的每一個。

當在模式前面插入 NOP 時，可能會發生三種不同的情況，如前圖所示。 在第一個場景中，在 NOP 數量較少的情況下，內存控制器可能仍會選擇發送在具有緩存命中的區域中刷新命令，導致沒有位翻轉。在第二種情況下，每個模式前面的大量翻轉會使模式太慢而無法觸發位翻轉。在第三種情況下，使用正確數量的 NOP，模式與內存控制器打算發送刷新命令的時間同步。這導致第一個攻擊者 (a,b) 逃脫 TRR 機制以成功錘擊內存并觸發位翻轉。

雖然在自驅逐模式的開頭添加 NOP 的策略在觸發位翻轉方面是有效的，但它需要攻擊者非常精確地與刷新命令同步，并找出成功攻擊的正確 NOP 數量。雖然這是一個合理的策略，正如將在評估中展示的那樣，但在 JavaScript 中與刷新間隔精確同步并不總是微不足道的。相反，將描述另一種創建模式的策略，該模式僅與內存控制器的刷新命令進行軟同步，并取消找到有效錘擊的確切 NOP 數量的要求。

B.軟同步自驅逐

為了確保內存控制器不會在不需要的時刻進行刷新，必須確保具有緩存命中的區域足夠小。為此，稍微修改了自驅逐訪問模式，以在緩存未命中之間更均勻地分配緩存命中，從而創建以下自驅逐模式：

上圖顯示了在前面使用可變數量的 NOP 執行此模式的結果。鑒于少量緩存命中并沒有為內存控制器提供足夠大的窗口來調度刷新，它會機會性地使用單個可用的 NOP 間隙來代替調度刷新命令。因此，公式 5 的模式可以更柔和地與刷新命令同步，而無需精確數量的 NOP。這使得從 JavaScript 搜索位翻轉更加方便，如下一節所示。

調整緩存切片：在這些實驗中發現訪問不同切片可能需要可變的時間。這使得生成同步模式變得更加困難，其中地址映射到的兩個集合 A 和 B 駐留在不同的切片中。因此，通過調整每個地址的列位，確保 A 和 B 映射到同一個切片。

0x07 Evaluation

上一節表明，可以成功生成自驅逐錘擊模式，這些模式能夠使用軟同步技術和重新操作來繞過 TRR 機制。還展示了正確選擇攻擊者地址的能力取決于虛擬到 DRAM 尋址功能以及如何選擇映射到給定緩存集和切片的地址。

在本節中，評估攻擊者可以成功創建有效的自驅逐模式的約束條件。本文評估了在來自兩個主要內存供應商的具有不同內存配置和內存模塊的三種設置上構建自驅逐模式的可行性（見上表）。所有系統均采用采用 Kaby Lake 微架構的 Intel Core i7-7700K CPU。由于 Skylake、Kaby Lake、Coffee Lake (R) 微架構都對給定的內存配置使用相同的 DRAM 尋址函數，正如前文中發現的那樣，關注在不同內存配置上構建自驅逐同步模式的可行性在 CPU 的微體系結構方面不乏通用性。

A.自驅逐模式的實用性

是否可以僅從大頁面中提取自驅逐模式，取決于內存控制器采用的 DRAM 尋址功能。在較小程度上，它還取決于用于切片尋址的復雜尋址方案，自 Sandy Bridge 以來，這種方案沒有改變，除了從 Skylake 開始，切片的數量等于超線程的數量而不是內核的數量。

使用基于軟件的 DRAMA 方法對幾種內存配置的物理到 DRAM 尋址功能進行了逆向工程。上表顯示了為獲得 (a,b) 形式的雙行對而需要更改的位。假設啟用了 THP，在七種可能配置中的六種中，可以成功地在大頁面內找到雙行對。在其余情況下，行位在大頁邊界之后開始，因此找不到與 a 相隔兩行的 b。

B.產生位翻轉

首先使用開源 TRRespass為的三個測試中的每一個找到最有效的多行訪問模式。然后，根據前文中描述的策略使每個模式自驅逐和同步。下表總結了所得模式的一些不同屬性（例如，降低的關聯性 W’）。

下表顯示所有三種自驅逐模式都能夠使用原生 C 實現觸發位翻轉。同時，觀察到不同系統所需的 NOP 數量存在明顯差異。特別是，與系統 S0 相比，系統 S1 和 S2 上的“有效 NOP 范圍”更窄。懷疑這是因為 S1 和 S2 構建的自驅逐模式的相對緩慢（與刷新模式相比）造成的。如上表所示，與 S0 相比，S1 和 S2 的 TRRespass 模式更小（即所需的傀儡更少），這意味著命中的引入將對 (a,b) 的激活之間的時間產生更大的相對影響。因此，使用太多 NOP 會使這些模式太慢而無法觸發位翻轉。

在 JavaScript 中的實現能夠觸發系統 S0 和 S1 上的位翻轉。觀察到與 S0 相比，S1 上位翻轉的發生頻率較低。盡管使用原生實現也觀察到了這一點，但與 S0 相比，系統 S1 和 S2 的更嚴格的同步要求（即更小的 NOP 范圍）會夸大差異是合理的。由于 NOP 在 JavaScript 中不可用，實現使用 XOR 代替。這兩條指令都很便宜，但 JavaScript 中的 XOR 循環有更多的開銷，因此引入了更粗粒度的延遲。這使得瞄準系統 S1 和 S2 的最佳位置變得更加困難。

C.JavaScript 實現基準

現在評估運行在最新版本的 Mozilla 的 JavaScript 運行時 SpiderMonkey 上的 JavaScript 實現的性能。特別地，考慮了程序的初始化階段（例如檢測頁面顏色所花費的時間）和錘擊階段。

初始化：攻擊者首先運行切分著色算法，以揭示支持其 ArrayBuffer 的 500 個大頁面的頁面顏色。接下來，攻擊者使用大頁面的子集（其大小取決于模式的長度）來組裝第一個自驅逐模式。最后，攻擊者需要注意同步，并通過改變模式前面的 XOR 數量來做到這一點。

上圖報告了在每個步驟上花費的時間：“第一個驅逐集”和“上色 500 大頁”。一起報告切片著色算法找到五個相同顏色的大頁面并隨后使用它們分別顯示其他 500 個頁面的顏色所需的時間。最后，“軟同步”。報告為軟同步尋找正確數量的 XOR 所花費的時間。每次測量都重復了 10 次。平均而言，攻擊者需要一分鐘才能完成初始化。請注意，軟同步步驟花費的時間最長。在實現中，使用放大的時間測量來估計模式在將其用于錘擊之前適合 7.8 μs 的刷新間隔 tREFI 的次數。如果模式適合四次，那么它是一個很好的錘擊候選者。

錘擊時間：初始化完成后，攻擊者開始尋找可利用的位翻轉。為了錘擊不同的行，攻擊者只需更改用于模式組裝的大頁面子集。上圖顯示了在 S0 和 S1 上的單個 10 小時實驗期間隨時間推移的唯一位翻轉的累積數量。

D.討論

要成功執行 SMASH，攻擊者需要了解受害者的內存配置。特別是，如果不知道 DRAM 尋址功能和至少一種繞過 TRR 的 n 行模式，就不可能構建自驅逐模式。雖然指紋可以檢測特定系統，但攻擊者也可以嘗試不同的配置，直到成功。

0x08 Mitigations

在硬件中緩解 Rowhammer：Rowhammer 是 DRAM 硬件中的一個漏洞，期望它應該在硬件中修復是明智的。不幸的是，更新和更有效的緩解措施需要很多年才能到達終端用戶。此外，鑒于未來的 DRAM 設備將采用更小的晶體管，是否有可能為此類設備構建有效的緩解措施還有待觀察。盡管如此，未來 DRAM 設備的安全性可以從三個方向提高：首先，硬件制造商可以以更高的成本構建更精確的sampler，無論是在 DRAM 設備內部還是在內存控制器上。其次，可以部署比現有解決方案更積極的糾錯，以降低觸發位翻轉的概率。第三，根據訪問模式和給定 DRAM 設備的脆弱性，可以限制潛在激活的數量。所有三個方向都伴隨著性能或存儲開銷，更不用說額外的功耗了。

在軟件中緩解 Rowhammer：在硬件緩解措施可用的情況下，已經有許多建議可以在軟件中緩解 Rowhammer。它們的安全性、兼容性或性能總是存在問題。 CATT建議使用保護頁來保護內核內存免受用戶內存的攻擊。不幸的是，內核內存可能會通過頁面緩存等常見機制直接暴露給用戶內存，從而使系統暴露在外。 ALIS和GuardION試圖保護系統的其余部分免受可能被攻擊的內存區域，但這些解決方案需要對每個軟件進行更改，而且不能保護系統的其余部分免受攻擊。 ZebRAM嘗試使用奇數行和偶數行將 VM 的內存劃分為安全和不安全區域。虛擬機可以直接訪問安全區，而不安全區則用作受 ECC 保護的交換緩存。 ZebRAM 的設計雖然可以抵御已知攻擊，但在處理內存密集型工作負載時具有非平凡的性能開銷。

減輕 SMASH：現在討論更實用的緩解措施，這些緩解措施在不解決底層Rowhammer漏洞的情況下讓攻擊者更難通過SMASH來利用瀏覽器。當前版本的 SMASH 依靠 THP 來構建高效的自驅逐模式。禁用 THP，同時引入一些性能開銷，將停止 SMASH 的當前實例。此外，漏洞利用特別依賴于瀏覽器中的破壞指針來破壞 ASLR 并轉向偽造對象。保護軟件或硬件中指針的完整性（例如，使用 PAC）將阻止當前的 SMASH 漏洞利用。

0x09 Conclusion

本研究展示了互聯網用戶仍然受到現代 DDR4 設備中 Rowhammer 漏洞的影響。 這些設備需要多行 Rowhammer 模式來繞過它們的 TRR 緩解。 在不訪問緩存刷新指令和連續物理內存的情況下，在 JavaScript 中高效執行此類模式特別具有挑戰性。 發現了 TRR 緩解的一個新屬性，結合精心選擇的錘擊地址，可以在瀏覽器中創建高效的多行Rowhammer 模式。 然而，在 JavaScript 中觸發位翻轉需要更進一步，并根據 CPU 內存控制器發出的刷新命令仔細安排緩存訪問。 端到端漏洞利用稱為 SMASH，可以在平均 15 分鐘內啟用所有緩解措施來完全破壞 Firefox 瀏覽器。 最后討論了減輕 Rowhammer 攻擊的未來方向，特別是 SMASH。