Home » Computer » Software » Archive by category "OS" (Page 3)

FreeBSD 上的 ccp (AMD Crypto Co-Processor)

看到 FreeBSD 上的「[base] Revision 328150」,將 AMD 的 AMD Crypto Co-Processor。

然後實測效能頗爛 XDDD 不過本來就不是以效能為主吧... 應該是以安全性與 Trusted Platform Module 考量?

像是 4KB buffer 的效能明顯比 AES-NI 慢了一大截 (少了一個零 XDDD):

aesni:      SHA1: ~8300 Mb/s    SHA256: ~8000 Mb/s
ccp:               ~630 Mb/s    SHA256:  ~660 Mb/s  SHA512:  ~700 Mb/s
cryptosoft:       ~1800 Mb/s    SHA256: ~1800 Mb/s  SHA512: ~2700 Mb/s

如果是 128KB buffer 時會好一些:

aesni:      SHA1:~10400 Mb/s    SHA256: ~9950 Mb/s
ccp:              ~2200 Mb/s    SHA256: ~2600 Mb/s  SHA512: ~3800 Mb/s
cryptosoft:       ~1750 Mb/s    SHA256: ~1800 Mb/s  SHA512: ~2700 Mb/s

然後 AES 也類似:

aesni:      4kB: ~11250 Mb/s    128kB: ~11250 Mb/s
ccp:               ~350 Mb/s    128kB:  ~4600 Mb/s
cryptosoft:       ~1750 Mb/s    128kB:  ~1700 Mb/s

所以是 sponsor 有認證需要的關係嗎...

Sponsored by:Dell EMC Isilon

在 ThinkPad T530 上跑 FreeBSD 的介紹

作者在「FreeBSD on a Laptop」這邊寫下了在 ThinkPad T530 上跑 FreeBSD 的完整攻略。

查了一下 ThinkPad T530,這應該是 2012 年就推出的筆電了 (五年多前),所以文章的重點在於要去那邊找解法 (i.e. 方向性)。另外作者有提到文章是假設你已經對 FreeBSD 生態算熟悉 (像是 Ports 以及 /etc 下設定檔習慣的格式與設定方式):

Unlike my usual posts, this time I'm going to assume you're already pretty familiar with FreeBSD.

然後有點無奈的地方... 即使是 2012 年的電腦,為了 driver 問題他還是得跑 -CURRENT

In my case, I run 12-CURRENT so I can take advantage of the latest Intel drivers in the graphics/drm-next-kmod port.

這有點苦 XD

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

這樣習慣一些...

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

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 來抵抗這兩套漏洞,現在也只能先等了...

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.

蘋果對於電池的新聞稿

前幾天提到 Apple 在新版 iOS 上搞出的電池問題:「iPhone 換電池恢復效能的事情傳到 Geekbench 後...」,結果看起來是 PR 部門整個加班處理 XDDD

台灣版的公告在「致廣大顧客關於 iPhone 電池與效能的說明」這邊可以看到,英文版的則是在「A Message to Our Customers about iPhone Batteries and Performance」這邊。

前面講的都是大家都已經知道的事情了,重點在後續的部份:

  • Apple 為需要更換電池的 iPhone 6 或後續機種使用者,降低更換已過保固期的 iPhone 電池價格,從 NT$2,590 降為 NT$890,降幅為 NT$1,700。自 2018 年 1 月底至 12 月,全球同步進行。詳細優惠資訊將在近期於 apple.com/tw 公布。
  • 在 2018 年初,我們將發布一項 iOS 軟體更新,其中的新功能可為使用者更清楚顯示 iPhone 電池的健康狀態,讓他們可以自己看到電池的狀態是否影響效能。
  • Apple is reducing the price of an out-of-warranty iPhone battery replacement by $50 — from $79 to $29 — for anyone with an iPhone 6 or later whose battery needs to be replaced, starting in late January and available worldwide through December 2018. Details will be provided soon on apple.com.
  • Early in 2018, we will issue an iOS software update with new features that give users more visibility into the health of their iPhone’s battery, so they can see for themselves if its condition is affecting performance.

所以總算是能在 iPhone 上面直接看到電池的情況了...

iPhone 換電池恢復效能的事情傳到 Geekbench 後...

在「iPhone 的電池與效能」這篇提到了 iPhone 換電池可以恢復效能,結果 Geekbench (也就是原來在 Reddit 上抱怨的人用的測速軟體) 的 John Poole 從 Geekbench 的回報資料庫裡分析了資料,發現了特別的現象後寫下這篇文章 (於是後來引發一連串報導,以及 Apple 的 PR 事件):「iPhone Performance and Battery Age」。

他先拿 iPhone 6S 分析,這看起來就不太妙:

再拿 iPhone 7 的資料分析,就更確定不妙:

可以看到 iOS 的 10.2.1 與 11.2.0 有奇怪的效能集中區。

後續蘋果也確認會刻意降速:「Apple addresses why people are saying their iPhones with older batteries are running ‘slower’」。

然後最新的發展就不太意外了,開始要打架了:「Days after iPhone battery fiasco, lawsuits against Apple begin to mount」。

接下來是耶誕假期,應該要等明年才會有新消息了...

Archives