幹壞事是進步最大的原動力
看到「What exactly was the point of [ “x$var” = “xval” ]?」這篇，在講為什麼不直接寫 [ "$var" = "val" ] 而是會加上 x 而寫成 [ "x$var" = "xval" ]，被稱為 x-hack 的 workaround... (其實已經變成 best practice 了)
最常被拿出來講的是 - 開頭的字串，不過文章作者找到更多奇怪的 bug report，像是 ( 與 ) 之類的問題 XD
雖然作者提到大概在 2010 (或是 2015) 都修完了，但我應該還是會繼續這樣寫 (算是 best practice 了)，可以避免在遇到老系統上遇到問題...
在 Hacker News 首頁上看到「How to bypass Cloudflare bot protection (jychp.medium.com)」這則，裡面的文章是「How to bypass CloudFlare bot protection ?」這篇，利用 Cloudflare Workers 繞過 Cloudflare 自家的 CAPTCHA 機制。
這個漏洞有先被送給 Cloudflare，但被認為不是問題，所以作者就決定公開：
Several months ago I submitted what appeared to be a security flaw to CloudFalre’s bugbounty program. According to them, this is not a problem, it’s up to you to make up your own mind.
技術上就是透過 Cloudflare Workers 當作 proxy server，只是看起來 Cloudflare 對自家 IP 有特別處理，在設定妥當後，用 Cloudflare Workers 的 IP address 去連 Cloudflare 的站台，幾乎不會觸發 Cloudflare 的阻擋機制。
不過 free tier 還是有限制，主要就是數量：
The first 100,000 requests each day are free and paid plans start at just $5/10 million requests, making Workers as much as ten-times less expensive than other serverless platforms.
作者也有提到這點：
So let’s enjoy the 100 000 request/day for your free Cloudflare account and go scrape the world !
但這是個有趣的方法，加上信用卡盜刷之類的方式，這整包看起來就很有威力...
上個禮拜丟出來很轟動的一篇「side project」，三個月不斷的打穿蘋果的企業網路：「We Hacked Apple for 3 Months: Here’s What We Found」，對應的 Hacker News 討論可以在「We Hacked Apple for 3 Months (samcurry.net)」這邊看到。
在最後面有提到這本來是打好玩的，但後來就投入愈來愈多時間進去：
This was originally meant to be a side project that we'd work on every once in a while, but with all of the extra free time with the pandemic we each ended up putting a few hundred hours into it.
這是五個人通力合作打了三個月出來的成果，依照他們的回報數字，共打出了 55 個「洞」，考慮到週休的情況，幾乎是天天打洞出來玩：
There were a total of 55 vulnerabilities discovered with 11 critical severity, 29 high severity, 13 medium severity, and 2 low severity reports. These severities were assessed by us for summarization purposes and are dependent on a mix of CVSS and our understanding of the business related impact.
文章裡沒有對每個安裝漏洞都描述，但有針對一些比較「有趣」的漏洞說明，雖然看了以後知道是怎麼一回事，但對這些手法沒這麼熟，你叫我打我還是不會打啊 XDDD 反而是當作表演藝術來看...
Mass Effect 是個 2007 在 Xbox 上推出的遊戲，並且在 2008 推出 Windows 版，這個遊戲在 2011 年 AMD 推出的 CPU 上 (Bulldozer)，某些場景會產生人物黑塊的 bug，社群有些猜測但一直都沒被證實，作者一路追出不少問題，並且給了一個還算乾淨的 workaround：「Fixing Mass Effect black blobs on modern AMD CPUs」，另外在 Hacker News 上有很精彩的討論：「Fixing Mass Effect black blobs on modern AMD CPUs (cookieplmonster.github.io)」。
這篇主要是看趣味的，裡面的狀況有點複雜。
社群有一些 workaround 可以避開這個問題，作者後來是從關閉 PSGP (Processor Specific Graphics Pipeline) 的方法找問題，然後發現在計算時會產生出 NaN 的問題，所以導致貼出來的圖就變成黑塊了...
一路追下去，發現遊戲本身好像沒什麼大問題，但跟 Direct3D 裡面的 D3DXMatrixInverse 有關，會依照 CPU 的支援度決定怎麼跑：
- Disabling PSGP makes both Intel and AMD take a regular
x86code path.- Intel CPUs always take an
intelsse2code path.- AMD CPUs supporting 3DNow! take a
amd_mmx_3dnoworamd3dnow_amdmmxcode path, while CPUs without 3DNow take anintelsse2code path.
會有這些邏輯是因為 AMD 在 2010 後決定放生 3DNow!，所以會需要這樣判斷。
接著寫了一隻小程式測試，用 memcmp() 判斷是不是一樣，結果發現 AMD 的 SSE2 跑出來的程式不被遊戲接受：(不一樣是正常的，因為這些指令本來就沒有要求完全正確，是可以接受誤差的)
接著就是翻資料，可以知道 XMMatrixInverse 算是接班人：
I figured that since we were to replace that matrix function anyway, I could try replacing it with
XMMatrixInversebeing a “modern” replacement forD3DXMatrixInverse.XMMatrixInversealso uses SSE2 instructions so it should be equally optimal to the D3DX function, but I was nearly sure it would break the same way.
所以就弄個一個 DLL，把本來呼叫 D3DXMatrixInverse 的部份用 XMMatrixInverse 改寫換掉：「SilentPatchME/source/D3DXMatrix.cpp」，這個方式算是乾淨的 workaround 掉，保持 API 相容性，以及該有的加速能力 (由 XMMatrixInverse 提供)。
Hacker News 上有討論到 Intel 與 AMD 這些指令在 SSE2 上的誤差值，都是在規格要求的範圍內：
Const-me 14 hours ago [–]
Here’s Intel versus AMD relative error of RCPPS instruction: http://const.me/tmp/vrcpps-errors-chart.png AMD is Ryzen 5 3600, Intel is Core i3 6157U.
Over the complete range of floats, AMD is more precise on average, 0.000078 versus 0.000095 relative error. However, Intel has 0.000300 maximum relative error, AMD 0.000315.Both are well within the spec. The documentation says “maximum relative error for this approximation is less than 1.5*2^-12”, in human language that would be 3.6621E-4.
Source code that compares them by creating 16GB binary files with the complete range of floats: https://gist.github.com/Const-me/a6d36f70a3a77de00c61cf4f6c17c7ac
至於為什麼會生出 NaN 的原因，沒找出來還是有點可惜，不過這個解法還行，就是「新版的 library 既然沒問題，就大家也不要太計較舊版的問題」的概念...
這是 Jespen 第一次測試 PostgreSQL，就順利找出可重製的 bug 了：「PostgreSQL 12.3」。
第一個 bug 是 REPEATABLE READ 下的問題，不過因為 SQL-92 定義不夠嚴謹的關係，其實算不算是 bug 有討論的空間，這點作者 Kyle Kingsbury 在文章裡也有提出來：
Whether PostgreSQL’s repeatable-read behavior is correct therefore depends on one’s interpretation of the standard. It is surprising that a database based on snapshot isolation would reject the strict interpretation chosen by the seminal paper on SI, but on reflection, the behavior is defensible.
另外一個就比較沒問題了，是 SERIALIZABLE 下的 bug，在 SQL-92 下對 SERIALIZABLE 的定義是這樣：
The execution of concurrent SQL-transactions at isolation level SERIALIZABLE is guaranteed to be serializable. A serializable execution is defined to be an execution of the operations of concurrently executing SQL-transactions that produces the same effect as some serial execution of those same SQL-transactions. A serial execution is one in which each SQL-transaction executes to completion before the next SQL-transaction begins.
也就是說，在 SERIALIZABLE 下一堆 transaction 的執行結果，你至少可以找到一組排序，使得這些 transaction 的結果是等價的。
而 Jespen 順利找出了一組 transaction (兩個 transaction)，在 SERIALIZABLE 下都成功 (但不應該成功)：
對於這兩個 transaction，不論是上面這條先執行，還是下面這條先執行，都不存在等價的結果，所以不符合 SERIALIZABLE 的要求。
另外也找到一個包括三個 transaction 的情況：
把 transaction 依照執行的結果把 dependency 拉出來，就可以看出來裡面產生了 loop，代表不可能在 SERIALIZABLE 下三個都成功。
在 Jespen 找到這些 bug 後，PostgreSQL 方面也找到軟體內產生 bug 的部份，並且修正了：「Avoid update conflict out serialization anomalies.」，看起來是在 PostgreSQL 引入 Serializable Snapshot Isolation (SSI) 的時候就有這個 bug，所以 9.1 以後的版本都有這個問題...
這次順利打下來，測得很漂亮啊... 翻了一下 Jespen 上的記錄，發現好像還沒測過 MySQL，應該會是後續的目標？
在正妹 wens 的 Facebook 上看到的，Intel 的 RDRAND 因為有安全漏洞 (CrossTalk/SRBDS)，新推出的修正使得 RDRAND 只有原來的 3% 效能：
從危機百科上看，大概是因為這個指令集有 compliance 的要求，所以這個安全性漏洞必須在安全性上修到乾淨，所以使用了暴力鎖硬解，造成效能掉這麼多：
The random number generator is compliant with security and cryptographic standards such as NIST SP 800-90A, FIPS 140-2, and ANSI X9.82.
不過畢竟這個指令不是常常被使用，一般使用者的影響應該是還好：
As explained in the earlier article, mitigating CrossTalk involves locking the entire memory bus before updating the staging buffer and unlocking it after the contents have been cleared. This locking and serialization now involved for those instructions is very brutal on the performance, but thankfully most real-world workloads shouldn't be making too much use of these instructions.
另外這個漏洞早在 2018 九月的時候就通報 Intel 提了，但最後花了超過一年半時間才更新，這算是當初在提 Bug Bounty 制度時可能的缺點，在這次算是比較明顯：
We disclosed an initial PoC (Proof-Of-Concept) showing the leakage of staging buffer content in September 2018, followed by a PoC implementing cross-core RDRAND/RDSEED leakage in July 2019. Following our reports, Intel acknowledged the vulnerabilities, rewarded CrossTalk with the Intel Bug Bounty (Side Channel) Program, and attributed the disclosure to our team with no other independent finders. Intel also requested an embargo until May 2020 (later extended), due to the difficulty of implementing a fix for the cross-core vulnerabilities identified in this paper.
回到原來的 bug，主要還是 Intel 架構上的問題造成大家打得很愉快，現在 Intel 這邊的架構對於資安研究員仍然是個大家熱愛的地方... (因為用的使用者太多)
Let's Encrypt 發現在檢查 CAA 的程式碼有問題，發了說明：「2020.02.29 CAA Rechecking Bug」，以及預定的處理方式：「Revoking certain certificates on March 4」。
問題是當一個 certificate request 包含了 N 個 domain 時，本來的 CAA 檢查應該要對這 N 個檢查，但程式寫成只會抓一個，然後檢查了 N 次：
The bug: when a certificate request contained N domain names that needed CAA rechecking, Boulder would pick one domain name and check it N times. What this means in practice is that if a subscriber validated a domain name at time X, and the CAA records for that domain at time X allowed Let’s Encrypt issuance, that subscriber would be able to issue a certificate containing that domain name until X+30 days, even if someone later installed CAA records on that domain name that prohibit issuance by Let’s Encrypt.
2020/02/29 發現的，就程式碼的部屬時間，發現應該從去年 2019/07/25 開始就有這個 bug：
We confirmed the bug at 2020-02-29 03:08 UTC, and halted issuance at 03:10. We deployed a fix at 05:22 UTC and then re-enabled issuance.
Our preliminary investigation suggests the bug was introduced on 2019-07-25. We will conduct a more detailed investigation and provide a postmortem when it is complete.
然後決定要 revoke 這些可能會有問題的 SSL certificate，大約佔現有還有效的 SSL certificate 的 2.6%，大約三百萬筆：
Q: How many certificates are affected?
A: 2.6%. That is 3,048,289 currently-valid certificates are affected, out of ~116 million overall active Let’s Encrypt certificates. Of the affected certificates, about 1 million are duplicates of other affected certificates, in the sense of covering the same set of domain names.
在「Check whether a host's certificate needs replacement」這邊可以偵測線上使用的 SSL certificate 是否受到影響。
另外在「Download affected certificate serials for 2020.02.29 CAA Rechecking Incident」這邊可以抓到所有受到影響，預定要 revoke 的 SSL certificate 的序號。關於取得序號的方式，官方也有提供 CLI 的指令可以操作確認，對於有很多網域名稱需要確認的人可以用這組指令編寫程式判斷：
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial\ Number | tr -d :
照目前的描述，如果申請時只有一個 domain 應該是不會中這個問題，再來是最壞的情況大概會維持三個月 (網站主人沒管他，等到時間到了自動 renew)。
上個禮拜四家裡的桌機開不了機，找了一天發現是系統的 SSD 掛掉了，就買了張 M.2 SSD，然後計畫順便把本來的 Ubuntu 16.04 升級到 Ubuntu 18.04，但 Ubuntu 18.04 把預設的界面從 Unity 換成 GNOME (然後披上 Unity 的皮)，加上前陣子系統從 Intel 平台換到 AMD，整個狀況變得超混亂之後，就變成一連串踩地雷的過程...
最一開始是 UEFI + LUKS 的安裝問題，本來想裝到 M.2 SSD 上面，但 Ubuntu 18.04 的 grub-install 就是硬寫到 /dev/sda 不能改：「“Unable to install GRUB in /dev/sda” when installing GRUB」，照著這篇的 workaround 用還是不行，最後放棄，直接生一顆 SATA SSD 接到 SATA Port 1，把 M.2 當作資料碟。
硬體相關的問題：
ifconfig 或是 ip link 這樣的指令)。軟體相關的問題：
pppoeconf 設定會比較好，然後可以改 /etc/ppp/options 加上 IPv6 的設定。現在至少是堪用的程度了，接下來就是不斷的補各種設定...
既然有方向了，後續應該會有人去找底層的問題...
先是在 Hacker News 上看到「Speculative fix to crashes from a CPU bug」這個猜測性的修正，這是因為他們發現在 Intel 的 Gemini Lake 低功耗晶片組上會發生很詭異的 crash：
For the last few months Chrome has been seeing many "impossible" crashes on Intel Gemini Lake, family 6 model 122 stepping 1 CPUs. These crashes only happen with 64-bit Chrome and only happen in the prologue of two functions. The crashes come and go across different Chrome versions.
然後依照 crash log 猜測跟 alignment 有關，所以決定用 gcc/clang 都有支援的 __attribute__ 強制設定 alignment 來避開，但看起來手上沒有可以重製的環境，所以只能先把實做丟上來...
在 Hacker News Daily 上看到 Reddit 上面有一篇對 AWS Management Console 的抱怨文，差不多是兩個月前開始累積的：「I am stupefied every day by the awfulness of the AWS web console」。
AWS 的主力開發因為是以 API 為主，而 AWS Management Console 能做的事情一直都少蠻多的 (看起來是一個團隊在開發，然後呼叫 API)，而且的確是常常中 bug，所以會有這樣的抱怨其實不太意外...
然後就有人放火了：
[–]canadian_sysadmin 24 points 2 months ago
I see you've never used Azure...
[–]myron-semack 18 points 2 months ago
AWS’s console sucks because they don’t give a damn about UI. They are API-first.Azure’s console sucks because they tried to make it nice but failed.
[–]ryantiger658 5 points 2 months ago
I was scrolling looking for this comment. Azures interface has made me appreciate AWS even more.
Azure 被偷戳了好幾下 XDDD 然後 GCP 也被偷戳了：
[–]edgan 1 point 2 months ago
It could br better, but it is far better than than Azure and GCP. Azure's old one was better than their new beta interface last I saw it. GCP has some interesting ideas, but the side bar centric design doesn't function well. It also tries to do too much, and is too JavaScript-y happy.
通常用 AWS 自己的 CloudFormation 或是第三方的 Terraform 管理還是比較常見的方式 (基於 Infrastructure as code 的概念)，而 AWS Managemenet Console 當作是輔助，因為目前的雲端服務在設計上的確是希望你多用 API...