Home » Posts tagged "linux" (Page 2)

Percona 版本的 MySQL 對於 Meltdown/Spectre 漏洞修復造成的效能損失 (Intel 平台)

而且這還不是完全修復,只是大幅降低被攻擊的機率...

PerconaUbuntu 16.04 上測試 MeltdownSpectre 這兩個安全漏洞的修正對於效能的影響。在原文標題就講了結論,為了修正 Meltdown 與 Spectre 兩個安全漏洞,效能的損失很明顯:「20-30% Performance Hit from the Spectre Bug Fix on Ubuntu」。

這邊測的結果發現,在 CPU bound 時的損失大約是 20%~25% (甚至到 30%),而 I/O bound 會輕一些,大約是 15%~20%:

We can see that in CPU-bound workloads the overhead is 20-25%, reaching up to 30% in point select queries. In IO-bound (25G buffer pool) workloads, the observed overhead is 15-20%.

在 comment 的地方 Percona 的人被問到 AMD 平台上效能會損失多少的問題,但因為他們手上目前沒有 AMD 平台的新機器所以不知道會有多少:

I do not have modern AMD servers on my hands right now

理論上 AMD 平台不需要處理 Meltdown 問題,損失應該會少一些,但沒測過也不曉得會是什麼情況... (像是 Spectre 的修正損失會不會比 Intel 還重,這之類的...)

另外補上早些時候的文章,當時 Ubuntu 上的 kernel 只有對 Meltdown 攻擊的修正,當時 Percona 的人也測了一次:「Does the Meltdown Fix Affect Performance for MySQL on Bare Metal?」,看起來對 Meltdown 攻擊的修正對效能的影響不太大,不過文裡有測試到 syscall 的效率的確如同預期掉很多。

Working Set Size (WSS) 的想法

NetflixBrendan Gregg (他比較知名的發明是 Flame Graph) 寫了一篇「How To Measure the Working Set Size on Linux」,他想要量測單位時間內會用到的記憶體區塊大小:

The Working Set Size (WSS) is how much memory an application needs to keep working. Your app may have populated 100 Gbytes of main memory, but only uses 50 Mbytes each second to do its job. That's the working set size. It is used for capacity planning and scalability analysis.

這可以拿來分析這些應用程式是否能夠利用 L1/L2/L3 cache 大幅增加執行速度,於是就可以做成圖,像是這樣:

在 Netflix 這樣人數的公司,需要設計一些有用的指標,另外發展出對應的工具,讓其他人更容易迅速掌握狀況,畢竟不是每個人都有上天下海的能力,遇到狀況可以馬上有頭緒進行 trouble shooting...

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 需要重新編過。

這次苦哈哈啊...

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

這樣習慣一些...

讀書時間: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 攻擊中很重要的一環。

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

Netflix 在 EC2 上調整的參數

Brendan GreggNetflixEC2 上調整的參數整理了出來:「AWS re:Invent 2017: How Netflix Tunes EC2」。

這些參數在 2017 的 AWS re:Invent 時有講到,他整理出來讓大家更方便參考:

My last talk for 2017 was at AWS re:Invent, on "How Netflix Tunes EC2 Instances for Performance," an updated version of my 2014 talk.

裡面有提到這是針對 Ubuntu 16.04 的調整 (而且是在 2017 年的版本,應該是 16.04.3?),用之前請理解每個參數:

WARNING: These tunables were developed in late 2017, for Ubuntu Xenial instances on EC2.

Microsoft 的 TTD 與 Mozilla 的 RR

也是個在瀏覽器 tab 上放了一陣子的連結... 先前看到 MicrosoftTime Travel Debugger (TTD),可以錄下程式執行的狀態,然後回放與搜尋:「Thoughts On Microsoft's Time-Travel Debugger」,另外有 CppCon 2017 上的影片,在 YouTube 上:

另外 Mozilla 也有類似的工具,叫做 rr (在影片開頭就有人問類似的問題 XD),程式碼在 GitHub 上:「mozilla/rr」。

而 TTD 與 rr 兩者最大的差異當然是平台支援的情況:

The most important and obvious difference between TTD and rr is that TTD is for Windows and rr is for Linux (though a few crazy people have had success debugging Windows applications in Wine under rr).

但另外一個也很重要的差異是 TTD 支援完整的 multi-threading,這對於現代的程式來說還蠻常見的:

TTD supports recording of multiple threads in parallel, while rr is limited to a single core.

當然,更完整的錄影也是要付出效能代價的:

On the other hand, per-thread recording overhead seems to be much higher in TTD than in rr. It's hard to make a direct comparison, but a simple "start Firefox, display mozilla.org, shut down" test run on similar hardware takes about 250 seconds under TTD and 26 seconds under rr.

不過有需要的時候應該會很方便?工具總是愈多愈好...

AWS 推出第二代的官方 Linux AMI:Amazon Linux 2

AWS 推出了第二代的官方 Linux AMI:「Introducing Amazon Linux 2」。這個版本提供五年 LTS 維護:

Amazon Linux 2 will offer extended availability of software updates for the core operating system through 5 years of long-term support and provides access to the latest software packages through the Amazon Linux Extras repository.

然後也大致提了一下內容物:

Amazon Linux 2 provides a modern execution environment with LTS Kernel (4.9) tuned for optimal performance on Amazon Web Services (AWS), systemd support, and newer tooling (gcc 7.2.1, glibc 2.25, binutils 2.27).

不過對 YUM-based 的系統不是很愛,應該還是會繼續龜在 Ubuntu 下...

AWS 推出可以在 Red Hat Enterprise Linux 上跑 Microsoft SQL Server 的 AMI

自從 Microsoft SQL Server 宣佈可以在 Linux 上跑後 (參考「Microsoft SQL Server 出 Linux 版...」),就沒看到什麼 Linux 上跑 SQL Server 的消息了... 結果在這波 AWS 的活動上推出了 RHEL 上跑 SQL Server 的消息:「Amazon EC2 now offers SQL Server 2017 with Red Hat Enterprise Linux 7.4」。

SQL Server 2017 is now available for Amazon EC2 instances running Red Hat Enterprise Linux (RHEL) 7.4 as an Amazon Machine Image (AMI) from the AWS Marketplace. With this release, you can now launch RHEL instances on-demand using SQL Server 2017 Enterprise License Included AMIs without having to bring your own license. SQL Server 2017 on RHEL 7.4 AMI is available in all public AWS regions starting today.

這個消息看到的時候嚇了一跳...

Archives