Mac 上 sprintf 的 scalability 問題

Hacker News 上看到個有趣的 scalability 問題,在 Mac 上的 sprintf() 因為有 lock 造成的 scalability 問題:「Curious lack of sprintf scaling (aras-p.info)」。

作者注意到 Mac 在多 CPU 下 sprintf() 會有 scalability 的問題,要注意到這邊的 Y 軸是對數比例:

用了 std::stringstream << 反而更慢 (作者還酸了一句「Zero cost abstractions」):

然後用了 Instruments 跑 profiling 找問題,可以看到看起來跟 locale 有關:

一般的情況下應該不會是問題,但如果是需要大量 sprintf() 組字串的人就會比較要注意了。

在「What else can we do?」這段有提到一些解法,包括了 stb_sprintf 當作替代品,以及 {fmt} 作為 iostreams 的替代品,然後另外是利用 to_chars 來解決,如果只是要把數字轉成字串。

算是蠻有趣的 bug hunting 過程,對於開發者來說,一般性的重點還是在 profiling,找到對的問題然後再往下提出解法...

其他非 Google 的 Email Hosting 服務

先前在「Cloudflare 的 Email Routing 功能可以讓一般人用 (包括免費帳號)」這邊有提到,因為 Google Workspace 要廢掉免費版本,所以 Cloudflare 推出了 E-mail forwarding 的方案讓大家用,所以一種簡單的解決方法就是註冊另外一個免費的 Gmail 帳號,然後用 Cloudflare 把信件 forward 到新的帳號裡。

但如果想要避開 Google 的服務的話,在 Hacker News 上的「Ask HN: Best hosted alternative to Google Workspace for email?」這邊就有討論不少可能的替代方案,主要是付費的為主。

討論裡常被提起的方案:

我自己是很愛 Fastmail,他的 webmail 界面速度很快 (即使 www.fastmail.com 需要連到美國的伺服氣上),而且鍵盤快速鍵與 Gmail 幾乎相同,所以學習成本很低,就把其中一個 domain 掛上去用,然後把一些服務的註冊 email 都往這邊掛。

而費用的部份,除了可以月繳外,年繳與三年繳都有另外再給 discount (30GB 版本是 US$5/mo、US$50/y 與 US$140/3y),第一次用一年後,後面就是刷三年了...

如果有在用 Office 的話,Microsoft 365 應該也是個選擇方案,不過我對 Outlook 的 folder-based 的設計邏輯用不慣...

然後是 iCloud+,看討論裡面提到穩定度似乎不太行,但也有人用的好好的,我自己是只有拿來同步 Apple 裝置用,沒有用到郵件服務的部份...

另外是自己有架設 Email service,話說這年頭自己搞 Email system 超麻煩的,對於沒搞過的人 SPFDKIM 加上 DMARC 絕對會搞死自己,乖乖丟雲端服務比較省事,我純粹是要保持多路暢通而已...

Apple 對 PNG 解碼的 bug

前幾天的 Hacker News Daily 上看到「PNG Parser Differential」這個,對應的討論在「PNG Parser Differential (vidbuchanan.co.uk)」這邊可以看到。

作者想要利用 threading 加速處理 PNG 格式,結果寫出了 bug,但意外發現 Apple 的 PNG decoder 也犯了一樣的問題:「Ambiguous Decodes #3」。

作者做了一個特別的 PNG 放在網站上,在非 Safari 的情況下會是:

而拿 iPhone 的 Safari 讀的話,可以看到:

應該是 implementation bug,還蠻有趣的 bug...

法院認為 Apple 必須在 12 月 9 日前開放行動平台上的第三方支付

大標題是「Judge orders Apple to allow external payment options for App Store by December 9th, denying stay」,小標題是「And Apple announces it will appeal」。

本來 Apple 想要繼續拖延,但法院直接打槍,然後 Apple 決定要再上訴到第九巡迴庭,基本上我們就是在旁邊坐著等看戲...

另外前陣子 Google 宣佈在南韓會開放其他付款機制 (參考「Google 在南韓開放 app 裡面使用其他付款機制了」),就沒看到 Apple 這邊的動作,找了一下新聞只看到 Apple 在南韓的頭決定不幹了:「Apple's top exec in South Korea departs amid dispute over App Store」,也許之後再找看看...

在非 4K 的螢幕上跑 HiDPI

前幾天看到 BetterDummy 這個專案,作者在 M1 上面外接 24" 1440p 的螢幕,但沒辦法啟用 HiDPI,於是就寫了一個軟體來解:

M1 macs tend to have issues with custom resolutions. Notoriously they don't allow sub-4K resolution displays to have HiDPI ("Retina") resolutions even though (for example) a 24" QHD 1440p display would greatly benefit from having an 1920x1080 HiDPI "Retina" mode.

