AWS 將新的 Nitro 架構回過投來支援以前 Xen 的機種

Twitter 上看到 Jeff Barr 提到的這篇,講 AWS 決定讓新的 Nitro 架構支援舊的 Xen 機種:

原文是「Xen-on-Nitro: AWS Nitro for Legacy Instances」這篇,裡面雖然很美化的在講這件事情,但提到了幾個很現實的問題,第一個是仍然有大量使用者 (120 萬) 在用 Xen 架構的機器:

Today, we still have over 1.2 Million unique customers using Xen-based instances.

但這些機器其實愈來愈難維護,一方面是 Nitro 讓 AWS 省下很多軟體上的維護,另外一方面是幾乎不會有新的使用者用這些舊機種,在採購上面也會是問題。

However, the underlying hardware is old and it’s getting increasingly difficult to maintain support for these older hypervisor systems.

所以 EC2 的團隊把 Nitro 的 Xen 相容架構給實做出來,從 2022 年開始就可以全部都用 Nitro 系統,這樣對 EC2 團隊的維護成本就會大幅下降:

All of these innovations enable us to continue to offer many of our older instance types well past the lifetime of the original hardware. Starting in 2022, customers launching M1, M2, M3, C1, C3, R3, I2 and T1 instances will land on Nitro supported instances hardware and existing running instances will also be migrated.

技術債沒辦法消失,就用這種方式降低維護成本耗 XD

AWS 要推出 Graviton3 的機種了

AWS 打算要推出 Graviton3 的機種了,目前還在 preview 階段:「Join the Preview – Amazon EC2 C7g Instances Powered by New AWS Graviton3 Processors」。

目前是宣稱與前一代的 Graviton2 相比有 25% 的效能提昇,另外在浮點數與密碼相關的運算上面也會有改善 (這個效能提昇的數字應該是有指令集的幫助):

In comparison to the Graviton2, the Graviton3 will deliver up to 25% more compute performance and up to twice as much floating point & cryptographic performance. On the machine learning side, Graviton3 includes support for bfloat16 data and will be able to deliver up to 3x better performance.

另外提到了 signed pointer,可以避免 stack 被搞,不過這邊需要 OS 與 compiler 的支援,算是針對 stack 類的攻擊提出的防禦方案:

Graviton3 processors also include a new pointer authentication feature that is designed to improve security. Before return addresses are pushed on to the stack, they are first signed with a secret key and additional context information, including the current value of the stack pointer. When the signed addresses are popped off the stack, they are validated before being used. An exception is raised if the address is not valid, thereby blocking attacks that work by overwriting the stack contents with the address of harmful code. We are working with operating system and compiler developers to add additional support for this feature, so please get in touch if this is of interest to you.

然後是使用 DDR5 的記憶體:

C7g instances will be available in multiple sizes (including bare metal), and are the first in the cloud industry to be equipped with DDR5 memory. In addition to drawing less power, this memory delivers 50% higher bandwidth than the DDR4 memory used in the current generation of EC2 instances.

現在還沒看到價錢,不過有可能是跟 c6g 一樣的價位?但考慮到記憶體換架構,也有可能是貴一些的?

另外翻了一下資料,ARM 有發表過新聞稿提到 Graviton2 是 ARM 的 Cortex-M55 機種:「Designing Arm Cortex-M55 CPU on Arm Neoverse powered AWS Graviton2 Processors」,這次的 Graviton3 應該在之後完整公開後會有更多消息出來...

用 USB 供電的 CR2032/CR2016

在「USB board emulates CR2032 or CR2016 coin cell battery」這邊看到的有趣東西,用 USB 供 5V 電進來,然後轉成 3V 透過 CR2032 或是 CR2016 的鈕扣電池形式提供電源:

看說明是可以拿來開發測試用:

You can now develop CR2032 or CR2016 powered devices without having to use an actual coin cell thanks to Peter Misenko’s (Bobricius) “coin cell battery emulator CR2016/CR2032”.

看起來只要旁邊的延伸段不要卡住就可以這樣玩,不過一般開發測試板應該是有 pin 腳可以灌 3V 進去啦,算是蠻有趣的東西就是了...

Framework 筆電也遇到缺料問題,換了音源晶片

Framework 的筆電最近在社群很紅,模組化設計讓維修變容易,而且也有許多規格上的客製化空間。在「Marketplace」這頁可以看到很多東西可以換,除了比較常見的無線網卡、SSD、記憶體以外,像是主機板、鍵盤甚至連 USB、HDMI 接口都是模組。

不過這邊要提到的是 audio chip 也在這波 supply chain 的供貨問題而中招了:「Solving for Silicon Shortages」,Hacker News 上的討論「Framework: Solving for Silicon Shortages (frame.work)」也可以看一下。

從文章裡看起來是 Realtek ALC295 的交期爆炸了:

Chips that would normally have 16-20 week lead times (meaning we’d place typically binding orders that far ahead of needing parts in our hands) went up to 52 weeks. In one case, we even got notified of a 68 week lead time on a chip!

We were able to get enough Realtek ALC295 audio CODECs to develop the Framework Laptop and get through the first few months of production, but nowhere near enough to fulfill ongoing demand from the US and Canada, let alone the additional countries we’d like to ship to.

