OpenBSD 6.5

平成が終了して令和が来たーーー。

2019年の4月までが平成31年で、それ以降が令和ね。

時代のエイリアス。過去はその方がわかり易いんで大いに結構。未来は何時変更になるかわからないので、西暦年がいいな。

p5.js dom

p5.js リサージュ図形

なんてのを見て楽しんでいる。translate(width/2, height/2); なんてのが出てきて、慌てて辞書を引いたりしてる自分がいる。人様のコードを見るって勉強になるなあ。

勉強と言えば、domなんていう苦手な科目が出てた。知ってはいたけど、こういうご利益があるのね。苦手を克服しなければ。

golang imports

go-import-add (Default: C-c C-a) で、pkg名を追加できるのは便利なんだけど、 vs codeには、もっと便利なのが用意されてたので、emacsからも使えるようにしておく。

go get golang.org/x/tools/cmd/goimports

(setq gofmt-command "goimports")をセットして、gofmtを上書きする。M-x gofmtで整形と同時にimportの追加と削除が行なわれるようになる。

install OpenBSD 6.5

ob$ signify -C -p /etc/signify/openbsd-65-base.pub -x SHA256.sig install65.iso 
Signature Verified
install65.iso: OK

落してきたISOに間違いが無いかOpenBSD流に確認してみた。SHA256.sigの冒頭に署名がなされているのがOpenBSDの偉い所だ。

sakae@atom:/mnt/c/Users/sakae/Downloads$ sha256sum -c SHA256.txt
sha256sum: BOOTIA32.EFI: No such file or directory
BOOTIA32.EFI: FAILED open or read
  :
install65.iso: OK

Windows10でやるなら、debianに任せればよい。ちょっと雑音が出るのでフィルターすればいいかな。

Xorg

こんな案内が出てたので試してみる。

Xorg(1). The Xorg binary is no longer installed setuid, so startx(1) can no
longer be used by non-root users. The xenodm(1) display manager has to be
used instead.

To set it up:

  # rcctl enable xenodm
  # rcctl start xenodm

If you wish to customize X you need to create an executable .xsession file.

これを実行すると、vboxのコンソールがX loginになり、1024x768のGUIが出現した。

CPU

cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2400.41 MHz, 06-4e-03
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
LUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCN
T,AES,XSAVE,AVX,RDRAND,NXE,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,AVX2,INVPCI
D,RDSEED,CLFLUSHOPT,L1DF,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: CPU supports MTRRs but not enabled by BIOS
cpu0: apic clock running at 1000MHz
cpu at mainbus0: not configured

昔は複数の石を認識してくれたと思ったど、思い過ごしかな。

copy to usb

amd64用と言うかThinkpad/E560なパソコン用にUSBメモリーを一本作っておく事にした。

とりあえず、fw_update iwm して、WIFIなドライバーを入れ、hostname.iwm0を作ってから焼いた。

doas dd if=/dev/rwd0c of=/dev/rsd0c bs=1m

焼いた後、wsconsctl.confとTERM=wsvt25の設定を加える事を思い出したけど後の祭り。

usbから動かす

何はなくともE560なパソコン用に足りないfwを追加。(fw_updateするだけだけど) そして、再起動後dmesgを確認。

cpu0: apic clock running at 23MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
  :
pchb0 at pci0 dev 0 function 0 "Intel Core 6G Host" rev 0x08
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 520" rev 0x07
drm0 at inteldrm0
inteldrm0: msi
error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load firmware i915/skl_dmc_ver1.bin (-22)
error: [drm:pid0:i915_gem_init_hw] *ERROR* Failed to initialize GuC, error -8 (ignored)
inteldrm0: 1920x1080, 32bpp

実機でもcpu1-3は認識しないなあ。初回に何か失敗でもしたんかな？まあ、このUSBは非常用という位置付なんで、真剣に悩むのは止めておこう。それから、drmが一部エラーになってるけど、大丈夫か？

そんなんで、Xを動かしてみたら、無事に動いた。firefoxと日本語フォントを追加でいれた。

ob$ doas rcctl -f start xenodm
xenodm(ok)
ob$ ps awx
  :
79421 ??  Is      0:00.07 /usr/X11R6/bin/xenodm
40440 ??  Is      0:01.69 /usr/X11R6/bin/X :0 vt05 -auth /etc/X11/xenodm/authdir/authfiles/A:0-Gkbotu (Xorg)
46150 ??  Ip      0:00.35 X: [priv] (Xorg)
94361 ??  Isp     0:00.57 xenodm: :0 (xenodm)
74811 ??  I       0:00.02 xconsole
99033 ??  Ip      0:00.05 xconsole
22088 ??  Isp     0:00.01 /bin/sh /etc/X11/xenodm/Xsession
61965 ??  Ip      0:00.00 /bin/sh /home/sakae/.xsession
60511 ??  I       0:00.15 twm
56805 ??  Ip      0:00.24 xterm

iwmは速くなったか？

Improved transmit rate selection in the iwm(4) driver.

