Re: [情報] Linux 之父轉用 AMD 後感到滿意，再度痛

看板PC_Shopping作者 (王小胖)時間3年前 (2021/01/13 16:22), 編輯推噓10(10推 0噓 20→)
留言30則, 14人參與, 3年前最新討論串2/2 (看更多)
※ 引述《hn9480412 (ilinker)》之銘言： : 指向糟糕的記憶體；而 ECC 可以防止 Rowhammer 錯誤，Rowhammer 問題存在已久，但 : 硬體製造商依舊強調 Rowhammer 是攻擊造成，而非偷工減料。 : Torvald 補充，現在要找到 ECC 記憶體十分困難，且價格昂貴，這歸咎於英特爾錯誤的 : 策略，強調消費者不需要 ECC；但由於 AMD，這個情況開始改善，因 AMD 雖然沒有官方 : 正式支援 ECC，但卻容許市場修復這些問題。 所以這個Rowhammer到底是什麼東西: 簡單說就是因為製程演進 記憶體單元越來越接近 導致讀取可以有機會干擾隔壁行的單元 造成位元翻轉 中文參考: https://reurl.cc/xgZWDE 或參考中英文wiki 那Linus念茲在茲的ECC到底能不能預防這件事情? 理論上可以 但有人搞出了可以繞過ECC的方法 (yoyodiy? 嚇尿我這個小小lab助理 所以變成ECC只能緩解 那到底怎麼預防? 7倍的DRAM刷新頻率應該可以 但太耗電了 性能也會損失 這樣大家又要說安全性更新結果性能下降 而且是DRAM的包 所以Intel和AMD都一樣 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 60.250.179.98 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/PC_Shopping/M.1610526167.A.14A.html
推
01/13 16:27, 3年前 , 1F
還看到可以操作記憶體內容來發出wifi訊號的 真會玩
01/13 16:27, 1F
推
01/13 16:30, 3年前 , 2F
yo叔又繞過了一個
01/13 16:30, 2F
推
01/13 16:38, 3年前 , 3F
感謝一樓和原po，長知識
01/13 16:38, 3F
推
01/13 16:42, 3年前 , 4F
一樓的那個就是最近的記憶體隔空讀個資的漏洞吧
01/13 16:42, 4F
→
01/13 16:44, 3年前 , 5F
更新頻率一定要到7倍這個魔法數字才有效喔？
01/13 16:44, 5F
→
01/13 17:11, 3年前 , 6F
Wiki寫的 參考15
01/13 17:11, 6F
推
01/13 17:12, 3年前 , 7F
這些駭客真的很會找漏洞
01/13 17:12, 7F
→
01/13 17:12, 3年前 , 8F
過熱時也容易觀察到類似問題 所以也會用提高更新頻
01/13 17:12, 8F
→
01/13 17:12, 3年前 , 9F
率這招
01/13 17:12, 9F
→
01/13 17:14, 3年前 , 10F
我看他試3個bit的error 心想：三小啦 這也行！？
01/13 17:14, 10F
推
01/13 17:30, 3年前 , 11F
不知道用軟體做檢查碼的成本會不會比ECC記憶體便宜
01/13 17:30, 11F
→
01/13 17:42, 3年前 , 12F
最大的檻 大概就是當ecc ram爛大街
01/13 17:42, 12F
→
01/13 17:47, 3年前 , 13F
拿個沒事的core作預讀 更正 回寫之類的事
01/13 17:47, 13F
→
01/13 17:52, 3年前 , 14F
不在乎效率的話 搞不好可以幹出很fancy的事
01/13 17:52, 14F
推
01/13 17:54, 3年前 , 15F
side channel attack?
01/13 17:54, 15F
推
01/13 19:23, 3年前 , 16F
又增加了些沒三小路用的知識，推一個！orz
01/13 19:23, 16F
→
01/13 19:54, 3年前 , 17F
01/13 19:54, 17F
→
01/13 19:54, 3年前 , 18F
tware-memory-bit-flip-detection-for-platforms-wi
01/13 19:54, 18F
→
01/13 19:54, 3年前 , 19F
thout-ecc
01/13 19:54, 19F
推
01/13 20:11, 3年前 , 20F
長知識推
01/13 20:11, 20F
推
01/13 20:27, 3年前 , 21F
每一種ECC演算法本來就有其可偵測/可復原的極限
01/13 20:27, 21F
→
01/13 20:28, 3年前 , 22F
很多電路層級的極端操作都會有問題 因為當初設計
01/13 20:28, 22F
→
01/13 20:28, 3年前 , 23F
的意圖就沒有要考慮這些情境的意思
01/13 20:28, 23F
→
01/13 20:29, 3年前 , 24F
designer大多會假設user照他定的規矩用
01/13 20:29, 24F
→
01/13 20:29, 3年前 , 25F
ECC不能防止所有錯誤 只是降低機率
01/13 20:29, 25F
→
01/13 22:45, 3年前 , 26F
不太對吧 照linus說法 他認為Rowhammer
01/13 22:45, 26F
→
01/13 22:46, 3年前 , 27F
就算沒人攻擊也會發生 所以他的意思應該是ECC
01/13 22:46, 27F
→
01/13 22:46, 3年前 , 28F
能夠解決自發性的這種問題
01/13 22:46, 28F
→
01/13 22:47, 3年前 , 29F
至於被攻擊的 應該不是他所想表達的
01/13 22:47, 29F
→
01/14 14:01, 3年前 , 30F
GG轉用AMD後感到滿意，讚
01/14 14:01, 30F
‣ 更多 hcwang1126 的文章
文章代碼(AID): #1V_gtN5A (PC_Shopping)
‣ 更多 hcwang1126 的文章
文章代碼(AID): #1V_gtN5A (PC_Shopping)