讀者們也許會覺得Rowhammer和比特位翻轉是音樂及舞蹈行業的專業術語，但其實他們指的是存在于動態隨機訪問存儲(DRAM)——大多數電子設備中都存在的一種核心組件中的某種非常嚴重的漏洞。隨著驅動器中在每個單獨的DRAM芯片上的存儲容量的提升，造成了其自身嚴重的漏洞，其允許攻擊者把DRAM中比特位的值從1改成0，或翻轉為相反的數值。這一基于硬件的攻擊能夠繞過核心系統保護措施，使數據安全和流程之間產生隔離。這威脅到了電子數據安全的基本原則，即內存位置的內容只有在它們被寫入時才發生變化。

DRAM芯片包含數以百萬計排的電容，包括充電或放電兩種類型，這兩種狀態代表了比特位的值，即0和1。要訪問DRAM芯片中存在的值，系統需要給整排電容進行同時加壓，并讀出所有的值，由于性能的原因使得要一次只讀取其中某位比特的信息是不現實的。事實上，DRAM的讀取操作實際上是一個讀取和更新的操作。讀取一行的值需要其電容放電，電容也就丟掉了它存的值。這意味著數據必須通過給電容充電的方式立即寫回。這種讀取和更新過程實際上發生在DRAM定期給電容放電來穩定自己，這就是術語中是動態RAM(Dynamic RAM)，而不是靜態RAM的原因。

隨著電容越來越小，排列越來越近，要防止相鄰電容之間相互影響干擾已經變得越來越難。快速和反復地訪問一排電容，會在相鄰行的電容間產生干擾錯誤和比特位翻轉。比特位翻轉很少發生在正常操作期間，因為緩存會限制DRAM讀取和更新循環需要發生的次數。然而，卡內基梅隆大學的研究人員在2014年發表的一篇題為《無訪問情況下的內存比特位翻轉——DRAM干擾性錯誤的試驗研究》的論文表明，重復性使用機器碼指令CLFLUSH或Cache Line Flush，能夠清除緩存并強制進行讀取和更新。研究人員發現，利用這一技術迫使內存反復讀取并給一排電容充電的話，將引起大量的比特位翻轉——產生所謂的Rowhammering現象。

谷歌的Project Zero團隊最近的研究發現，惡意程序可以利用比特位翻轉的Rowhammering運行未經授權的代碼。該團隊設計出如何使CPU重定向，從錯誤的內存地址運行代碼，利用Rowhammering改變操作系統的內存映射的內容。來自阿姆斯特丹自由大學的四位研究人員已經在Windows 10上使用Rowhammering與新近發現的一種存儲重復數據刪除矢量相結合的方法成功實現攻擊。即使系統的補丁完全修復，并運行著各種安全加固措施，此種方式還是可以使攻擊者控制操作系統。

Rowhammering漏洞在現實中出現可能還需要一段時間，但這種設計缺陷存在當今計算機設備的基本硬件之中。硬件供應商都試圖在DDR4架構中引入防止或減少Rowhammering漏洞的緩解措施或功能，但谷歌公司以及Third I/O公司的研究表明，DDR4也不能免疫Rowhammering，要防范這一漏洞，業界還有許多事情要做。

管理員們可以借助FuturePlus Systems Corp的FS2800 DDR Detective軟件的Rowhammer監測功能或谷歌的免費Rowhammer測試工具來檢查自己的設備是否存在漏洞。而另一種否定的聲音認為，沒有必要認為設備在比特位翻轉上存在漏洞，因為這一現象很難實現，他們的假設是基于比特位翻轉是不存在。這些工具只能運行在測試機器上，要求測試機和真實環境具有類似的硬件配置，且那些包含敏感數據，因為工具的操作可以永久性地損壞DRAM芯片，導致數據受損或系統崩潰。

這一存在設備硬件端的漏洞，已然超越了傳統反病毒和安全軟件的對于解決方案的認識，該問題無法僅僅通過升級操作系統軟件來解決。用戶正寄希望于硬件供應商提供解決措施，例如提升最小內存更新頻率來降低Rowhammering對比特位翻轉的影響。不幸的是，這一辦法將對DRAM能耗和性能產生不利影響。DRAM模塊制造商們對他們的產品如何應對Rowhammering均守口如瓶，可能的緩解機制也被深埋在產品規格說明書中。思科在降低級別變化方面提出了一些建議能夠緩解DRAM Rowhammer漏洞，但任何新的參數都必須現在測試環境中進行配置測試后二次配置才能應用。由曼徹斯特大學計算機科學學院正在開發能夠阻止Rowhammer漏洞的可行的硬件解決方案，簡稱為ARMOR，是一種內存運行時的熱排探測器。

如果在測試過程中發生了比特位翻轉，管理員應該考慮監視那些經常性具有很高CPU占用率和高緩存丟失的進程，這很有可能是基于Rowhammer攻擊方式的特征。根據評估的風險水平，將硬件移動到支持偽目標行更新(Pseudo Target Row Refresh)或目標行更新(Targeted Row Refresh)的平臺，通過目標行更新運行某一hammered row可能是一種選擇，但最好的建議是直接與您的供應商尋求意見，如何才能完全地保護特定的環境免受攻擊。最后，任何快速的解決方法將很有可能以BIOS更新的形式發布，管理員們應保證他們能實時跟蹤硬件廠商的安全通知。