所以決定換到 Tempo 92HD95B

Luckily, we were able to find an alternative CODEC that lets us stay in production: the Tempo 92HD95B.

查了一下 datasheet,本來的 Realtek ALC295 是 QFN-48,而 Tempo 92HD95B 是 QFN-40,看起來得改不少東西... 應該是連 open market 上都翻不到而被迫換設計,跟我們家的情況也很像,看起來最近大家都哭到爆炸了 :o

Raspberry Pi 4 2GB 版本「暫時」漲價,另外 1GB 版本回歸

Raspberry Pi 宣佈 Raspberry Pi 4 的 2GB 版本將從 US$35 漲到 US$45,另外本來淘汰掉的 1GB 版本回歸,賣 US$35:「Supply chain, shortages, and our first-ever price increase」。

In February last year, we announced that we were discontinuing the 1GB variant of Raspberry Pi 4, and moving the 2GB product to our signature price of $35. We’re still glad we did this, as countless young people made use of this device as they studied from home during the pandemic.

Unfortunately, cost increases caused by the current shortage mean that this product is not currently economically viable at this reduced price point. We are therefore moving it back to $45 on a temporary basis.

To support the many industrial customers who have designed the 2GB variant of Raspberry Pi 4 into their products, we are reintroducing the 1GB variant at the $35 price point. This provides a degree of choice: less memory at the same price; or the same memory at a higher price.

然後共用 40nm 製程的 3B+ 會暫時先被降低優先權,產能會優先提供給 CM3CM3+3B

In allocating our limited stocks of 40nm silicon, we will prioritise Compute Module 3, Compute Module 3+, and Raspberry Pi 3B, and deprioritise Raspberry Pi 3B+.

整個供應鏈的情況被炸的亂七八糟...

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」。

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

Cloudflare 開始在正式環境用 ARM server 了

在「Designing Edge Servers with Arm CPUs to Deliver 57% More Performance Per Watt」這邊 Cloudflare 提到了他們在正式環境用 ARM 架構了:

Our first Arm CPU was deployed in production earlier this month — July 2021.

記得測了很多年,其中遇到測試到一半看起來還不錯,但原廠商決定不繼續做的,直到後來又有廠商投入,到現在總算是有比較成熟的產品可以用。

隔壁棚 AWS 上的 ARM 伺服器用起來也是香到不行,還沒有用過的可以試看看,至少我這台 blog & wiki 也都是跑在上面。

另外文章裡有提到目前 x86 的效能,新一代的 AMD 大概只比前一代多了 39% 的每瓦效能,但如果是把 ARM 拿進來比的話會到 57%:

Our most recently deployed generation of edge servers, Gen X, used AMD Rome CPUs. Compared with that, the newest Arm based CPUs process an incredible 57% more Internet requests per watt. While AMD has a sequel, Milan (and which Cloudflare will also be deploying), it doesn’t achieve the same degree of energy efficiency that the Arm processor does — managing only 39% more requests per watt than Rome CPUs in our existing fleet.

開始推上 production 後應該會愈換愈快,而且代表 Cloudflare 也會開始針對 ARM 平台最佳化。

又再次看到了 Spectre Mitigation 的效能損失...

Hacker News 首頁上看到的文章,講 Spectre Mitigation 的效能損失:「Spectre Mitigations Murder *Userspace* Performance In The Presence Of Frequent Syscalls」,對應的討論串在「Spectre Mitigations Murder Userspace Performance (ocallahan.org)」。

看起來作者是在調校 rr 時遇到的問題,幾年前有提到過 rr:「Microsoft 的 TTD 與 Mozilla 的 RR」。

對此作者對 rr 上了一個 patch,減少了 mitigation code 會在 syscall 時清掉 cache 與 TLB,這個 patch 讓執行的速度大幅提昇:「Cache access() calls to avoid syscalls」。

另外作者提到了他的硬體是 IntelSkylake,他又再跑一次 pre-patch 與 post-patch 的速度,可以看到在 pre-patch 前,mitigation 會讓系統慢超多 (從 2m5.776s 到 3m19.648s),而 post-patch 後大幅降低 syscall 的使用,就不會影響那麼多 (從 0m33.422s 到 0m36.160s)。

就目前知道的 mitigation 方式來說,這個猜測應該是對的...

Backblaze 的 2021Q1 硬碟報告

Backblaze 昨天放出來 2021Q1 的硬碟報告:「Backblaze Drive Stats for Q1 2021」。

前半部沒有什麼意外,HGST 的硬碟比起其他家的看起來還是好不少。

比較有趣的是首次拿 SSD 與 HDD 對決,這邊比較的對象是開機碟。可以看到如果以 2021Q1 的時間來看,SSD 的 AFR 低不少:

拉長到 lifetime 來看也還是低不少:

但裡面也有提到 HDD 的最大壽命比目前 SSD 都高不少,時間看起來可能還不夠長,算是一個很初步的資料...

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 (googleblog.com)」。

首先是這個攻擊方法在目前的瀏覽器都還有用,而且包括 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.

即使目前的瀏覽器都已經把 performance.now() 改為 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 performance.now() 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 不知道會怎樣...