在這之前的解法都有些麻煩,一種是買個 dummy dongle 去騙 macOS,另外是用 mirror 的方式使用:

To fix this issue, some resort to buying a 4K HDMI dummy dongle to fool macOS into thinking that a 4K display is connected and then mirror the contents of this dummy display to their actual monitor in order to have HiDPI resolutions available. Others use the built in screens of their MacBooks to mirror to the external display. These approaches have obvious drawbacks and cannot solve all problems.

作者提供的軟體可以先建立 Dummy Monitor,然後再透過 mirror 掛到實際螢幕上:

不確定用起來如何,但如果之後有需要的話好像可以測試看看...

在 Linux (Ubuntu) 上跑透過 QEMU 跑 Windows/Mac/Linux 的工具

Hacker News Daily 上看到的工具:「Quickly create and run optimised Windows, macOS and Linux desktop virtual machines.」,對應的討論在「Quickemu: Quickly create and run optimised Win-10,11/macOS/Linux on Linux (github.com/wimpysworld)」這邊可以看到,可以減少自己要設定一堆 QEMU 參數。

雖然專案是支援多系統,但其實 Microsoft WindowsLinux 的部份在其他虛擬軟體都很簡單 (像是用 VirtaulBox),大家馬上會注意到的重點還是 macOS 的部份,如果有自己弄過就會知道這東西有夠難裝的,而且跨版本有不同的安裝方式...

目前 Quickemu 支援四個版本:

Supported macOS releases:

  • High Sierra
  • Mojave
  • Catalina (Recommended)
  • Big Sur

然後可以看到幾乎所有目前能支援的功能都有設定上去了,包括 VirtIO 與 USB 的部份。

然後一些經典的問題,像是 Big Sur 的音源問題還是沒解:

Full Duplex audio works on macOS High Sierra, Mojave and Catalina.

  • macOS Big Sur has no audio at all.

在 Hacker News 的討論串裡面有提到有很多地方沒有檢查,這會是風險:

While I appreciate the effort, and the code is very readable. I just want to give a friendly warning that these shell scripts just download random stuff from the internet and run this random stuff without checking any integrity/signature.

下面的討論另外看到個冷知識,關於蘋果故意走 HTTP 下載 recovery image 是因為 HTTPS 太複雜,在 UEFI firmware 裡面實做容易產生被攻擊的點,所以決定自己透過其他機制確認正確性:

Apple Internet recoveryOS images are served over plain http, on purpose. The macrecovery.py script used by Quickemu uses http¹, though the server supports https.

https://support.apple.com/guide/security/recoveryos-and-diagnostics-environments-sec2512a0c09/web

> When the internet recovery and diagnostic modes were added to Mac computers in 2011, it was decided that it would be better to use the simpler HTTP transport, and handle content authentication using the chunklist mechanism, rather than implement the more complicated HTTPS functionality in the UEFI firmware, and thus increase the firmwareʼs attack surface.

¹https://github.com/acidanthera/OpenCorePkg/blob/4a740c3f256e285c66ca3b65e42b60af6826d343/Utilities/macrecovery/macrecovery.py#L123

[edit] Added macrecovery.py info

另外為了避免直接在 shell script 裡面出現「神秘字串」,可以看到特別的寫法 XDDD

Took a little while to find the magic words in there: https://github.com/wimpysworld/quickemu/blob/af26f41440d63a069045660fad860c797011310a/quickemu#L351

可以想到一些用途,像是在機房裡面跑 CI 的 worker,但要注意這個搞法不符合蘋果的 EULA,現在不抓不代表以後也不會有事,請自己謹慎評估...

然後往 ARM-based 架構後應該門檻就更高了,現在還有 Intel-based 的環境可以用加減用...

南韓對 Apple 與 Google 的 In-App 付款機制的提案

WSJ 上看到南韓對 AppleGoogle 的 in-app 付款機制提案,強制 Apple 與 Google 讓 app 的開發者 (或是開發商) 使用第三方支付平台:「Google, Apple Hit by First Law Threatening Dominance Over App-Store Payments」。

看不到 WSJ 內文的可以看「Apple and Google must allow developers to use other payment systems, new Korean law declares」這篇,裡面有引用韓國的媒體報導 (英文版):「S. Korea looks set for legislation to curb Google, Apple's in-app billing system」。

要注意這還沒有通過,目前過委員會而已 (parliamentary committee),接下來要表決才會成為正式法律。

先前美國亞利桑那州的法案被擋下來,然後參議院提的法案也還在進行中,看起來還有很硬的仗要打:「由美國參議院提出的 Open App Markets Act」。

先繼續等後續發展,可以想見 Apple 與 Google 一定會想辦法抵制...

由美國參議院提出的 Open App Markets Act

