EFIなら何も考えなくてもいいのかもしれないが、レガシーPC向けにMBRでやろうとすると微妙にはまったので

1. Windows 10 の ISO をダウンロードしてくる
   • https://www.microsoft.com/ja-jp/software-download/windows10ISO
2. これに従う
   • https://alexlubbock.com/bootable-windows-usb-on-mac
3. ブートローダーを書く
   • このリンクの Step 3 以降に従う
   • https://www.oueta.com/macos/create-windows-7-8-10-bootable-usb-drive-in-macos-with-command-line-mbr-partitioning-scheme/

ざっくりコマンドの流れを書くとこんな感じ。ディスクは /dev/disk2 とします。ツール等のリンクは参照した記事ママなので、リンク切れしていたら別のところから探してきてください。

$ brew install wimlib
$ hdiutil mount Win10_1909_Japanese_x64.iso
$ sudo diskutil eraseDisk MS-DOS "WIN10" MBR /dev/disk2

$ rsync -vha --exclude=sources/install.wim /Volumes/[isoのマウント先]/ /Volumes/WIN10
$ wimlib-imagex split /Volumes/[isoのマウント先]/sources/install.wim /Volumes/WIN10/sources/install.swm 4000

$ curl https://www.oueta.com/wp-content/uploads/2018/10/syslinux-4.03.tar.gz -o syslinux-4.03.tar.gz
$ tar -zxvf syslinux-4.03.tar.gz

$ curl https://www.oueta.com/wp-content/uploads/2018/10/syslinux-mac.tar.gz -o syslinux-mac.tar.gz
$ tar -zxvf syslinux-mac.tar.gz

$ sudo dd if=syslinux-4.03/mbr/mbr.bin of=/dev/disk2 bs=440 count=1
$ sudo ./syslinux -i /dev/disk2s1

