Netflix 找到的 TCP 實做安全性問題...

這幾天的 Linux 主機都有收到 kernel 的更新,起因於 Netflix 發現並與社群一起修正了一系列 LinuxFreeBSD 上 TCP 實做 MSSSACK 的安全性問題:「」。

其中最嚴重的應該是 CVE-2019-11477 這組,可以導致 Linux kernel panic,影響範圍從 2.6.29 開始的所有 kernel 版本。能夠升級的主機可以直接修正,無法升級的主機可以參考提出來的兩個 workaround:

Workaround #1: Block connections with a low MSS using one of the supplied filters. (The values in the filters are examples. You can apply a higher or lower limit, as appropriate for your environment.) Note that these filters may break legitimate connections which rely on a low MSS. Also, note that this mitigation is only effective if TCP probing is disabled (that is, the net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the default value for that sysctl).

Workaround #2: Disable SACK processing (/proc/sys/net/ipv4/tcp_sack set to 0).

第一個 workaround 是擋掉 MSS 過小的封包,但不保證就不會 kernel panic (文章裡面用語是 mitigation)。

第二個 workaround 是直接關掉 SACK,這組 workaround 在有 packet loss 的情況下效能會掉的比較明顯,但看起來可以避免直接 kernel panic...

把 Docker Image 轉成 VM Image


slim will build a micro-vm from a Dockerfile. Slim works by building and extracting a rootfs from a Dockerfile, and then merging that filesystem with a small minimal kernel that runs in RAM.

This results in a real VM that can boot instantly, while using very limited resources. If done properly, slim can allow you to design and build immutable unikernels for running services, or build tiny and embedded development environments.

從 screenshot 可以看到會產生 ISO Image:

產生的 ISO Image 可以透過 HyperKit (在 macOS 時) 或是 VirtualBox 跑起來。


Ubuntu 19.10 要放掉 i386 架構

Ubuntu 19.10 版將不再支援 i386 架構了:「i386 architecture will be dropped starting with eoan (Ubuntu 19.10)」。

查了一下 x86-64 條目,AMD 的第一個 x86-64 版本是在 2003 年四月推出的:

The first AMD64-based processor, the Opteron, was released in April 2003.

Intel 則是在 2004 年六月推出:

The first processor to implement Intel 64 was the multi-socket processor Xeon code-named Nocona in June 2004.

但是 mobile 版的是 2006 年七月:

The first Intel mobile processor implementing Intel 64 is the Merom version of the Core 2 processor, which was released on July 27, 2006.

不論如何都已經十年了,如果考慮到 Ubuntu 18.04 提供五年支援,其實到 2023 年四月前都還有得用...

iOS 13 與 macOS 10.15 對憑證的限制

Slack 上看到同事丟出來的,關於之後要推出的 iOS 13 與 macOS 10.15 會對憑證限制的項目:「Requirements for trusted certificates in iOS 13 and macOS 10.15」。

主要是把不安全的演算法淘汰掉 (RSA 小於 2048 bits,以及 SHA-1 類的 hash algorithm),這兩個部份相關的新聞應該不少,沒有什麼太大問題:

TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS.

TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm. SHA-1 signed certificates are no longer trusted for TLS.

然後是要求憑證使用 SAN (Subject Alternative Name),舊的標準 CN (CommonName) 將不會再被信任。

如果是公開簽發的憑證應該都沒問題 (像是 Let's Encrypt,或是花錢買的那些),主要的問題應該會出現在自己建立的憑證,網路上蠻多舊資料還是產生 CN...

TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.

另外是 2019/7/1 之後發出的憑證,有額外兩個規範要注意,第一個是強制要透過 EKU 指定 id-kp-serverAuth,這是出自 RFC 5280

   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.

再來是時間的限制,接下來的憑證最長只認得 825 天 (大約 27 個月多一些),以前都惡搞 -days 3650,現在得兩年簽一次了:

TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).


macOS 打算移除 Perl/Python/Ruby

從 beta 版的 release note 可以看到 macOS 打算在 10.15 移除 PerlPythonRuby:「macOS 10.15 Beta Release Notes」。

Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202)

看起來會另外包一份出來... 不過這樣內建的工具就少了些,雖然 shell script 是 turing machine... :o

Nokia 釋出的 Memory Profiler

Rust 開發的 memory profiler,可以抓 memory leaking 與 memory fragmentation,然後宣稱效能影響也比較低:「A memory profiler for Linux」,有提供網頁界面,還蠻美觀的:

給的範例有兩行,一行是跑 profiler:

LD_PRELOAD=./ ./your_application

另外一行是讀資料給 HTTP server:

./memory-profiler-cli server memory-profiling_*.dat