以為之前有寫過亞利桑那州的法律,結果沒找到... (有可能寫一寫就刪掉了)

三月初的時候亞利桑那州推動修正法案,強制夠大的 OS 必須開放其他的 App Store 以及 Payment 系統 (以當時,或是現在來看,應該只有 AppleiOSGoogleAndroid 這兩個系統):「Arizona advances bill forcing Apple and Google to allow Fortnite-style alternative payment options」,不過這個法案在同月月底的時候就被沒收了:「It’s game over for Arizona’s controversial App Store bill」。

這次則是由美國參議院 (上議院) 跨黨派的三位參議員提出來的 Open App Markets Act 也是類似的事情,只是拉到全國的層級:「Blumenthal, Blackburn & Klobuchar Introduce Bipartisan Antitrust Legislation to Promote App Store Competition」。在 Hacker News 上有討論:「Senators introduce bipartisan antitrust bill to promote app store competition (senate.gov)」。

第一關應該是要先讓參議院通過,在這個階段 Apple 與 Google 兩家應該就會有各種檯面上的遊說與檯面下的動作,另外像是 EpicSpotify 這些公司應該也會進去推一把...

居然在安全性漏洞的 PoC 上面看到拿 Bad Apple!! 當作範例

人在日本的資安專家 Hector Martin 找到了 Apple M1 的安全漏洞,可以不用透過 macOS Big Sur 提供的界面,直接透過 M1 的漏洞跨使用者權限傳輸資料,這可以用在突破 sandbox 的限制。而也如同目前的流行,他取了一個好記的名字:「M1RACLES: M1ssing Register Access Controls Leak EL0 State」,對應的 CVECVE-2021-30747

先講比較特別的點,PoC 的影片放在 YouTube 上,作者拿 Bad Apple!! 當作示範,這很明顯是個雙關的點:

這應該是當年的影繪版本,看了好懷念啊... 當年看到的時候有種「浪費才能」的感覺,但不得不說是個經典。

Hacker News 上有討論可以翻翻:「M1racles: An Apple M1 covert channel vulnerability (m1racles.com)」。

依照作者的說明,Apple A14 因為架構類似,也有類似的問題,不過作者沒有 iPhone,沒辦法實際測試:

Are other Apple CPUs affected?

Maybe, but I don't have an iPhone or a DTK to test it. Feel free to report back if you try it. The A14 has been confirmed as also affected, which is expected, as it is a close relative of the M1.

另外作者覺得這個安全漏洞在 macOS 上還好,主要是你系統都已經被打穿可以操控 s3_5_c15_c10_1 register 了,應該會有更好的方式可以用:

So you're telling me I shouldn't worry?

Yes.

What, really?

Really, nobody's going to actually find a nefarious use for this flaw in practical circumstances. Besides, there are already a million side channels you can use for cooperative cross-process communication (e.g. cache stuff), on every system. Covert channels can't leak data from uncooperative apps or systems.

Actually, that one's worth repeating: Covert channels are completely useless unless your system is already compromised.

比較明顯的問題應該是 iOS 這邊的 privacy issue,不過 iOS 上的 app store 有基本的保護機制:(不過想到作者可以故意寫成 RCE 漏洞...)

What about iOS?

iOS is affected, like all other OSes. There are unique privacy implications to this vulnerability on iOS, as it could be used to bypass some of its stricter privacy protections. For example, keyboard apps are not allowed to access the internet, for privacy reasons. A malicious keyboard app could use this vulnerability to send text that the user types to another malicious app, which could then send it to the internet.

However, since iOS apps distributed through the App Store are not allowed to build code at runtime (JIT), Apple can automatically scan them at submission time and reliably detect any attempts to exploit this vulnerability using static analysis (which they already use). We do not have further information on whether Apple is planning to deploy these checks (or whether they have already done so), but they are aware of the potential issue and it would be reasonable to expect they will. It is even possible that the existing automated analysis already rejects any attempts to use system registers directly.

Apple 與 Amazon 都要推出無損版的音樂串流服務了

首先是 Apple 宣佈了無損的音樂串流服務,不另外加價:「Apple Music Launching Spatial Audio With Dolby Atmos and Lossless Audio in June at No Extra Cost」,官方新聞稿在「Apple Music announces Spatial Audio with Dolby Atmos; will bring Lossless Audio to entire catalog」。

再來是 Amazon 也宣佈跟上,本來就有提供無損的 Amazon Music HD 下放到 Amazon Music Unlimited 方案也可以聽了:「Amazon Music Matching Apple by Offering Hi-Fi Tier at No Extra Cost」。

這對 Spotify 的壓力應該不小,畢竟已經先宣佈會推出無損版,但卻反而先被競爭對手出招先行制定價錢了...