幹壞事是進步最大的原動力
本來花了一些功夫整理了一下 KataGo + Lizzie 純 CPU 版本在 Windows 上的安裝方式 (在「KataGo/Windows」這邊)，後來找了一下發現早就有人做的更簡單了：「BadukMegapack」。
底層的部份除了可以選擇裝 KataGo 外，也可以選擇目前已經停止維護的 Leela Zero，或是 SAI、AQ 與 Ray。
而界面的部份除了可以用 Lizzie 外 (而且還是改過的加強版 XD)，還可以選其他的界面... 除此之外還連 JVM (Java 8) 都一起拉進來幫你裝。
看起來算是包的好好的... 看起來最困難的應該是弄一張高階顯卡了？
Dropbox 也要搞自己的密碼管理器 Dropbox Passwords：「Dropbox Passwords coming soon for all users」。
看起來只要是 Dropbox 的付費方案就可以無限使用，而免費版的則是 50 組。從下載頁看起來目前在 PC 上只支援 Microsoft Windows 與 macOS，不支援 Linux：
Come back to this page on a PC with Windows 10 or a Mac with at least macOS Sierra 10.12 to get the Passwords desktop app.
How do I use the Android and iPhone password manager?
Once you sign in to the Passwords app, it automatically fills in your usernames and passwords so you can access frequently used apps and websites on your mobile device.
從示意圖看起來有整合瀏覽器，而加密技術的部份沒有講太多，只說是 zero-knowledge encryption，先觀望看看...
Vault 是 HashiCorp 拿來管理各種敏感資訊的軟體，像是 API token 或是資料庫的帳號密碼。把這些資訊集中控管後就不需要把這些資訊放進 Git (超爽的？)，而是在需要的時候由應用程式呼叫 Vault 取得。
而 Vault 的設計裡面要求應用程式需要「認證」後才能取得，結果這個「認證」又是一組敏感資訊，這就是 Secret Zero 問題，屬於雞蛋問題的一種。
找了一輪發現 HashiCorp 自家的說明解釋的最清楚，不過這篇是放在 blog 上的文章：「Tackling the Vault Secret Zero Problem by AppRole Authentication」。
Vault 在解決 Secret Zero 的方法是使用 AppRole，這邊的認證包括了 role_id 與 secret_id 的設計。比較特別的是一組 role_id 可以有多組 secret_id 對應。
在 AppRole 這樣的設計下，權限會綁在 role_id 上，而 secret_id 則可以在部屬時動態產生，像是官方提到的 Terraform 與 Chef，或是依照組織裡面使用的管理工具：
這樣就可以透過 role_id 管理權限，但不用在 Git 裡面寫死 Secret Zero 資訊，而且每台機器都有自己的 secret_id 可以提供稽核記錄，把幾個比較明顯的問題解了不少...
在 Hacker News Daily 上看到的有趣故事，作者在 Reddit 上描述怎麼不停機把實體的伺服器搬到兩百米外的機房，中間還經過了停車場：「[Rant... sorta] Physically moved a server today...」，另外作者的 FAQ 在「[FAQ][Rant... sorta] Physically moved a server today...」這邊可以看到。
我會把這個當故事看一看就好，裡面還是有一些細節沒有被敘述 (像是網路不斷線的部份)，感覺不太對，但就一個故事來看是蠻有趣的 XD
搬運的過程中間包括了使用 UPS 與多顆 switch 對接，另外中間經過一個停車場，算是很有趣的方式？
我用 Packer 包了一個將 Lizzie (界面) + KataGo (引擎) 打包成 Amazon EC2 AMI 的設定：「packer-katago」。
這個組合應該是目前圍棋棋手最常拿來分析棋譜的工具，與之前常用的 Lizzie + Leela Zero 的差異在於 KataGo 可以分析勝率與目數，而 Leela Zero 則只能分析勝率。(參考之前寫的「用更少訓練時間的 KataGo」這篇)
早期的 KataGo 強度還沒有很強，一般還是會與 Leela Zero 交叉換著分析，但最近幾個版本的強度比之前好很多，目前看起來已經超過 Leela Zero 了 (可以參考 CGOS Whole Period Ratings for 19x19 Board 這邊列出來的排名)，另外就 YouTube 上看起來，蠻多棋手應該都是改用 KataGo 了...
不過不管是 Leela Zero 還是 KataGo 都需要夠強的 GPU 運算，之前就算用 GTX 1080 Ti 也還是覺得不夠快，就丟到 AWS 上面用看看，順便練一下手，熟悉 Packer 怎麼用。
我是設計成用 IceWM + VNC，連進去後左下的選單裡面就會有 Lizzie 可以選：
第一次跑起來會比較久，我在 p3.2xlarge 的機器上大約要等個三四分鐘，然後就會出現數字了：
看了一下運算的速度還不錯，用 spot instance 開的話，成本上應該還可以接受 (剛剛的 p3.2xlarge 是 USD$0.918/hr)。
最近開始在不同的地方會看到 KataGo 這個名字 (Twitter 與 YouTube 上都有看到)，翻了一下資料發現是在訓練成本上有重大突破，依照論文的宣稱快了五十倍...
在第一次跑的時候，只用了 35 張 V100 跑七天就有 Leela Zero 第 130 代的強度：
The first serious run of KataGo ran for 7 days in Februrary 2019 on up to 35xV100 GPUs. This is the run featured in the paper. It achieved close to LZ130 strength before it was halted, or up to just barely superhuman.
而第二次跑的時候用了 28 張 V100 跑 20 blocks 的訓練，跑了 19 天就已經超越 Facebook 當初提供的 ELFv2 版本，而對應到 Leela Zero 大約是第 200 代左右的強度 (要注意的是在 Leela Zero 這邊已經是用 40 blocks 的結構訓練了一陣子了)：
Following some further improvements and much-improved hyperparameters, KataGo performed a second serious run in May-June a max of 28xV100 GPUs, surpassing the February run after just three and a half days. The run was halted after 19 days, with the final 20-block networks reaching a final strength slightly stronger than LZ-ELFv2! (This is Facebook's very strong 20-block ELF network, running on Leela Zero's search architecture). Comparing to the yet larger Leela Zero 40-block networks, KataGo's network falls somewhere around LZ200 at visit parity, despite only itself being 20 blocks.
從論文裡面可以看到，跟 Leela Zero 一樣是逐步提昇 (應該也是用 Net2Net)，而不是一開始就拉到 20x256：
In KataGo’s main 19-day run, (b, c) began at (6, 96) and switched to (10, 128), (15, 192), and (20, 256), at roughly 0.75 days, 1.75 days, and 7.5 days, respectively. The final size approximately matches that of AlphaZero and ELF.
訓練速度上會有這麼大的改善，分成兩個類型，一種是一般性的 (在「Major General Improvements」這章)，另外一類是特定於圍棋領域的改進 (在「Major Domain-Specific Improvements」這章)。
在 Leela Zero 的 issue tracking 裡面也可以看到很多關於 KataGo 的消息，看起來作者也在裡面一起討論，應該會有一些結果出來...
看到「圍棋ＡＩ與ＡＷＳ」這篇譯文，原文是「囲碁AIブームに乗って、若手棋士の間で「AWS」が大流行 その理由とは？」。
沒有太意外是使用 Leela Zero + Lizzle，畢竟這是 open source project，在軟體與資料的取得上相當方便，而且在好的硬體上已經可以超越人類頂尖棋手。
由於在 Lizzle 的介面上可以看到勝率，以及 Leela Zero 考慮的下一手 (通常會有多個選點)，而且當游標移到這些選點上以後，還會有可能的變化圖可以看，所以對於棋手在熟悉操作介面後，可以很快的擺個變化圖，然後讓 Leela Zero 分析後續的發展，而棋手就可以快速判斷出「喔喔原來是這樣啊」。
網路上也有類似的自戰解說，可以看到棋手對 Lizzle 的操作與分析 (大約從 50:50 開始才是 Lizzle 的操作)：
不過話說回來，幹壞事果然是進步最大的原動力... 讓一群對 AWS 沒什麼經驗的圍棋棋手用起 AWS，而且還透過 AMI 與 spot instance 省錢... XD
The Register 發表了「Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign」這篇文章，算是頗完整的說明了這次的安全漏洞 (以 IT 新聞媒體標準來看)，引用了蠻多資料並且試著說明問題。
而這也使得整個事情迅速發展與擴散超出本來的預期，使得 Google 的 Project Zero 提前公開發表了 Spectre 與 Meltdown 這兩套 CPU 安全漏洞。文章非常的長，描述的也比 The Register 那篇還完整：「Reading privileged memory with a side-channel」。
在 Google Project Zero 的文章裡面，把這些漏洞分成三類，剛好依據 CVE 編號分開描述：
前兩個被稱作 Spectre，由 Google Project Zero、Cyberus Technology 以及 Graz University of Technology 三個團隊獨立發現並且回報原廠。後面這個稱作 Meltdown，由 Google Project Zero 與另外一個團隊獨立發現並且回報原廠。
這兩套 CPU 的安全漏洞都有「官網」，網址不一樣但內容一樣：spectreattack.com 與 meltdownattack.com。
影響範圍包括 Intel、AMD 以及 ARM，其中 AMD 因為架構不一樣，只有在特定的情況下會中獎 (在使用者自己打開 eBPF JIT 後才會中)：
(提到 Variant 1 的情況) If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU.
這次的洞主要試著透過 side channel 資訊讀取記憶體內容 (會有一些條件限制)，而痛點在於修正 Meltdown 的方式會有極大的 CPU 效能損失，在 Linux 上對 Meltdown 的修正的資訊可以參考「KAISER: hiding the kernel from user space」這篇，裡面提到：
KAISER will affect performance for anything that does system calls or interrupts: everything. Just the new instructions (CR3 manipulation) add a few hundred cycles to a syscall or interrupt. Most workloads that we have run show single-digit regressions. 5% is a good round number for what is typical. The worst we have seen is a roughly 30% regression on a loopback networking test that did a ton of syscalls and context switches.
KAISER 後來改名為 KPTI，查資料的時候可以注意一下。
不過上面提到的是實體機器，在 VM 裡面可以預期會有更多 syscall 與 context switch，於是 Phoronix 測試後發現在 VM 裡效能的損失比實體機器大很多 (還是跟應用有關，主要看應用會產生多少 syscall 與 context switch)：「VM Performance Showing Mixed Impact With Linux 4.15 KPTI Patches」。
With these VM results so far it's still a far cry from the "30%" performance hit that's been hyped up by some of the Windows publications, etc. It's still highly dependent upon the particular workload and system how much performance may be potentially lost when enabling page table isolation within the kernel.
這對各家 cloud service 不是什麼好消息，如果效能損失這麼大，不太可能直接硬上 KPTI patch... 尤其是 VPS，對於平常就會 oversubscription 的前提下，KPTI 不像是可行的方案。
可以看到各 VPS 都已經發 PR 公告了 (先發個 PR 稿說我們有在注意，但都還沒有提出解法)：「CPU Vulnerabilities: Meltdown & Spectre (Linode)」、「A Message About Intel Security Findings (DigitalOcean)」、「Intel CPU Vulnerability Alert (Vultr)」。
現在可以預期會有更多人投入研究，要怎麼樣用比較少的 performance penalty 來抵抗這兩套漏洞，現在也只能先等了...
Leela 的作者 Gian-Carlo Pascutto 依照 paper 的描述寫完了，放在 GitHub 上的 gcp/leela-zero：
I made an open source re-implementation of AlphaGo Zero: https://t.co/p8H6gGohA1
It just needs a good weights file.
— Gian-Carlo Pascutto (@gcpascutto) October 24, 2017
不過他在 Twitter 上也提到了，open source 實做不是真正的困難，真正的困難在於訓練完的資料，那個部份需要大量的成本才有辦法作到：
Every redditor is asking to opensource AlphaGo Zero, when all we really need are those last 500k self-play games.
— Gian-Carlo Pascutto (@gcpascutto) October 19, 2017
另外他推估 AlphaGo Zero 的計算量是 1700 年 (以 1080 Ti 來計算)：「[Computer-go] Zero performance」。
另外 Leela 0.11.0 也推出了，還是先維持 policy + value 的方式，但引入了不少新演算法加強。另外一個蠻特別的地方是 Windows 版改用 clang 而變快不少：
Windows version is now compiled with Clang/LLVM 5.0 instead of MSVC2017. This makes the Monte Carlo evaluations about 15% faster.
雖然 DeepMind 說要收手，但還是留下不少方向讓大家走...
Adam Langley 的「Testing Security Keys」這篇測試了不少有支援 U2F Security Key 的產品，這邊作者是以 Linux 環境測試。
tl;dr：在 Linux 環境下，除了 Yubico 的產品沒問題外，其他的都有問題... (只是差在問題多與少而已)
Yubico 的沒找到問題：
Easy one first: I can find no flaws in Yubico's U2F Security Key.
VASCO SecureClick 的則是 vendor ID 與 product ID 會跑掉：
If you're using Linux and you configure udev to grant access to the vendor ID & product ID of the token as it appears normally, nothing will work because the vendor ID and product ID are different when it's active. The Chrome extension will get very confused about this.
Feitian ePass 的 ASN.1 DER 編碼是錯的：
ASN.1 DER is designed to be a “distinguished” encoding, i.e. there should be a unique serialisation for a given value and all other representations are invalid. As such, numbers are supposed to be encoded minimally, with no leading zeros (unless necessary to make a number positive). Feitian doesn't get that right with this security key: numbers that start with 9 leading zero bits have an invalid zero byte at the beginning. Presumably, numbers starting with 17 zero bits have two invalid zero bytes at the beginning and so on, but I wasn't able to press the button enough times to get such an example. Thus something like one in 256 signatures produced by this security key are invalid.
Thetis 根本沒照 spec 走，然後也有相同的 ASN.1 DER 編碼問題：
With this device, I can't test things like key handle mutability and whether the appID is being checked because of some odd behaviour. The response to the first Check is invalid, according to the spec: it returns status 0x9000 (“NO_ERROR”), when it should be 0x6985 or 0x6a80. After that, it starts rejecting all key handles (even valid ones) with 0x6a80 until it's unplugged and reinserted.
This device has the same non-minimal signature encoding issue as the Feitian ePass. Also, if you click too fast, this security key gets upset and rejects a few requests with status 0x6ffe.
U2F Zero 直接 crash 沒辦法測 XDDD：
A 1KiB ping message crashes this device (i.e. it stops responding to USB messages and needs to be unplugged and reinserted). Testing a corrupted key handle also crashes it and thus I wasn't able to run many tests.
KEY-ID (網站連 HTTPS 都沒上...) / HyperFIDO 也有編碼問題但更嚴重：
The Key-ID (and HyperFIDO devices, which have the same firmware, I think) have the same non-minimal encoding issue as the Feitian ePass, but also have a second ASN.1 flaw. In ASN.1 DER, if the most-significant bit of a number is set, that number is negative. If it's not supposed to be negative, then a zero pad byte is needed. I think what happened here is that, when testing the most-significant bit, the security key checks whether the first byte is > 0x80, but it should be checking whether it's >= 0x80. The upshot is the sometimes it produces signatures that contain negative numbers and are thus invalid.
所以還是乖乖用 GitHub 帳號買 Yubico 吧...