在 Raspberry Pi 上面設定 Fixed IP (Static IP)

家裡本來是用 Raspberry Pi (第一代) 跑 SmokePing 觀察有線電視提供的網路 (看品質狀況),但前陣子 SD card 掛掉了... 只好網路上找一張新的 SD card 重新裝一套系統。

在拿到卡後去 Raspberry Pi 的官網上下載最新版的 Raspbian,發現版本變新後,裡面有不少東西不一樣了 :o

固定 IP address 以前都是改 /etc/network/interfaces,但裡面可以看到還蠻有趣的警告,我就是要設定 Static IP:

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

這邊說明了如果要設定固定 IP 的話不要改這個檔案,而是修改 /etc/dhcpcd.confdhcpcd 處理。


interface eth0
static ip_address=
static routers=
static domain_name_servers=


加快 ls 的速度

看到「When setting an environment variable gives you a 40x speedup」這篇在講 ls 的速度。

文章是由 StanfordSherlock 發出來的,不過看起來跟電視劇沒關係,從網站上的標語「The HPC cluster for all your computing needs」可以看出是 HPC 相關的單位。

在 HPC 環境裡面可以預期單一目錄裡會有很多檔案,所以使用者跑來抱怨 ls 的速度就不算太意外了。不過這次使用者有提到在他自己的 laptop 上跑 ls 反而很快:

It all started from a support question, from a user reporting a usability problem with ls taking several minutes to list the contents of a 15,000+ entries directory on $SCRATCH.

Having thousands of files in a single directory is usually not very file system-friendly, and definitely not recommended. The user knew this already and admitted that wasn’t great, but when he mentioned his laptop was 1,000x faster than Sherlock to list this directory’s contents, of course, it stung. So we looked deeper.

直接跳到後面的結論... 原因是出自於因為需要顯示不同顏色,而需要透過 lstat() 查詢額外的檔案性質 (可執行、setuid 以及 setgid 這些資料),導致速度變慢:

From 13s with the default settings, to 0.3s with a small LS_COLORS tweak, that’s a 40x speedup right there, for the cheap price of not having setuid/setgid or executable files colorized differently.

Of course, this is now setup on Sherlock, for every user’s benefit.

透過設定 LS_COLORS='ex=00:su=00:sg=00:ca=00:',可以讓 lstat() 消失,所以被放進 Sherlock 的預設值了... 而沒有遇到這個問題的環境 (像是有設計好對應的目錄結構),或是想要維持原來的樣子的人,則可以 unset 掉這個值讓輸出還是有色彩差異 :o

從 Homebrew 換用 MacPorts...

看到「Thoughts on macOS Package Managers」這篇的介紹,文章作者在裡面提到從 Homebrew 換用 MacPorts 的幾個原因...

裡面有提到 root 權限的問題 (Homebrew 的 workaround),以及軟體豐富度的問題 (常用的應該都有,這邊的差異會是冷門一些的軟體)。不過這些大概都是之前都已經知道的... 比較新的是目前維護者在 integrity 上的問題:

用「How to uninstall Homebrew?」這邊的方法移除 Homebrew 後,再去 MacPorts 官網上下載檔案安裝,跑一陣子看看會不會有什麼問題...

目前看起來比較大的問題都是出自 /opt/local/{bin,sbin} 架構,這個可以靠在 /etc/profile 裡面設定解決 (不是很愛這個方法,但至少這樣會動...)。

修正 Mac 外接螢幕的 Underscan 問題

公司的 MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports) 透過 HDMI 接 Dell P2419H 一直都有 Underscan 的問題:

出自「About overscan and underscan on your Mac, Apple TV, or other display

本來想透過 Underscan slide 修改 (像是下面這張圖),但發現系統內沒有 Underscan slide。

出自「About overscan and underscan on your Mac, Apple TV, or other display

找了不少文章後後來是在「Fixing Issues with Overscan/Underscan(Black Borders) on macOS」這篇的 comment 看到解法:

Ran into this same underscan problem with black borders showing up on my new Dell 24-inch Ultrasharp U2415 connected to a 2013 Macbook Air running High Sierra, and after hours of looking into the problem the fix turned out to be super simple:

Just restart in Safe Mode.

That’s it. Restart your Mac in Safe Mode (restart, hold down the Shift key after the Apple BONG sounds, then restart normally once again for good measure. I don’t know what this clears or resets but it worked for me. No more letterboxing or black borders with the native 1920×1200 resolution selected.

So maybe something to try first for anyone coming across this post.

照著重開進 Safe mode 後再開回一般模式就正常了 (what???),先記錄起來,讓我之後遇到時可以搜尋到自己的文章...