Home » Computer » Archive by category "Software" (Page 2)

Ubuntu 開始更新 Kernel 了...

這波 CPU 安全問題,UbuntuLinux Kernel 的更新計畫 (workaround patch) 放在「Information Leak via speculative execution side channel attacks (CVE-2017-5715, CVE-2017-5753, CVE-2017-5754 aka Spectre and Meltdown)」這邊。

不是所有版本的 kernel 都有更新,像是我之前跑 4.10 發現這次沒在清單內,就換成 linux-image-generic-hwe-16.04-edge 了... 換完後需要再裝 linux-headers-generic-hwe-16.04-edge,然後把舊的 kernel 都清乾淨,最後 nvidia-387 需要重新編過。

這次苦哈哈啊...

把自動播放影片的功能關掉...

一堆國外新聞網站超愛這套,這不是 Flash 時代的搞法嗎,怎麼現在還這樣搞啊... 在 Google Chrome 內建的設定就可以關掉了,先進入 chrome://flags,然後選擇「Document activation is required.」:

中文版的 Chrome 不知道是翻成什麼,就自己翻譯猜一下吧...

JVM 的各種調校

看到「JVM Anatomy Park」這篇,作者是 Red HatOpenJDK 團隊的人,寫了二十則與 JVM 效能相關的主題,裡面提到每則大約花五到十分鐘可以看完,不過我覺得應該會再久一點 (需要翻資料交叉查)。

除了網頁版外,也提供 EPUB、MOBI 與 PDF 格式可以下載。

都是講效能相關的,從不同角度看。以第一個 Lock Coarsening and Loops 來說,已知這段程式碼:

synchronized (obj) {
  // statements 1
}
synchronized (obj) {
  // statements 2
}

會被轉換成這樣等效的程式碼:

synchronized (obj) {
  // statements 1
  // statements 2
}

作者就問了,那這樣的話,這段:

for (...) {
  synchronized (obj) {
    // something
  }
}

會不會轉成這段呢:

synchronized (this) {
  for (...) {
     // something
  }
}

答案是不會,但可以橋:

While lock coarsening does not work on the entire loop, another loop optimization — loop unrolling — sets up the stage for the regular lock coarsening, once the intermediate representation starts to look as if there are N adjacent lock-unlock sequences. This reaps the performance benefits, and helps to limit the scope of coarsening, to avoid over-coarsening over fat loops.

就大概是這樣的主題 XD 每天看個一兩篇慢慢消化還不錯...

Ubuntu 下調整滑鼠的速度...

換了一隻滑鼠後,發現速度已經調到最慢了,但還是感覺太快:

這時候就得調其他東西了,我是參考「Fix Mouse Sensitivity in Ubuntu 16.04」這邊的說明來調整的。測過 xset 會動後,把檔案丟到 ~/.config/autostart/mouse.desktop 裡面讓他登入後生效:

[Desktop Entry]
Name=Decrease mouse sensitivity
Exec=xset m 1/2 8
Type=Application
Comment[en_US]=Use xset to set mouse params
Comment=Use xset to set mouse params

這樣習慣一些...

Fortnite 看起來沒上 Auto Scaling?(或是沒正確設好?)

Fortnite 遊戲的伺服器放在 AWS 上,看起來這波 Meltdown 的安全更新 (KPTI) 造成非常大的 overhead:

不過看起來出了問題:

We wanted to provide a bit more context for the most recent login issues and service instability. All of our cloud services are affected by updates required to mitigate the Meltdown vulnerability. We heavily rely on cloud services to run our back-end and we may experience further service issues due to ongoing updates.

最有可能的是把 AWS 當作一般的 VPS 在用,另外一種可能是有部份內部服務沒有 scale,造成上了 KPTI 後 overhead 增加,就卡住了...

讀書時間:Meltdown 的攻擊方式

Meltdown 的論文可以在「Meltdown (PDF)」這邊看到。這個漏洞在 Intel 的 CPU 上影響最大,而在 AMD 是不受影響的。其他平台有零星的消息,不過不像 Intel 是這十五年來所有的 CPU 都中獎... (從 Pentium 4 以及之後的所有 CPU)

Meltdown 是基於這些前提,而達到記憶體任意位置的 memory dump:

  • 支援 µOP 方式的 out-of-order execution 以及當失敗時的 rollback 機制。
  • 因為 cache 機制造成的 side channel information leak。
  • 在 out-of-order execution 時對記憶體存取的 permission check 失效。

