Home » Posts tagged "arm"

Spectre 與 Meltdown 兩套 CPU 的安全漏洞

The Register 發表了「Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign」這篇文章,算是頗完整的說明了這次的安全漏洞 (以 IT 新聞媒體標準來看),引用了蠻多資料並且試著說明問題。

而這也使得整個事情迅速發展與擴散超出本來的預期,使得 GoogleProject Zero 提前公開發表了 Spectre 與 Meltdown 這兩套 CPU 安全漏洞。文章非常的長,描述的也比 The Register 那篇還完整:「Reading privileged memory with a side-channel」。

在 Google Project Zero 的文章裡面,把這些漏洞分成三類,剛好依據 CVE 編號分開描述:

  • Variant 1: bounds check bypass (CVE-2017-5753)
  • Variant 2: branch target injection (CVE-2017-5715)
  • Variant 3: rogue data cache load (CVE-2017-5754)

前兩個被稱作 Spectre,由 Google Project Zero、Cyberus Technology 以及 Graz University of Technology 三個團隊獨立發現並且回報原廠。後面這個稱作 Meltdown,由 Google Project Zero 與另外一個團隊獨立發現並且回報原廠。

這兩套 CPU 的安全漏洞都有「官網」,網址不一樣但內容一樣:spectreattack.commeltdownattack.com

影響範圍包括 IntelAMD 以及 ARM,其中 AMD 因為架構不一樣,只有在特定的情況下會中獎 (在使用者自己打開 eBPF JIT 後才會中):

(提到 Variant 1 的情況) If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU.

這次的洞主要試著透過 side channel 資訊讀取記憶體內容 (會有一些條件限制),而痛點在於修正 Meltdown 的方式會有極大的 CPU 效能損失,在 Linux 上對 Meltdown 的修正的資訊可以參考「KAISER: hiding the kernel from user space」這篇,裡面提到:

KAISER will affect performance for anything that does system calls or interrupts: everything. Just the new instructions (CR3 manipulation) add a few hundred cycles to a syscall or interrupt. Most workloads that we have run show single-digit regressions. 5% is a good round number for what is typical. The worst we have seen is a roughly 30% regression on a loopback networking test that did a ton of syscalls and context switches.

KAISER 後來改名為 KPTI,查資料的時候可以注意一下。

不過上面提到的是實體機器,在 VM 裡面可以預期會有更多 syscall 與 context switch,於是 Phoronix 測試後發現在 VM 裡效能的損失比實體機器大很多 (還是跟應用有關,主要看應用會產生多少 syscall 與 context switch):「VM Performance Showing Mixed Impact With Linux 4.15 KPTI Patches」。

With these VM results so far it's still a far cry from the "30%" performance hit that's been hyped up by some of the Windows publications, etc. It's still highly dependent upon the particular workload and system how much performance may be potentially lost when enabling page table isolation within the kernel.

這對各家 cloud service 不是什麼好消息,如果效能損失這麼大,不太可能直接硬上 KPTI patch... 尤其是 VPS,對於平常就會 oversubscription 的前提下,KPTI 不像是可行的方案。

可以看到各 VPS 都已經發 PR 公告了 (先發個 PR 稿說我們有在注意,但都還沒有提出解法):「CPU Vulnerabilities: Meltdown & Spectre (Linode)」、「A Message About Intel Security Findings (DigitalOcean)」、「Intel CPU Vulnerability Alert (Vultr)」。

現在可以預期會有更多人投入研究,要怎麼樣用比較少的 performance penalty 來抵抗這兩套漏洞,現在也只能先等了...

Cloudflare 測試 ARM 新的伺服器

Cloudflare 測試 ARM 新的伺服器 (是由 QualcommCavium 提供工程樣品給 Cloudflare 測試):「ARM Takes Wing: Qualcomm vs. Intel CPU comparison」。

原文有很多測試數據,可以看出來跟以前比起來好很多。系統程式的效能都還不錯,跟 Intel 平台各有輸贏,但 Go 對 ARM 的最佳化好像不太好,有點慘...

不過這樣至少表示了有機會互拼,如果考慮電力使用情況,加上這還是工程樣板的話,應該是可以拉板凳了?

Scaleway 的降價 (ARMv7 VPS)

Scaleway 好像知道市場的殘酷了,這次宣佈大降價:「We are slashing the C1 price by 70 percent」。

四核 ARMv7 + 2GB RAM + 50GB SSD 從本來的 €9.99/month 降到 €2.99/month,大約是 70% 的降幅。不過要記得這是未稅價,另外加上稅會變成 €3.59/month (20%),大約就是 USD$4/month 了。

這價錢可以當玩具玩玩看...