リリースの案内にこんな事が載っていたので期待しちゃう。安易な方法で、スピード比べする。

#!/bin/sh
time curl -O https://ftp.riken.jp/pub/OpenBSD/6.5/i386/install65.iso

ギガが減るなんて事は気にしない。連休中だからビジネスの皆様にも迷惑をかける事はあるまいって判断です。

ob$ ./riken.sh                                                                                      
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  367M  100  367M    0     0  1613k      0  0:03:53  0:03:53 --:--:-- 3707k
    3m53.37s real     0m00.92s user     0m01.91s system

実際に走らせた例です。rikenの他にjaistにもご迷惑をかけてデータ取得しました。

            riken      jaist
OpenBSD     1613       1834     USBから起動した iwm0
vbox        3253       2683     Windows10上のOpenBSD em0
debian      4818       2914     32bit機 iwn0相当

数値が大きい程、高速。本当は生のWindows10の実力を知りたかったんだけど、数値化の方法が思いつかなかったんで、vbox経由での計測になっちゃった。Windows側でのwifiがvbox経由で、em0に見えるはずって寸法。

にしても、iwmを生で使うOpenBSDでは、性能が出ていないなあ。

良い事を思いついた。ブラウザーを使っちゃえ。speed testでググッて、数値化してくれるサイトを選んだ。ググルのやつだと、裏工作が心配なので、セカンドオピニオンね。相見積とかコンペみたいなものね。

Google       Down      Up
OpenBSD      24.9      18.50 Mbps
Windows      98.5      79.6
Debian       41.4      21.4

Ookla        Down      Up
OpenBSD      16.30     16.64
Windows     158.17     91.00
Debian       58.15     23.43

Windows/OpenBSD共、同一ハードウェアで規格は、IEEE802.11ac。Debianの方は、IEEE802.1nってやつ。やっぱりOpenBSDのドライバーは性能を出し切れていないね。

今月号のSDにgolangの逸品って事で、 fast-service ってのが紹介されてた。Webに頼らなくても、CUIでチェック出きるぞ。

vbox用のOpenBSD

vbox用のOpenBSDとして用意したamd64版は、マルチプロセッサーではどういう訳か有効にならなかった。実機でもだめだったのは、呆らめモード。

vmwareではOpenBSD 6.2がマルチプロセッサーで動いているから、ここで6.5を確認するって手もあるけど、面倒なんでやらない。

そんなんで、i386版をvboxに入れたよ。そしたら、4CPUでもちゃんと動いた。これで良としよう。多くを求めるな。

signify

上ででてきた、落してきたISOの確認がどんな仕組みになってるか確認してみる。

まず、6.5/i386の所から、関係者と思しきファイルを落としてきて、比べてみた。

ob$ diff -u SHA256 SHA256.sig
--- SHA256      Wed May  1 15:24:55 2019
+++ SHA256.sig  Wed May  1 15:24:08 2019
@@ -1,3 +1,5 @@
+untrusted comment: verify with openbsd-65-base.pub
+RWSZaRmt1LEQT5jTLVD6GSy5JmjT5DSHfGsH9UzLQjITpxHEdafOrwrCOkEfXGuhDrSAYt9FTJVPdLPMhJoTfJYqIgZxtkPw5QM=
 SHA256 (BUILDINFO) = fc4f7e0721af6461864b81e731dc4030d3df33a06bd090f5cf91583c95c7d685
 SHA256 (INSTALL.i386) = c6bd55de1624a90682d12da5c94d438d95b255686c6e43c5d60a7d031abc7461
 SHA256 (base65.tgz) = d5cd8ea3a9890a23111daa7bc3036ae36ef64a4cca3fe00da304f9881d6a0707

ふむ、sigの方は頭に2行分の追加があるな。これが署名データなんだろうね。

もう一つ、公開鍵と思われるやつが、/etc/signify内に格納されてるっぽい。

ob$ ls /etc/signify/
openbsd-63-base.pub        openbsd-64-pkg.pub         openbsd-66-base.pub
openbsd-63-fw.pub          openbsd-64-syspatch.pub    openbsd-66-fw.pub
openbsd-63-pkg.pub         openbsd-65-base.pub        openbsd-66-pkg.pub
openbsd-63-syspatch.pub    openbsd-65-fw.pub          openbsd-66-syspatch.pub
openbsd-64-base.pub        openbsd-65-pkg.pub
openbsd-64-fw.pub          openbsd-65-syspatch.pub

2世代前と未来の分の公開鍵があるんか。外部から取り込むデータに対して責任を持ちますって事だね。で、公開鍵ってどんなデータ？

ob$ cat /etc/signify/openbsd-65-base.pub
untrusted comment: openbsd 6.5 base public key
RWSZaRmt1LEQT9CtPygf9CvONu8kYPTlVEJdysNoUR62/NkeWgdkc3zY

そんじゃ、signify(1)に習って、署名を作り、それで検証してみるか。

ob$ echo foo >foo.txt
 :