out-of-order execution 在大學時的計算機組織應該都會提到,不過我印象中當時只講「在確認不相干的指令才會有 out-of-order」。而現代 CPU 做的更深入,包括了兩個部份:

  • 第一個是 µOP 方式,將每個 assembly 拆成更細的 micro-operation,後面的 out-of-order execution 是對 µOP 做。
  • 第二個是可以先執行下去,如果發現搞錯了再 rollback。

像是下面的 access() 理論上不應該被執行到,但現代的 out-of-order execution 會讓 CPU 有機會先跑後面的指令,最後發現不該被執行到後,再將 register 與 memory 的資料 rollback 回來:

而 Meltdown 把後面不應該執行到 code 放上這段程式碼 (這是 Intel syntax assembly):

其中 mov al, byte [rcx] 應該要做記憶體檢查,確認使用者是否有權限存取那個位置。但這邊因為連記憶體檢查也拆成 µOP 平行跑,而產生 race condition:

Meltdown is some form of race condition between the fetch of a memory address and the corresponding permission check for this address.

而這導致後面這段不該被執行到的程式碼會先讀到資料放進 al register 裡。然後再去存取某個記憶體位置造成某塊記憶體位置被讀到 cache 裡。

造成 cache 內的資料改變後,就可以透過 FLUSH+RELOAD 技巧 (side channel) 而得知這段程式碼讀了哪一塊資料 (參考之前寫的「Meltdown 與 Spectre 都有用到的 FLUSH+RELOAD」),於是就能夠推出 al 的值...

而 Meltdown 在 mov al, byte [rcx] 這邊之所以可以成立,另外一個需要突破的地方是 [rcx]。這邊 [rcx] 存取時就算沒有權限檢查,在 virtual address 轉成 physical address 時應該會遇到問題?

原因是 LinuxOS X 上有 direct-physical map 的機制,會把整塊 physical memory 對應到 virtual memory 的固定位置上,這些位置不會再發給 user space 使用,所以是通的:

On Linux and OS X, this is done via a direct-physical map, i.e., the entire physical memory is directly mapped to a pre-defined virtual address (cf. Figure 2).

而在 Windows 上則是比較複雜,但大部分的 physical memory 都有對應到 kernel address space,而每個 process 裡面也都還是有完整的 kernel address space (只是受到權限控制),所以 Meltdown 的攻擊仍然有效:

Instead of a direct-physical map, Windows maintains a multiple so-called paged pools, non-paged pools, and the system cache. These pools are virtual memory regions in the kernel address space mapping physical pages to virtual addresses which are either required to remain in the memory (non-paged pool) or can be removed from the memory because a copy is already stored on the disk (paged pool). The system cache further contains mappings of all file-backed pages. Combined, these memory pools will typically map a large fraction of the physical memory into the kernel address space of every process.

這也是 workaround patch「Kernel page-table isolation」的原理 (看名字大概就知道方向了),藉由將 kernel 與 user 的區塊拆開來打掉 Meltdown 的攻擊途徑。

而 AMD 的硬體則是因為 mov al, byte [rcx] 這邊權限的檢查並沒有放進 out-of-order execution,所以就避開了 Meltdown 攻擊中很重要的一環。

Meltdown 與 Spectre 都有用到的 FLUSH+RELOAD

MeltdownSpectre 攻擊裡都有用到的 FLUSH+RELOAD 技巧。這個技巧是出自於 2013 年的「Flush+Reload: a High Resolution, Low Noise, L3 Cache Side-Channel Attack」。當時還因此對 GnuPG 發了一個 CVE-2013-4242

FLUSH+RELOAD 是希望透過 shared memory & cache 得到 side channel information,藉此突破安全機制。

論文裡面提到兩個攻擊模式,一種是在同一個 OS 裡面 (same-OS),另外一種是在同一台機器,但是是兩個不同的 VM (cross-VM)。攻擊的前提是要拿到與 GnuPG process 相同的 shared memory。兩個環境的作法都是透過 mmap() GnuPG 的執行檔以取得 shared memory。

在 same-OS 的情況下會使用同一個 process:

To achieve sharing, the spy mmaps the victim’s executable file into the spy’s virtual address space. As the Linux loader maps executable files into the process when executing them, the spy and the victim share the memory image of the mapped file.

在 cross-VM 的情況下會因為 hypervisor 會 dedup 而產生 shared memory:

For the cross-VM scenario we used two different hypervisors: VMware ESXi 5.1 on the HP machine and Centos 6.5 with KVM on the Dell machine. In each hypervisor we created two virtual machines, one for the victim and the other for the spy. The virtual machines run CentOS 6.5 Linux. In this scenario, the spy mmaps a copy of the victim’s executable file. Sharing is achieved through the page de-duplication mechanisms of the hypervisors.

