FreeBSD 的 Firecracker 支援

Colin PercivalFreeBSD 能夠支援 Firecrack:「Announcing the FreeBSD/Firecracker platform」,成為 LinuxOSv 以外的第三個支援的作業系統。對應的 patch 在「amd64: Add FIRECRACKER kernel configuration」這邊可以看到。

接下來是反過來,要送一些 patch 進去 Firecracker,讓他支援 FreeBSD:

Now that FreeBSD supported Firecracker, there was one more thing to do: Make Firecracker support FreeBSD.

看起來是基於之前在 2020 年的 patch (但當時沒被整進去) 再修改:

Alejandro Jimenez contributed patches two years ago, but they were never merged. Some of his code ended up in the linux-loader project (which Firecracker uses); but I spent a few weeks digging through his thousand lines of changes to figure out which went into linux-loader, which still applied cleanly to Firecracker, and which I had to rewrite from scratch — a task made more difficult by the fact that Firecracker is written in Rust, and I had never used Rust before! Nevertheless, I was eventually successful, and opened a PR with updated patches which I hope to see merged into mainline Firecracker in the upcoming weeks.

看起來兩邊都有 patch 要做才能支援,目前看起來 Firecracker 這邊沒動作了,大概是沒什麼動力...

Brian Kernighan 幫 AWK 加上 Unicode 支援

看到這個 commit,裡面是 Brian KernighanAWK 加上 Unicode 支援的信件。

現在在各 OS 下都有包不一樣的 AWK 實做,像是 Linux 下常見的 GNU awk,所以這個 patch 原版的 AWK 其實還好,但更多的是一種景仰的感覺...

Brian Kernighan 就是 AWK 的作者之一 (AWK 裡的 K 就是他),另外一個更為人熟知的就是經典的 The C Programming Language 這本書,或是因此而知名的簡寫,K&R 裡面的 K。

老人家八十歲還會送 patch 給現在的 maintainer 加功能...

修正 Curl 的 TLS handshake,避開 bot 偵測機制