ob$ sha256 -h SHA256 *.txt
ob$ cat SHA256
SHA256 (bar.txt) = 7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730
SHA256 (baz.txt) = 4bd70bd182bbf4bd9d2791b5a899b4cd969f5f121bc8925b7b3ef077785ae7ed
SHA256 (foo.txt) = b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c

まず、ISOファイルとかgzファイルの代わりに、適当なテキストファイルを数個用意した。そしてそれらのsha256を取って結果をSHA256ファイルに残す。

このファイルと元ファイルを改変されても、それを知る手段がない。そこで、署名付なファイルって発想が生まれる。 signifyコマンドにお任せあれ。

ob$ signify -G -p newkey.pub -s newkey.sec
passphrase:             ;; hoge
confirm passphrase:     ;; hoge
ob$ cat newkey.pub
untrusted comment: signify public key
RWSYIViS0qV7dyVvjsfzixiEG0SflMpDQK+OmXOZVtWagsQcBiOElNs9
ob$ cat newkey.sec
untrusted comment: signify secret key
RWRCSwAAACpw2dvKkrUKySHBy204UEkaet0v/JcyGHSYIViS0qV7dyY39XdA+CcWODdXwxBNScZz1WWPoNi/Z7tYbNnJrpoej7iD3Z5MgfgZWPZCnRFXI6bN4pJhYjUwA0XifHefVg8=

まず、公開鍵と秘密鍵を作成する。秘密鍵はそれを作った人しか扱えないように、パスフレーズで保護してる。

ob$ signify -S -s newkey.sec -m SHA256  -x msg.sig
passphrase:             ;; hoge
ob$ cat msg.sig
untrusted comment: verify with newkey.pub
RWSYIViS0qV7dzQtqgEygdtE3P5+poC85Sd+CuJ74/LzfOo3qAhj6EaPya04cmmdIPjv3sqR8qaRrRATTe29HCrhD0cd3xNrxgw=

次は、sha256した結果テキストに秘密鍵を使って署名する。署名データが、msg.sigに得られた。

ob$ cat msg.sig SHA256 >SHA256.sig
ob$ cat SHA256.sig
untrusted comment: verify with newkey.pub
RWSYIViS0qV7dzQtqgEygdtE3P5+poC85Sd+CuJ74/LzfOo3qAhj6EaPya04cmmdIPjv3sqR8qaRrRATTe29HCrhD0cd3xNrxgw=
SHA256 (bar.txt) = 7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730
SHA256 (baz.txt) = 4bd70bd182bbf4bd9d2791b5a899b4cd969f5f121bc8925b7b3ef077785ae7ed
SHA256 (foo.txt) = b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c

後は、それを連結。これでOpenBSDのリリース担当者がWebに上げる署名ファイルができあがった。

ob$ signify -C -p newkey.pub -x SHA256.sig bar.txt
Signature Verified
bar.txt:

署名付データを使って検証。

ob$ signify -C -p newkey.pub -x SHA256.sig foo.txt
foo.txt: FAIL

foo.txtを強引に書き換えてみた。ちゃんとエラーを検出してるね。

ob$ signify -C -p newkey.pub -x SHA256.sig foo.txt
signify: signature verification failed

書き換えたファイルのsha256を再計算させ、それをSHA256.sigに反映。こうしておいてベリファイすると、今度は署名ファイルがおかしいと言ってきた。これで、安心だね。

createsig

署名って、どうやってるんだろう？

オイラーが考えるに、SHA256のファイルのsha256を取り、それを秘密鍵で暗号化してるんだろう。こうしておけば、SHA256ファイルを作り変えても、秘密鍵を知らない限り再暗号化は不可能。

検証時は、sigファイルを2つに分解。暗号化された署名部分を公開鍵で復号。これで、SHA256のsha256値が得られる。一方の部分をその場で、sha256する。両者が一致してれば問題無し。不一致なら、どこかがおかしいって事になる。

コードの主要部分かな？

uint8_t *
createsig(const char *seckeyfile, const char *msgfile, uint8_t *msg,
    unsigned long long msglen)
         :
        SHA512Init(&ctx);
        SHA512Update(&ctx, enckey.seckey, sizeof(enckey.seckey));
        SHA512Final(digest, &ctx);
        if (memcmp(enckey.checksum, digest, sizeof(enckey.checksum)) != 0)
                errx(1, "incorrect passphrase");
        explicit_bzero(digest, sizeof(digest));

        signmsg(enckey.seckey, msg, msglen, sig.sig);
         :

と思ったら、更にこちらがあった。

static void
signmsg(uint8_t *seckey, uint8_t *msg, unsigned long long msglen,
    uint8_t *sig)
{
        unsigned long long siglen;
        uint8_t *sigbuf;

        sigbuf = xmalloc(msglen + SIGBYTES);
        crypto_sign_ed25519(sigbuf, &siglen, msg, msglen, seckey);
        memcpy(sig, sigbuf, SIGBYTES);
        free(sigbuf);
}

長くなりそうなので、次回へ持ち越しするかな。