美國聯邦政府 CIO 以資安理由建議安裝 ad block 軟體

Hacker News Daily 上看到的,美國聯邦政府的 CIO Clare Martorana 行文建議行政管理和預算局 (Office of Management and Budget) 安裝 ad block 軟體以確保資訊安全:「The NSA and CIA Use Ad Blockers Because Online Advertising Is So Dangerous」。行文的文件在「Wyden Letter to OMB on Ad-Blocking」這邊可以看到,另外在 Hacker News 上的討論「The NSA and CIA use ad blockers (vice.com)」也可以翻。

有很多惡意軟體 (像是 malware) 會透過合法的 ad network 散布,然後竊取資料,甚至是透過麥克風監聽環境音:

I write to urge the Office of Management and Budget (OMB) to protect federal networks from foreign spies and criminals who misuse online advertising for hacking and surveillance, by setting clear new rules for agencies in its forthcoming “zero trust” cybersecurity policy.

I have pushed successive administrations to respond more appropriately to surveillance threats, including from foreign governments and criminals exploiting online advertisingto hack federal systems. This includes seemingly innocuous online advertisements, which can be used to deliver ‘malware to phones and computers—often without requiring users to click anything. This ‘malware can steal, modify or wipe sensitive government data, or record conversations by remotely enabling a computers built-in microphone.

記得我是從 Firefox 還叫做 Phoenix 的時代就在用 ad blocker 了... 建議大家一定要裝啊,以現在來說應該都是裝 uBlock Origin,在有支援 extension 的瀏覽器都有商店可以直接安裝。

Ubuntu 14.04 與 16.04 的 ESM 從八年延長到十年

本來的舊的 Ubuntu ESM 是額外的三年 (加上本來的 LTS 五年,共八年),14.04 會支援到 2022 年四月 (參考 Internet Archive 上的存檔資料「Ubuntu 14.04 LTS has transitioned to ESM support」),然後 16.04 會支援到 2024 年四月 (參考 Internet Archive 上的存檔資料「Ubuntu 16.04 LTS transitions to Extended Security Maintenance (ESM)」),而 18.04 與 20.04 以後的 Ubuntu ESM 則是額外五年。

現在則是宣佈 14.04 與 16.04 都切齊額外五年了,所以總共都是十年:「Ubuntu 14.04 and 16.04 lifecycle extended to ten years」。

另外在 Hacker News 上的討論可以看一下:「Ubuntu 14.04 and 16.04 lifecycle extended to ten years (ubuntu.com)」,有人覺得這個政策很糟,但我覺得還好,有些商業環境就是花錢解決懶得升級... (沒有 support 只有 security update 的方案,一台實體機器才 USD$225/year,如果是虛擬機的話就更便宜了)

算是對付 legacy application 還蠻重要的方案...

用 Gecko Engine 寫的另外一個瀏覽器 Dot

Hacker News 首頁上看到 Dot 這個瀏覽器,平常看各種標語已經麻木了 (什麼 privacy enhanced 之類的),讓鄉民看上眼的是,這是一個 Gecko 寫的瀏覽器,也就是 Firefox 的底層,而不是 Blink (就 Google Chrome 那個系列):「Dot Browser – privacy-conscious web browser (github.com/dothq)」。

抓下來跑了一下,看起來就如同 GitHub 頁面上的警告:

Dot Browser is alpha software, and you will most likely experience bugs and issues!

目前功能也超陽春,還沒支援 extension 之類的東西... 不過是有內建 ad blocking 與 usercss 的能力,算是基本盤吧。

可以放著看看發展的如何...

Netflix 在單機服務 400Gbps 的影音流量

Hacker News 首頁上看到 NetflixEuroBSDCon 2021 上發表的投影片:「Serving Netflix Video at 400Gb/s on FreeBSD」,對應的討論則是在「Serving Netflix Video at 400Gb/s [pdf] (freebsd.org)」這邊可以翻到,投影片的作者有在上面回答一些問題。

投影片在講的應該就是 Netflix 的 Open Connect

主要是因為 Open Connect 的伺服器是放到各家 ISP 機房,在單一 IP 且單一伺服器的限制下,要想辦法壓榨出最高的效能。

