Intel CPU漏洞導致64位元作業系統、虛擬化軟體易受駭客攻擊
=> 有篇進垃圾桶
網管幫幫忙吧 ..
我只想知道 intel , AMD 64 BIT CPU
到底問題在那 ..vmware 灌 會出問題嗎 ?
thank you
taiwan2008 wrote:
Intel CPU漏...(恕刪)
轉自PTT 作者a40136
在過去AMD開發X86-64的指令集時，AMD並沒有真的把記憶體的位元數擴充到64bit
實際上只有到48bit(因為48bit已足夠定址256TB的記憶體，真實64bit需要6層的
pagetable、而48bit只需要4層pagetable)。
所以當記憶體儲存時，第48~63bit的值必須與第47bit的值相等(canonical form)假使值不相等那就會回傳一個錯誤訊息(GP)。
現在的作業系統設計主要都是階層化設計，分為User mode、Priveleged mode
中間是透過SYSRET這個System Call做切換，一些比較重要的事情都必須在
Priveleged mode底下運行，而進行轉換這個動作主要是透過SYSRET執行，也是
這次問題發生之所在。
SYSRET 主會做以下2個動作
將RCX值賦予RIP(instruction pointer)
轉換為User mode。
而RCX 是一個通用的register所以可以存取64bit之值
但是RIP是用作存取記憶體位置所以必須符合前述所說canonical form
針對這點，Intel與AMD都會針對這個值檢查的時機不同。
Intel是在轉換前做檢查，AMD是在轉換後。
假使不符合canonical form
Intel會是在Priveleged mode傳回GP。
AMD會在User mode傳回GP。
假使GP是在Userv mode時傳出，那Stack pointer會是一個由hypervisor給定
得值。
但是假使GP是在Priveleged mode傳出那SP值會是當下的SP值也就是Priveleged mode底下的SP值。
但是SYSRET並不會做回復SP值這個動作，這個動作是由hypervisor執行，所以當GP出現之前SP值已經被複製到當下的地方，所以有心要搞破壞的人，只需要促使
hypervisor 所接收到的RIP不符合canonical form那他就能任意修改SP的值，藉此破壞。
其實早期的AMD處理器也有相同的問題，並不只有Intel。
正確來說最早是AMD實做這個指令集Intel拿去用，或許AMD後來偷改過沒公布。
理論上只要修改作業系統針對層級切換所使用的system call就可以解決這個問題
Windows、Xen、FreeBSD、RedHat、NetBSD都已經有Patch，記得更新就沒事了。
如果是企業用戶使用Linux系統建議可以參考一下KSplice，在事情爆發後不到12小時就更新了，還不錯。
有看過恐龍書的應該就知道這在說啥哩.
補上xen的說明(英文)
內文搜尋
從 APP 打開
X