$ mkdir /Volumes/WIN10/syslinux
$ cp syslinux-4.03/com32/modules/*.c32 /Volumes/WIN10/syslinux
$ $EDITOR /Volumes/WIN10/syslinux/syslinux.cfg

$ sudo diskutil unmountDisk disk2

$ sudo fdisk -e /dev/disk2
fdisk: 1> flag 1
Partition 1 marked active.
fdisk:*1> write
Writing MBR at offset 0.
fdisk: 1> exit
$ diskutil eject disk2

今回ご紹介するテクニックを意味不明に活用することで，18.2GBのスキャン(10円程度)で2301億行の一時テーブルを作って集計することが可能です．便利ですね．ちなみに私は12桁の数字を突然見て混乱しました．ちなみに上のクエリは37.5秒で帰ってきましたが，内部では4時間52分のCPU時間を使用したようです．つまり，単純に計算すると約500スレッドが並列して走っていたようです．すごいですね……

(注: この記事は実用性皆無です．ごく一部を除き，一般の分析用途でBigQueryを使用するユーザにはなんの利もありません)

他にも，1TB超えのデータをシャッフルすることもあり…… (シャッフルという概念は一般的なRDBMSにはなく，後述するMapReduceが持つ特徴の一つです)
1TBのデータをシャッフルできるの異常じゃないですか? DC内ネットワークすごいですね．

並列度が高いクエリだと1週間どころか2週間を超えるCPU時間を1発のクエリで使うこともあります．

さて，BigQueryのコストはスキャンするデータ量に依存します．そのため，一般的なログ分析基盤でコスト削減のためにスキャンする列を減らしたり，時系列でパーティショニングして必要な分だけスキャンする手法が取られますが，こういった話はありふれているので割愛します．

ここでの目的はスキャン量を増やすこと無くスロット時間(CPU時間)を増やすことであり，これにより同じコストでより多くのCPUを使いたいということです．とにかく多くのリソースを使うことが快楽に繋がります．

実際，上の図では31日と5時間のCPU時間をわずか66.6GBのスキャンで消費することに成功しています．
BigQueryは執筆時点で1TBスキャンするコストが$5ですから，66.6GBのスキャンはわずか30円程度です．30円でGCPのサーバを1ヶ月分動かせると考えるとお得な気がしませんか?

コストパフォーマンスを突き詰めていくと，1.6MBのデータから2時間41分のCPU時間を消費することもできます．
BigQueryは10MB以下しかスキャンしなかった場合には，10MBへ切り上げた上で課金の計算がなされますが，10MBスキャンしたところで掛かるコストは$0.00005 ですから，これは実質無料です．

一方で，複雑なクエリを叩くと実際長い時間がかかることがあります．このとき，BigQueryではクエリのタイムアウトが6時間と定められているため，これを超えるとクエリが強制終了させられます．

他にも雑に PARTITION BYを使ってパーティションを切りつつ内部でソートを掛けているとメモリを食いすぎて死んでしまったり

(意訳ですが)予想された時間を大幅に超えたのでとりあえず止めました，みたいなエラーが出たりします．
これは未だに納得がいってない．6時間動かしてから言って欲しい．

さて，我々は賢いので(?) BigQueryの内部アーキテクチャを攻略することで可能な限りこういった中断系エラーを避けつつ安価にクエリする方法を試すことができます．

BigQueryはSQLが使える分析特化のDBではありますが，中身はMapReduceだと推測され，実際クエリプランを見るとそれっぽい様子を垣間見ることができます．
MapReduceといえばHadoopやSparkが有名ですが僕は触ったことがありません．安易に解釈すると大量のマシンにデータをバラ撒いてジョインして適当に集計する，みたいな感じでしょうか．そのうち原論文をちゃんと読みたいですね．

BigQuery公式でも述べられていますが，クエリを高速に実行するためのキモはいかにうまく分散させるかに掛かっています．CPU時間を稼ぎつつ実時間を抑えるためにはこの並列数を上げるためのクエリ書換が重要になります．

今回私が実行したかったクエリは約1万行のテーブルを2重に自己結合するクエリでした．イメージとしては下のようなクエリになります．
単純にINNER JOINを2回書けばよいのですが，計算量は単純計算で1万の3乗，1兆回のループが発生します．終わりません．

SELECT *
FROM some_table src
INNER JOIN some_table a
  ON ...
INNER JOIN some_table b
  ON ...

実際にはON句での絞り込みがあるので結果セットは数分の一(それでも数千億ありますが)になるのですが，こんなクエリを素直に書いても全然スケールしません．

これは，行数が少ないテーブルのINNER JOINはあまり並列数を上げて実行してくれない現在のBigQueryのクエリ計画エンジン(?)の特性に思えます．

ちなみに BigQuery だと WITH句を使って一時テーブルの見た目をした何かを作ることができますが，これは実行プランには影響がありません．

WITH some_table_joined AS (
  SELECT *
  FROM some_table src
  INNER JOIN some_table a
    ON ...
)
SELECT *
FROM some_table_joined
INNER JOIN some_table b
  ON ...

対策として，まず自己結合を1回した一時テーブルを作り(数千万行)クエリをし，その結果テーブルに対して再度自己結合を掛けるクエリを書いたところ500スロット並列で動くことを確認しました．具体的にはクエリを次の2つに分割することになります．

-- create some_table_joined
SELECT *
FROM some_table src
INNER JOIN some_table a
  ON ...

-- join some_table_joined and some_table
SELECT *
FROM some_table_joined
INNER JOIN some_table b
  ON ...

元の1万行のデータは高々数MBしかないため，これを2重結合するクエリが動けば実質無料になるのですが，これはうまく行かず，結局自己結合した一時テーブルのスキャンに数十円程度掛かりました．それでも安いのですが……

ちなみにここで注意すべきこととして，ストレージ課金があります．BigQueryのストレージは安価とはいえ，3ヶ月以内に変更されたデータに掛かる料金，つまりActive Storageは $0.020/GB です．中間テーブルを作ってクエリが終わり，使いみちがなくなったら不要なテーブルを削除しましょう．
(実際には BigQuery でクエリしたときに勝手に作られる結果用の一時テーブル(数時間しか有効期限がない)は課金されないような気がします．僕は実験が日をまたぐこともありますし，とりあえず名前を付けてテーブルに保存していたので消す必要がありました)

他にも，やはり数千万行を超えるデータのソートは苦手なようで，なかなか苦労しました．結局PARTITION BYの中でソートをして成功したことは数えるほどしかありません．今回のケースでは諦めてMIN, MAX関数に逃げてしまいましたが，本来は一時テーブルをもう一度作らないとタイムアウト内に終わらない気がしますね．

このように，BigQueryでログデータ以外の集計をする人は実質存在しないかと思いますが，今回のケースではうまくMapReduceの特性を利用することができ，無事高速かつ安価に数千億の組み合わせを試行することができました．

おまけ

BigQueryはスキャン量に応じて課金されると書きました．つまりスキャンしないと無料です．

というわけでこういうことができます．

無限のリソースがあったら何をしますか? とりあえず面倒になったのでモンテカルロ法で円周率でも計算しましょう．とりあえずできましたが精度が低い……

ﾇｯ

こういうことをしたら終わらなくなってしまったので終わりです．(朝見たらタイムアウトしてました)
ちなみにBigQueryはJavaScriptでUDFを書くことができますが，これはこれでタイムアウトやスロット数が別にあり色々大変です．頑張りましょう．

いかがでしたか? ぜひ，皆さんもBigQueryをどんどん活用してください．

正確には、Amazon.co.jp を見たら異常に高くてそりゃ転売したら儲かるな、という気持ちになったので、適当に人を募って Amazon.com (US) で共同購入しました。
関税や送料を足した結果、YubiKey 5 NFC が5500円, YubiKey 5C が6100円ぐらいで買えました。良かったですね。

YubiKey といえばそもそも OTP が出てくるキーボードとして認識されるデバイスですが、最近だと WebAuthn で使えたりしますね。あとは PKCS#11 の署名用や適当な鍵を登録できたりします。

雑に手元の macOS でssh するぞ、と思ったら地味にハマってしまったのでいろいろやった結果動くようになったのでメモ

手順だけ分かればおっけー！という方は Gist にパッチ等まとめたので、そちらを参照してください: https://gist.github.com/kyontan/763952e7be68a2e96d5c3f0ad0d3bce8

検証環境のバージョンは macOS Mojave 10.14.4 で、OpenSSH は 7.9p1, LibreSSL 2.7.3 が入っていました。
ただ、今回は最終的に OpenSSH と OpenSSL は自前でビルドしたのであまり関係ありません。
より重要そうな Homebrew でインストールしたパッケージのバージョンは、 OpenSSH 7.9p1, OpenSSL 1.0.2r (26 Feb 2019), OpenSC 0.19.0 です。

まず、下記の記事などを参考に鍵の生成を試みます。

Putty CAC で SSH に YubiKey を使う(OpenSC編) – enjoy struggling
https://blog.haniyama.com/2018/02/02/yubikey-ssh-opensc/

GUI のツール (YubiKey PIV Manager) の場合は PIN を設定すると自動的に Authentication と Key Management 用の鍵を生成してくれます。現代だとデフォルトで ecdsa-sha2-nistp256 の鍵が生成されるんですね。便利。

公開鍵を取り出そうとした

YubiKey へのアクセスや署名(でよいのでしょうか?) にはスマートカード等で使う OpenSC を使用するようです。今回は Homebrew でインストールしました。 (brew install opensc)

早速試してみます。まずは上の

# ssh-keygen -D /usr/local/Cellar/opensc/0.19.0/lib/opensc-pkcs11.so
C_GetAttributeValue failed: 18
C_GetAttributeValue failed: 18
cannot read public key from pkcs11

うまく行きませんね。(上手く行った場合はこの記事を読む必要はありません。最後のステップまで飛ばしてください。

パッチを当てる

エラー文でググると偉大な先達の記事が出てきます。今回この記事がなかったら即死していたでしょう。

ssh with yubikey ECDSA keys – lithium03の物置
https://lithium03.info/yubikey/index.html

この記事を読むと、「RSA鍵なら問題なくいける」「OpenSSH が OpenSC を使うときに (具体的には PKCS#11 の署名等で) ECDSA鍵に対応できてない」ということが分かります。

親切にパッチや、そのパッチの元になったチケットまでリンクがあります。

2474 – Enabling ECDSA in PKCS#11 support for ssh-agent
https://bugzilla.mindrot.org/show_bug.cgi?id=2474

このチケットを見ると、Fedora 28 では既にこのパッチがバックポートされていること、upstream には OpenSSH 8.0 でマージされる予定であることが分かります。

ちなみにパッチは OpenSSH 7.6p1 用で、上の記事では 7.8p1 用に書き換えられたものが公開されていますが、現時点の Homebrew でインストール可能なのは 7.9p1 ということで、パッチを修正しました。

というわけでパッチです: https://gist.github.com/kyontan/763952e7be68a2e96d5c3f0ad0d3bce8

ビルドする

Homebrew でパッチとかどうやるんだ……と思いましたが、どうやら brew edit openssh で行けるみたいです。こんなに簡単に当てられるなんて……便利だ……

Homebrew: Patching an existing package
https://www.ralfebert.de/snippets/brew-apply-patch-to-package-formula/

というわけで雑に既に書かれている patch の下に、以下のように追記してやるとパッチが当たります。

# Add support ECDSA for PKCS11, ref: https://bugzilla.mindrot.org/show_bug.cgi?id=2474
patch do
  url "https://gist.githubusercontent.com/kyontan/763952e7be68a2e96d5c3f0ad0d3bce8/raw/2ad5f854eba7704fbb7af2182ac57ee82b9a8f61/openssh-7.9p1-pkcs11-ecdsa.patch"
  sha256 "93b4e48321db94d785833a9414b12467a4741156cec90fa3052a4092acec8938"
end

インストールは brew install --build-from-source openssh です。既にインストールしてあるものがある人は install を reinstall に読み替えてください。

ビルドできたら、ビルドした ssh や ssh-keygen のパスをよしなに通してやります。勝手に通ってるかもしれません。(rehash なりしてから ssh -V の結果を見るとかすれば分かると思います)

うおおおおお！！！！

# ssh-keygen -D /usr/local/Cellar/opensc/{version}/lib/opensc-pkcs11.so
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBDnIbZ4ANu...
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBv0e8HKnx...

というわけで公開鍵が見られました。2つ見えたのは、上で自動的に作られると行っていた Authentication と Key Management 用の鍵がどちらも見えてるからだと思います。普通は上の方を使えば良いはずです。

鍵を登録して、ssh していきます。 ssh -I /usr/local/Cellar/opensc/{version}/lib/opensc-pkcs11.so host です。

# ssh -v -I /usr/local/Cellar/opensc/0.19.0/lib/opensc-pkcs11.so user@xxx.monora.me
OpenSSH_7.9p1, OpenSSL 1.0.2r  26 Feb 2019
...
debug1: Connection established.
debug1: provider /.../opensc-pkcs11.so: manufacturerID <OpenSC Project> cryptokiVersion 2.20 libraryDescription <OpenSC smartcard framework> libraryVersion 0.19
debug1: provider /.../opensc-pkcs11.so slot 0: label <Yubico PIV Authentication> manufacturerID <piv_II> model <PKCS#15 emulate> serial <...> flags 0x40d
debug1: have 1 keys
debug1: have 2 keys
...
debug1: Will attempt key: /.../opensc-pkcs11.so ECDSA SHA256:nr/MvmFI6cYmChV97dMVIBeE2Uq5UmhVvoIdIuayLvg token
debug1: Will attempt key: /.../opensc-pkcs11.so ECDSA SHA256:Z7dluZC4FCEsUAC0HYiITr5+I83bLtHUxOwdla81Rtc token
...
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /.../opensc-pkcs11.so ECDSA SHA256:nr/MvmFI6cYmChV97dMVIBeE2Uq5UmhVvoIdIuayLvg token
debug1: Server accepts key: /.../opensc-pkcs11.so ECDSA SHA256:nr/MvmFI6cYmChV97dMVIBeE2Uq5UmhVvoIdIuayLvg token
Enter PIN for 'Yubico PIV Authentication':
debug1: Authentication succeeded (publickey).
Authenticated to xxx.monora.me ([xxx.yyy.zzz.www]:22).
...
# sl
...

というわけで ssh 出来ました。嬉しいですね。

パッチを見て当ててみたらエラーが出た瞬間にやる気をなくして、うだうだやっていたら3時間ぐらい掛かってしまいましたが、なんとか動いてよかったです。

それでは皆さまもハッピーYubiKeyライフをお過ごしください！

環境は macOS Mojave (10.14.1), Oracle VM VirtualBox のバージョンは 6.0.0 (5.2.22 でも再現)

以下、解決方法

結論から言うと「システム環境設定」-「セキュリティとプライバシー」-「一般」-「ダウンロードしたアプリケーションの実行許可」 で Oracle America, Inc かそれっぽいのを許可する。既に許可してしまったのでボタンが消えているが下の図の枠で囲った位置にボタンが出てくる。それっぽいエラーを何もユーザーへ提示せずに死ぬのでハマった。ちなみに macOS のインストーラはエラーログとかを /var/log/install.log に吐くのでそれを見ると何で落ちたのかは分かる。

installd[400]: PackageKit: ----- Begin install -----
...
installd[400]: ./postflight: /Library/Application Support/VirtualBox/VBoxDrv.kext failed to load - (libkern/kext) system policy prevents loading; check the system/kernel logs for errors or try kextutil(8).
...
Installer[9779]: Install failed: エラーによってインストールできませんでした。ソフトウェアの製造元に問い合わせてください。

ところで結局これでWindowsを起動したところで目的は達成できずに負けました。完全敗北

Touch ID が sudo でもパスワードを入力する代わりに使えそうだな、と思ったので調べてみたらどうやら pam_tid.so という PAMモジュールが用意されており、コンフィグを弄ることで使えるようです。具体的には /etc/pam.d/sudo へ auth sufficient pam_tid.so を追記するだけです。簡単ですね。

しかし、tmux のようなターミナルマルチプレクサを使用している場合にはこれだけではうまく動作せず、sudoコマンドを用いても普通にパスワードを求められてしまいます。
(これは各ユーザごとに存在する bootstrap namespace に tmux が存在しないこと? が原因のようです。詳しくは当該リポジトリに説明と詳細へのリンクがあります。)

これに対処するために pam_reattach という PAMモジュールを書いた人がいて、これが使えます。

fabianishere/pam_reattach: A pluggable authentication module that reattaches to the user’s GUI (Aqua) session on macOS

参考にした元の記事やこのリポジトリの README.md には何事もなく以下のようにやれば入ると書いてありますが、これは失敗します。

$ cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr
$ make
$ sudo make install

これは最近の macOS の保護機能の1つである System Integrity Protection が有効になっているためで、rootであっても / 配下のほとんどが書き込み不可能になっています。つまり /usr/lib/pam にビルドされた pam_reattach.so をコピーすることができず失敗します。
多分これを開発するような人は無効にしてるんじゃないでしょうか……

実は/usr/lib/pam は /usr/local/lib/pamで代替できます。というわけでそうします。具体的には以下のように PREFIX を変えるだけです。

$ cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr/local
$ make
$ sudo make install

それではよい tmux life をお過ごしください。