硬體是 AMDEPYC,在先前的版本可以達到 240Gbps,經過分析與嘗試解決了一堆問題後,最後是在原來的 AMD 機器上跑到了 380Gbps (另外有測 ARM 以及 Intel 的數字),然後之後機房有可能會有 800Gbps 的標準,他們又要繼續煩惱...

有看到 Mellanox ConnectX-6 Dx (CX6-DX) 這個東西,看起來很有趣啊,有 200Gbps 的能力,而且可以把 TLS 的事情推到卡上面處理... 然後這家公司被 Nvidia 買走了。

另外當然也會有人問為什麼不用 Linux,作者在討論串裡面也有回答一些,有興趣的可以自己去搜一下。

Brendan Gregg 的工具與 profiling 技巧

這篇放在 browser tab 上一陣子了,今天找機會玩一下... 這是 Brendan Gregg 的工具,以及他說明怎麼用他來 profiling:「Analyzing a High Rate of Paging」。

裡面提到的 iostatfree 算是基本盤了,但裡面提到了很多看起來很神奇的東西,像是 biolatency、bitesize、cachestat,可以裝 bpfcc-tools 來用,檔名會加上 -bpfcc 的 suffix (像是 biolatency-bpfcc 這樣)。

三隻程式都需要 root 才能跑,對我來說,在 database 上面分析效能應該是很好用... 好像可以考慮直接當作預設安裝裝到每台機器上?

Amazon RDS 支援 ARM 架構的 t4g 與 x2g

這兩篇剛好一起看,Amazon RDS 支援了 ARM 架構的 t4gx2g:「Amazon RDS now supports X2g instances for MySQL, MariaDB, and PostgreSQL databases.」與「Amazon RDS now supports T4g instances for MySQL, MariaDB, and PostgreSQL databases.」。

目前主要是關注 t4g,因為目前量的關係反而是大量使用 t4g 類的機器,如果上面的 PostgreSQL 可以跑 t4g 的話,看起來只要沒有買 RI 的可以換過去,主要是比 t3 再省一些錢:以新加坡區的 PostgreSQL 來說,db.t4g.micro 目前是 $0.025/hr,而 db.t3.micro 則是 $0.028/hr,差不多是九折。

沒意外的話效能應該也會提昇一些,不過用 t 系列的機器本來就沒有太大的量在上面跑,這點應該是還好...

Java 17 (JDK 17),新的 Java LTS 版本 (然後來看 GC)

Java 17 (JDK 17) 釋出,這是 Oracle 本家新的 LTS 版本,引用的是 jdk-dev 的 mailing list:「Java 17 / JDK 17: General Availability」。另外在 Hacker News 上的討論可以翻一下:「Java 17 / JDK 17: General Availability (java.net)」。

上一個 LTS 版本是 Java 11,所以很自然的也會有從 Java 11 之後的新功能說明:「JEPs in JDK 17 integrated since JDK 11」。

對於只是拿來用,而不是拿來開發的人來說,我的重點都放在 JVM 的 GC 效能以及特性。

從 Java 11 預設的 G1GC 來看,可以看到一些改善,從「JEP 345: NUMA-Aware Memory Allocation for G1」(Java 14) 這個看起來會改善 G1GC 在多實體 CPU 的情況下效能,不過看起來有 -XX:+UseNUMA 這個參數要加。

再來是「JEP 346: Promptly Return Unused Committed Memory from G1」(Java 12) 可以在閒閒的時候跑個 GC 把記憶體給 OS。

接下來是兩個新的 GC (相較於 11 版),一個是 ZGC,另外一個是 Shenandoah,都沒有取代 G1GC,但兩個都有對應使用的場景。

ZGC 有列兩個 JEP:「JEP 376: ZGC: Concurrent Thread-Stack Processing」、「JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production)」,目標是讓 GC pause time 盡可能的低,另外在 wiki 上面的說明則是有提到目標在 1ms 以下:

The ZGC garbage collector (GC) aims to make GC pauses and scalability issues in HotSpot a thing of the past.

Sub-millisecond max pause times

Shenandoah 列出了「JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production)」,不過先前的「JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)」講的比較詳細,目標是希望 GC 不影響目前正在執行的程式:

Add a new garbage collection (GC) algorithm named Shenandoah which reduces GC pause times by doing evacuation work concurrently with the running Java threads. Pause times with Shenandoah are independent of heap size, meaning you will have the same consistent pause times whether your heap is 200 MB or 200 GB.