利用 TLS handshake 的 pattern 可以當作是某種 fingerprint,就可以知道你是用 Curl,這個方式在蠻多 CDN 都會用在 anti-bot 機制 (像是 Cloudflare),而剛剛看到有人投稿自己的 patch,試著將 Curl 修改成 Firefox 的 pattern:「curl-impersonate」,Hacker News 上的討論在這邊可以看到:「Show HN: Curl modified to impersonate Firefox and mimic its TLS handshake (」。

作者有提到這次的 patch 偏 hack,不太可能整進上游,但希望未來改的乾淨一點,然後整進上游:

I hope to do so in the future, for now the implementation is extremely hacky so I doubt it can get accepted into curl.

另外有人提出來說應該要用 Firefox ESR 版本的 pattern 而非 stable channel,也有人提出來說用 Google Chrome 的更好,不過我覺得有人開始做就已經很棒了 XD

Git 的 Diff 演算法

Lobsters Daily 上看到「When to Use Each of the Git Diff Algorithms」這篇 2020 的文章 (Lobsters 這邊常冒出一些舊文章),講 Git 的 diff 演算法。

文章裡面題到了四個演算法,看了一下 git-diff 的 manpage 也還是這四個:


另外看 manpage 時還有看到 --anchored 的用法,看起來是用來提示 Git 產生比較好懂的 diff 結果:


Generate a diff using the "anchored diff" algorithm.

This option may be specified more than once.

If a line exists in both the source and destination, exists only once, and starts with this text, this algorithm attempts to prevent it from appearing as a deletion or addition in the output. It uses the "patience diff" algorithm internally.

回頭翻了一下自己的 config repository,看起來 2017 年年底的時候我就加了「Use histogram diff algorithm.」,然後過幾天換成「Use patience algorithm.」,就一直用到現在...

這次改用 minimal 跑一陣子看看好了...

XFCE 配上 Chromium 系列瀏覽器 (Chrome/Brave/...),視窗最大化時的問題

今天發現 Brave 在視窗最大化時會超出預期的邊界,而非放大到螢幕的邊緣,找了一下發現有人已經在 Brave 的 GitHub 上開了「Incorrect scale if browser is full screen #18964」這張票,後來看到有人說在 Chromium 的 bug system 上已經有人提出來了:「Issue 1257119: Goes under the taskbar when maximized」、「Issue 1260821: maximise gets screen dimension wron」與「Issue 1261797: [User Feedback - Stable] Reports that when Chrome is maximized after being minimized, it launches to beyond the window frame on Linux」。

這次遇到的 bug 看起來是只有用 XFCE 的使用者才會中獎,目前先摸索出一套 workaround 是透過 wmctrl 操作修改瀏覽器的位置與視窗大小。

方法是先用 wmctrl -l -G 列出所有視窗的資訊,包括 geometry 的資料,接著再用 wmctrl -i -r 0x12345678 -e 0,3760,15,1232,1935 這樣的指令去指定瀏覽器的位置與視窗大小。


Linux Kernel 與明尼蘇達大學之間的攻防

Linux Kernel Community 與明尼蘇達大學 (UMN) 之間的事件差不多告一段落了,整理一下裡面比較重要的事件。隔壁棚 Basecamp 的事情還在燒,讓子彈多飛一點時間,等該跑出來的內部資訊都跑出來以後再來整理...

Linux Kernel 這件事情各家媒體都有整理出來,這邊拉 ZDNet 的文章來看:

講一下我的感想,因為 UMN 可以從這次事件證明了 Linux Kernel Community 沒有足夠的能力抵禦這類惡意攻擊,而且 Linux Kernel Community 也沒有打算解決這件事情,如果要比喻的話,很像台灣常看到的「解決發現問題的人」。

只要流程沒有改善,幾乎可以預測出之後會有政府資助的方式塞 buggy patch 進去埋洞。

作為 Linux 作業系統使用者,看起來沒什麼可以改變的,只能從架構面上設計出來安全界線,讓被攻進來時有一些防線防止直接打穿到底...

Google 釋出網頁版的 Spectre 攻擊 PoC,包括 Apple M1 在內

在大約三年前 (2018 年年初) 的時候,在讀完 Spectre 之後寫下了一些記錄:「讀書時間:Spectre 的攻擊方式」,結果在 Bruce Schneier 這邊看到消息,Google 前幾天把把 PoC 放出來了:「Exploiting Spectre Over the Internet」,在 Hacker News 上也有討論:「A Spectre proof-of-concept for a Spectre-proof web (」。

首先是這個攻擊方法在目前的瀏覽器都還有用,而且包括 Apple M1 上都可以跑:

The demonstration website can leak data at a speed of 1kB/s when running on Chrome 88 on an Intel Skylake CPU. Note that the code will likely require minor modifications to apply to other CPUs or browser versions; however, in our tests the attack was successful on several other processors, including the Apple M1 ARM CPU, without any major changes.

即使目前的瀏覽器都已經把 改為 1ms 的精度,也還是可以達到 60 bytes/sec 的速度:

While experimenting, we also developed other PoCs with different properties. Some examples include:

  • A PoC which can leak 8kB/s of data at a cost of reduced stability using as a timer with 5μs precision.
  • A PoC which leaks data at 60B/s using timers with a precision of 1ms or worse.

比較苦的消息是 Google 已經確認在軟體層沒辦法解乾淨,目前在瀏覽器上只能靠各種 isolation 降低風險,像是將不同站台跑在不同的 process 裡面:

In 2019, the team responsible for V8, Chrome’s JavaScript engine, published a blog post and whitepaper concluding that such attacks can’t be reliably mitigated at the software level. Instead, robust solutions to these issues require security boundaries in applications such as web browsers to be aligned with low-level primitives, for example process-based isolation.

Apple M1 也中這件事情讓人比較意外一點,看起來是當初開發的時候沒評估?目前傳言的 M1x 與 M2 不知道會怎樣...

GTA Online 釋出官方修正,大幅改善啟動效能

看到「GTA Online load time fix released, shaves off actual minutes of waiting for some」這邊的消息,先前在「GTA 的啟動讀取效能問題」這邊提到 GTA Online 啟動速度很慢的問題,官方正式推出修正版本了:「GTAV Title Update 1.53 Notes (PS4 / Xbox One / PC)」。

抓了一些在 Reddit 的討論「Loading Times Have FINALLY been patched - Discussion Thread」。

這則降的比率與當時 workaround 的修正差不多:

Insane. GTA menu -> GTA: Online.

Dropped from 7 minutes to 1:57

i7-2600k,GTX1070,16GB RAM and the game is on HDD.

這個就有點誇張了,這是 90% 吧?

Dropped from 5-8 minutes to 35 seconds

這個差不多 70%~80%:

Loading time 2m 20s for online directly from steam. Before it was like 8-10 minutes for me. Damn

Edit: 50s for story mode. 35s from story mode to online. So it seems it's still faster to load into online from story mode.

這個也差不多 70%:

From 4-5 minutes to 1 a minute and 22 seconds. Y e s p l e a s e

然後 PS4 的版本原來也受到一樣的影響?

Currently tested on PS4 , from main menu to online : 3min 45 sec From story mode to online: 1min 20sec (😩 i can't tell for sure )

整體看起來是正面的,畢竟大家等這個問題等超久了... 另外也可以看出來當初的 workaround patch 其實相當精準的把問題都解掉了,官方的修正並沒有快更多。

來繼續關注 libc 那邊的問題...

sscanf() 與 strlen() 的故事繼續發展

昨天在「GTA 的啟動讀取效能問題」這邊提到了 sscanf()strlen() 的問題,剛剛在 Hacker News Daily 上又看到一篇「It Can Happen to You」,在講他自己的專案也中獎。

他提到了一個解法,用 strtof() 取代 sscanf() 讀數字,結果大幅降低了 parsing 的時間:

Replacing the sscanf call with strtof improved startup by nearly a factor of 10: from 1.8 seconds to 199 milliseconds.

文章的最後面題到了不少目前正在進行中的討論與 patch。

首先是 FreeBSD 上的 patch 已經在測試:「address a performance problem w/ partial sscanf on long strings...」,裡面可以看到有很小心的在研究會不會造成 performance regression。

然後是 glibc 這邊,在 2014 年就有被開了一張票提出來:「Bug 17577 - sscanf extremely slow on large strings」,不過下面只是多了幾個 comment,目前沒有任何進度。

然後是 上的「std::scanf, std::fscanf, std::sscanf」頁面則是加注了複雜度的問題:


Not guaranteed. Notably, some implementations of sscanf are O(N), where N = std::strlen(buffer) [1]. For performant string parsing, see std::from_chars.


Python 2 的後續支援

雖然 2020/01/01 開始 Python 2 就沒有官方支援了 (翻了一下資料發現「Python 2 series to be retired by April 2020」這篇,官方好像延到四月了...),不過剛剛看到這則新聞,裡面提到了商業支援:「Snakes on a wane: Python 2 development is finally frozen in time, version 3 slithers on」。


Those catering to corporate clients intend to continue support Python 2.7 for a while. In October, Red Hat said it will stop supporting Python 2.7 in RHEL 8 come June 2024.

不確定這些 patch 會不會也移植到 CentOS 上,如果會的話,至少有一個地方可以讓你多四年掙扎,感覺上可以用 container 生一個獨立的環境...

另外 Ubuntu 這邊的 LTS 不知道有什麼方案,已知 20.04 的目標是要移除掉,但 16.04 與 18.04 裡的 Python 2 如果有問題時,不知道會不會收 patch...

再來就是 pyenv 了,翻了一下目前的情況,好像就是放著,不知道會有什麼方案搬出來...