CloudFlare 宣佈停用 RC4,並且支援 ChaCha20+Poly1305

CloudFlare 同時宣佈了停用 RC4 與支援 ChaCha20+Poly1305 的計畫:「End of the road for RC4」、「Do the ChaCha: better mobile performance with cryptography」。

2014 年年初的時候,CloudFlare 先把 RC4 從 TLS 1.1+ 的連線拿掉,而 2014 年五月時,再把 RC4 搬到 cipherlist 裡優先權最低的,成功的讓 99.9991% 的 request 改用 AES3DES (大約五個 9 ):

而九個月後的現在,CloudFlare 上 RC4 使用的比率則是降到了 0.000002%,反過來說也就是 99.999998% 的等級 (七個 9),也讓 CloudFlare 決定直接停用掉 RC4。

另外一個重大的新進展則是 ChaCha20+Poly1305,兩個都是 Daniel J. Bernstein 的作品。其中 ChaCha20 是 stream cipher,Poly1305 是 MAC。

由於 RC4 已經不夠安全,在行動平台上要夠安全必須使用 AES,但 AES 在 ARM 上面還沒有普及:在 Nexus 6 用的 ARMv7 不支援,是透過 Qualcomm Snapdragon 805 的加掛模組做的,而在低階手機支援度就更不用說了。

Google 大力推動 ChaCha20+Poly1305 的目的,是為了在行動平台上找到一個與 RC4 可以匹敵的速度,而且有著可以超越 AES-GCM 安全性的 cipher+MAC。

在 CloudFlare 採用 ChaCha20+Poly1305 前,Google 是唯一一個在 HTTPS 上大幅採用的單位,而瀏覽器的部份也只有 Google Chrome 有支援。雖然 Firefox 一直有喊著要支援,但這是個雞生蛋蛋生雞的問題,可以看到進度不怎麼快 (Bug 917571 - Support ChaCha20+Poly1305 cipher suites)。

CloudFlare 支援之後,使用 ChaCha20+Poly1305 的 pool 瞬間大了不少。可以看到一上線的使用率不算低,瞬間就有 10% 了:

希望可以推動 Firefox 快一點支援... (這是養大 pool 的下一步)

各種有趣的小板子...

Slashdot 的「Ringing In 2015 With 40 Linux-Friendly Hacker SBCs」報導了「Ringing in 2015 with 40 Linux-friendly hacker SBCs」這篇文章,裡面介紹了不少可以跑 Linux 的小板子。

還蠻多有趣的板子,大多都是 ARM,不過還是有一些 x86 的板子可以玩,另外還有一張 MIPS 的板子...

另外翻了翻還看到 SAMA5D3 Xplained 這張有兩個網卡的板子 (不過是 GE + FE),好像可以拿來做些有趣的東西?

不過上次從 zonble 那邊弄來的 Raspberry Pi 好像都還沒動...

Opus 1.1 釋出...

Opus 是個 royalty-free 的 audio codec,據官方說法是個多用途的 codec (而且表現都很好):

前幾天 Opus 終於釋出 1.1 版 (1.0 版已經是一年前的事情):「Opus 1.1 Released」。

這個版本在 ARM 上的效能大幅提昇 (包括了壓縮與解壓縮),很明顯是針對行動裝置的改善:「[opus] Opus 1.1 released」。

不過好像都沒看到 bitrate 夠高時的比較...

ARM Server 與 Intel Server 的比較...

在「ARM Based Server Cluster Benchmarked」看到有人對 ARMIntel 的 x86 (x86_64) 架構比較。原文在「Calxeda's ARM server tested」,ARM 的部份是以 Calxedas 的 server 測試。

重點其實在第 13 頁:

So on the one hand, no, the current Calxeda servers are no Intel Xeon killers (yet). However, we feel that the Calxeda's ECX-1000 server node is revolutionary technology. When we ran 16 VMs (instead of 24), the dual low power Xeon was capable of achieving the same performance per VM as the Calxeda server nodes. That this 24 node system could offer 50% more throughput at 10% lower power than one of the best Xeon machines available was honestly surprising to us.

雖然知道 ARM 的單位能量所產生的效能比較好,但比我想像中少... 我以為同樣電力會到兩倍。如果只有 50%+ 的話,也難怪各家都還在評估,而非大力換掉 :o

在 Raspberry Pi 上跑 FreeBSD...

Raspberry Pi 的官方網站上提到可以在 Raspberry Pi 上跑 FreeBSD 的消息:「FreeBSD is here!」。

不過這是 community (unofficial) 版本,而且是 10-CURRENT,維護者自己也說這還不是 production-ready,主要是給大家嘗鮮用...

目前如果要拿來做一些正事,還是以 Linux 為主吧,畢竟是主力平台。

Archives