在「How not to structure your database-backed web applications: a study of performance bugs in the wild」這邊看到的，裡面提到的論文是以 Rails 的 ActiveRecord 分析，不過概念上還算通用...
重點在最後一張 (Table 7 那張)：
看一下在腦裡留個印象，之後遇到的時候至少大概知道怎麼查...
Tag: bug
Home » Posts tagged "bug"
把本來 dehydrated 的 PPA 改成 dehydrated-lite
本來有做 dehydrated 的 PPA (在「PPA for dehydrated : Gea-Suan Lin」這邊)，後來在 17.10+ 就有更專業的人包進去了 (參考「Ubuntu – Package Search Results -- dehydrated」)，為了避免名稱相同但是內容物差很多，我把 PPA 的名字換成 dehydrated-lite 了 (參考「PPA for dehydrated (lite) : Gea-Suan Lin」)。
然後 0.6.2 的 dehydrated 針對 ACMEv2 有修正，這在 0.6.1 時會產生 certificate 裡有多餘資訊 (而 PPA 版的 gslin/dehydrated 只會停留在 0.6.1)，這點需要注意一下：
Don't walk certificate chain for ACMEv2 (certificate contains chain by default)
之後再找機會拔掉 gslin/dehydrated，也許會照著現在 APT 內的架構來做...
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 新聞媒體標準來看)，引用了蠻多資料並且試著說明問題。
而這也使得整個事情迅速發展與擴散超出本來的預期，使得 Google 的 Project 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.com 與 meltdownattack.com。
影響範圍包括 Intel、AMD 以及 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 來抵抗這兩套漏洞，現在也只能先等了...
用 Psalm 掃出 PHP 有問題的程式碼
Psalm 的 slogan 是「A static analysis tool for PHP」，由 Vimeo 發展並開放出來的軟體：「vimeo/psalm」。
目前是 v0.3.71，所以需要 PHP 5.6 以上才能跑：
- v0.3.x supports checking PHP 5.4 - 7.1 code, and requires PHP 5.6+ to run.
- v0.2.x supports checking PHP 5.4 - 7.0 code and requires PHP 5.4+ to run.
Psalm 主要的目標是找出哪邊「已經發生錯誤」，而不像其他幾套的目標是「預防」，這樣可以避免過高的 false alarm...
歐洲議會嘗試撥款支援 Open Source Software 的 Bug Bounty 計畫
在 Hacker News 上看到歐盟議會試著以 Bug Bounty 計畫支援 Open Source Software 的消息。這次看到的是 VLC：「VLC: Bug Bounty Program - Get Rewards through HackerOne」。
The European Parliament has approved budget to improve the EU’s IT infrastructure by extending the free software security audit programme (FOSSA) and by including a bug bounty approach in the programme.
這還蠻特別的... 由官方經費贊助 open source 的計畫，除了 VLC 外，重點會在成效以及後續還有哪些被贊助。
man 的復活節彩蛋
有人在 Unix & Linux Stack Exchange 上抱怨他的自動化測試在清晨會爛掉，但其他時間都好的：「Why does man print “gimme gimme gimme” at 00:30?」。
We've noticed that some of our automatic tests fail when they run at 00:30 but work fine the rest of the day. They fail with the message "gimme gimme gimme" in stderr, which wasn't expected. Why are we getting this output?
然後兇手跟作者都自己跑來出來說明 & 修正了 XDD
該 tweet 出自：
Dear @colmmacuait, I think that if you type "man" at 0001 hours it should print "gimme gimme gimme". #abba
— Marnanel Thurman (@marnanel) November 4, 2011
最近 man 怎麼這麼紅啊 XDDD (像是「10 Year Old Root Exploit Found in 'man' Command」)，你們這些人不要亂搞啊 XDDD 這樣很吃大家通靈的時間啊 XDDD
InnoDB 的 MVCC 繁忙時的效能問題
在 Facebook 上看到 Percona 的人修正了 InnoDB 的 MVCC 在繁忙時會有 
在 MySQL 官方的 bug tracking system 是「InnoDB's MVCC has O(N^2) behaviors」這個，可以看到給的重製範例是在 transaction 內大量塞 INSERT 進去後，另外一個 transaction 使用 secondary index 就會受到影響。
裡面也有提到「Secondary index updates make consistent reads do O(N^2) undo page lookups」，雖然修正了，但看起來跟當時實做的規劃有關？所以導致許多地方都是
這個 bug 感覺是批次作業的行為？因為批次作業可能會用 transaction 包起來，一次寫入萬筆資料後再 COMMIT 進去。而這個行為很有機會觸發這個 bug，導致影響到線上的服務...
在 Mac 上快速換輸入法的方法：Kawa
三月的時候在「在 Mac 上快速切換輸入法」這邊提到了 IMEShortcuts，但有時候還是不會生效...
在「GitHub 中那些不错的免费软件」這篇裡面提到了 open source 的 utatti/kawa 這個專案，裡面有針對 CJKV 輸入法的 bug 提供 workaround，就給個機會測試看看：
There is a known bug in the TIS library of macOS that switching keyboard layouts doesn't work well when done programmatically, especially between complex input sources like CJKV.
而且最近變得可以用 Homebrew 管理了，這樣之後升級比較方便。
PHP 的 Unquoted Strings 將在 PHP 8 被移除
Twitter 上看到 PHP 的 unquoted string 被視為字串的功能將被移除：「PHP RFC: Deprecate and Remove Bareword (Unquoted) Strings」。
常見的情境是 $_GET[bar] 這樣的用法被視為與 $_GET["bar"] 相同... 超奇怪的功能，而現在這個功能已經投票通過，將會在 7.2 被列為 deprecated，到 8 就會拿掉。
這個功能本來是標示 E_NOTICE，但比較特別的是，雖然是列為 deprecated，PHP 7.2 預定會標示為 E_WARNING 而不是 E_DEPRECATED。主要是這次的兩個目標互相衝突 (可以參考原文)，取比較有效的那個 (因為 PHP 8 就不會有這個問題了，所以 PHP 7.2 的過渡期以比較容易提醒使用者的那個為主)。
投票是 100% 通過 (41/41)。