幹壞事是進步最大的原動力
看得出來 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
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 編號分開描述：
前兩個被稱作 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 的 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...
在 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 外，重點會在成效以及後續還有哪些被贊助。
有人在 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
在 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 上快速切換輸入法」這邊提到了 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 管理了，這樣之後升級比較方便。
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)。
Short Version：遇到這個問題，只要把作業系統從 10.10 更新到 10.12 就好了：「Mac Users Reporting Widespread System Freezes With OS X El Capitan 10.11.4 Update」。
之前 MBPR 在過保後掛過一次送修 (常常無法開機，開起來後鍵盤與觸控板都沒有反應)，當時把鍵盤與觸控板都換掉... 結果前幾天發生觸控板的壓力回饋失效的問題 (還是可以移動滑鼠游標與輕觸)，但這幾天要去日本，想帶著處理事情，就先上 24h 買個 Magic Mouse 2 應急 (用 lightning 充電的那個版本，被嘲笑很醜的那個 XD)。
買回來後發現 Magic Mouse 2 的多點觸控與電量資訊沒有顯示在系統裡，翻了資料才發現要 10.11 之後的版本：
Bluetooth-enabled Mac computer with OS X v10.11 or later
耐著性子升級想說出國前至少把問題解決一些，升完後發現觸控板的回饋就回來了... 然後查資料發現是系統的 bug 造成的：
The freeze seems to affect not only the screen and mouse cursor but also the Mac's Force Touch trackpad, which completely loses feedback.
好吧就這樣吧 orz
在「Security fixes for Libgcrypt and GnuPG 1.4 [CVE-2016-6316]」這邊看到這個歷史悠久的 bug：
Felix Dörre and Vladimir Klebanov from the Karlsruhe Institute of Technology found a bug in the mixing functions of Libgcrypt's random number generator: An attacker who obtains 4640 bits from the RNG can trivially predict the next 160 bits of output. This bug exists since 1998 in all GnuPG and Libgcrypt versions.
就這樣的行為，對於自己用的機器應該是還好... 不過得到 4640 bits 後就可以預測接下來的 160 bits，這個 RNG 有點囧 @_@
官方目前是認為應該還好：
A first analysis on the impact of this bug in GnuPG shows that existing RSA keys are not weakened. For DSA and Elgamal keys it is also unlikely that the private key can be predicted from other public information. This needs more research and I would suggest _not to_ overhasty revoke keys.
不過如果你有絕對的安全需求的話還是可以考慮 revoke 再重新生一把...