接下來就能夠利用 cache 表演了。基本原理是「存取某一塊記憶體內容,然後計算花了多久取得,就能知道這次存取是從 L1、L2、L3 還是記憶體取得」。所以 FLUSH+RELOAD 就設計了三個步驟:

  • During the first phase, the monitored memory line is flushed from the cache hierarchy.
  • The spy, then, waits to allow the victim time to access the memory line before the third phase.
  • In the third phase, the spy reloads the memory line, measuring the time to load it.

先 flush 掉要觀察的記憶體位置 (用 clflush),然後等待一小段時間,接著掃記憶體區塊,透過時間得知有哪些被存取過 (就會比較快)。這邊跟 cache 架構有關,你不能想要偷看超過 cache 大小的量 (這樣會被 purge 出去),所以通常是盯著關鍵的部份就好。

接著是要搞 GnuPG,先看他在使用 RSA private key 計算的程式碼:

而依照這段程式碼挑好位置觀察後,就開始攻擊收資訊。隨著時間變化就可以看到這樣的資訊:

然後可以觀察出執行的順序:

於是就能夠依照執行順序推敲出 RSA key 了,而實際測試的成果是這樣,在一次的 decrypt 或是 sign 就把 RSA key 還原的差不多了 (96.7%):

We demonstrate the efficacy of the FLUSH+RELOAD attack by using it to extract the private encryption keys from a victim program running GnuPG 1.4.13. We tested the attack both between two unrelated processes in a single operating system and between processes running in separate virtual machines. On average, the attack is able to recover 96.7% of the bits of the secret key by observing a single signature or decryption round.

知道了這個方法後,看 Meltdown 或是 Spectre 才會知道他們用 FLUSH+RELOAD 的原因... (因為在 Meltdown 與 Spectre 裡面就只有帶過去)

在 TeX 上輸出圍棋棋譜的套件 psgo_emitter

忘記是在哪邊看到 avysk/psgo_emitter 這個套件,提供 TeX 語法輸出成圍棋棋盤的圖示,不過說明裡說只支援 Windows 平台:

psgo_emitter is a (Windows) console utility to create go diagrams for go life-and-death problems (tsumego).

可以只輸出角部,像是這段語法:

    \begin{psgopartialboard}{(1,1)(8,6)}
            \stone{black}{b}{3}
            \stone{black}{d}{3}
            \stone{black}{b}{4}
            \stone{white}{d}{5}
            \stone{white}{g}{2}
            \stone{black}{d}{2}
            \stone{white}{b}{5}
            \stone{white}{c}{4}
            \stone{white}{e}{4}
            \stone{white}{e}{3}
            \stone{white}{e}{2}
            \stone{black}{e}{1}
    \end{psgopartialboard}

會輸出這樣的圖:

另外也可以把手順放進去:

    \begin{psgopartialboard}{(1,1)(8,6)}
            \stone{black}{b}{3}
            \stone[\marklb{1}]{black}{a}{2}
            \stone{black}{d}{3}
            \stone{black}{b}{4}
            \stone[\marklb{8}]{white}{f}{1}
            \stone[\marklb{6}]{white}{d}{1}
            \stone{white}{e}{2}
            \stone{white}{g}{2}
            \stone{black}{d}{2}
            \stone{white}{b}{5}
            \stone[\marklb{7}]{black}{b}{2}
            \stone[\marklb{9}]{black}{a}{1}
            \stone{white}{c}{4}
            \stone[\marklb{4}]{white}{c}{2}
            \stone{white}{e}{4}
            \stone[\marklb{5}]{black}{c}{3}
            \stone{white}{e}{3}
            \stone[\marklb{2}]{white}{b}{1}
            \stone{white}{d}{5}
            \stone[\marklb{3}]{black}{a}{4}
            \stone{black}{e}{1}
    \end{psgopartialboard}

就會輸出:

套件還很新,不知道之後會發展成什麼樣子...

Linus (又) 不爽了... XD

看得出來 Linus 對於 Intel 的行為很不爽:「Re: Avoid speculative indirect calls in kernel」。

Please talk to management. Because I really see exactly two possibibilities:

 - Intel never intends to fix anything

OR

 - these workarounds should have a way to disable them.

Which of the two is it?

那個 possibibilities 應該是 typo,但不知道為什麼看起來很有味道 XDDD

Archives