可以看出來兩個新的 GC 都是希望降低 pause time,對於 latency 敏感的應用應該都可以測試看看,可以預期整體的 throughput 會低一些。

回頭來看 G1GC,有人跑了 benchmark 測試了 Java 11 與 Java 17 的 G1GC 差異:「How much faster is Java 17?」。

可以看到 G1GC 的改善 (藍色的部份) 看起來還是不少,不過有些情況下是會變慢的。文章裡面還有提到 Parallel GC,這邊就不提了,可以自己看...

等各家 build 出來後來測看看 Cassandra 的效能影響如何...

OpenSSL 1.0.2 與 Let's Encrypt 在這個月月底的相容性問題

看到 OpenSSL 的官方居然特地寫一篇與 Let's Encrypt 的相容性問題:「Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2」。

這邊提到的 OpenSSL 1.0.2 很舊了 (在 Ubuntu 16.04 內是 1.0.2g),理論上大多數的機器應該不太會遇到這個問題。

問題出自 Let's Encrypt 舊的 DST Root CA X3 將在這個月月底過期,這在 Let's Encrypt 的「DST Root CA X3 Expiration (September 2021)」這邊也有提到。

The currently recommended certificate chain as presented to Let’s Encrypt ACME clients when new certificates are issued contains an intermediate certificate (ISRG Root X1) that is signed by an old DST Root CA X3 certificate that expires on 2021-09-30.

理想上只有要任何一條 trust chain 成立,就應該會把這個憑證認為是合法的憑證,但這在 OpenSSL 1.0.2 (以及之前的版本) 不是這樣設計。

舊版的設計是只要有任何一條過期的憑證,就會把憑證認為過期而失效:

Unfortunately this does not apply to OpenSSL 1.0.2 which always prefers the untrusted chain and if that chain contains a path that leads to an expired trusted root certificate (DST Root CA X3), it will be selected for the certificate verification and the expiration will be reported.

OpenSSL 官方給了三個 workaround 可以做,另外我還有想到一個惡搞方式,是可以用其他家免費的憑證... 不過也是得測看看在 OpenSSL 1.0.2 下會不會動。

用 Ephemeral Storage 加速 MySQL over ZFS 的效能

Percona 的「MySQL/ZFS in the Cloud, Leveraging Ephemeral Storage」這篇裡面在探討是不是可以看看 ZFS 在 Ephemeral Storage (機器附的本地硬碟) 上的效能。

一開始測試是直接當主力硬碟來測,可以看到跑 ZFS 的情況下,本地的 storage 還是會比 SSD Premium (這是 Azure 的產品線) 還快不少:

但把資料放在本地的 storage 上其實有點刺激,至少在 production 應該不太會這樣搞,所以後面用 L2ARC 的方式來測,可以看到效率提昇相當明顯,甚至接近本來直接把資料放在本地的 storage:

另外測了 ext4/bcache,看起來效率就沒那麼好:

這樣看起來是個不錯的選擇...

Intel 與 AMD 在 RSQRTSS 的不同

看到「rr Trace Portability: Diverging Behavior of RSQRTSS in AMD vs Intel」這個,作者因為在 rr 上發現 replay 不正確,發現是 SSE 裡面的 RSQRTSS 這個指令在 IntelAMD 平台上會有不同的值出現導致的。

RSQRTSS 是計算平方根倒數,也就是計算 1 / \sqrt{x},另外比較特別的是,這個指令不保證正確性,是允許有誤差產生的。

提到平方根倒數,這個演算法更有名的應該是「反平方根快速演算法」這個用到 0x5f3759df 這個魔術數字的奇技淫巧,不過這不是這次的重點...

作者發現 RSQRTSS 在 Intel 與 AMD 平台的值不一定一樣,像是 256 的平方根導數是 1/16 (0.0625),但兩個平台跑出來不同:

On Intel Skylake I get
out = 3d7ff000, float = 0.062485

On AMD Rome I get
out = 3d7ff800, float = 0.062492

在這邊的 case 可以看出來 AMD 算的比較正確 (誤差值比較低),但都還是在 spec 允許的誤差範圍。

後來作者還發現有其他不同的指令也有類似的問題,為了解決在 rr 上可以正確 replay 的問題,他生了對應的 mapping table 來解:「Emulating AMD Approximate Arithmetic Instructions On Intel」。

苦啊... 不過這個主題還蠻有趣的。