HiFive Premier P550を手に入れた

SiFive P550というコア使ったHiFive Premiver P550というボードを入手した。メモリ16GBが日本円で約60000円強。前買ったUnmatchedはドルだと$250高かったけど、円的にはそんなに変わらず。円安...

Install Ubuntu to SSD

確かまだPremier P550対応のDTSなどLinuxのコードはメインラインには入ってないけど、eMMCにはUbuntu 24.04 TLSがプレインストールされていてシリアルコンソール経由でログインすることが出来るが、SATAポートがこのボードに存在しているので、SSDにインストールすることにする

イメージを取得

https://github.com/sifive/hifive-premier-p550-ubuntu/releases/tag/2024.11.00にUbuntuのイメージが置かれているので、これを入手する

ディスクに書き込む

まずxzで圧縮されているので、展開

xz -d ubuntu-24.04-preinstalled-server-riscv64.img.xz

SSDが/dev/sdaだとして、ddコマンドでディスクに書き込む

dd if=ubuntu-24.04-preinstalled-server-riscv64.img of=/dev/sda bs=1M

この状態でリブートするとSSDが(hd0)になるので、SSD経由でブートする。ただし、eMMCはこのイメージを書き込んであるっぽいので、GPTのUUIDが全部一緒になるので、好みにおおじてGPTを変えてupdate-grubかけたほうがよい

Unix Bench

------------------------------------------------------------------------
Benchmark Run: Sun Jan 12 2025 06:34:27 - 07:02:47
4 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       12927124.9 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     2641.1 MWIPS (9.9 s, 7 samples)
Execl Throughput                               1176.6 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        229490.7 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           72809.9 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        374429.0 KBps  (30.0 s, 2 samples)
Pipe Throughput                              475331.9 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  31965.9 lps   (10.0 s, 7 samples)
Process Creation                               2703.0 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   3510.5 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   1154.5 lpm   (60.0 s, 2 samples)
System Call Overhead                         590916.1 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   12927124.9   1107.7
Double-Precision Whetstone                       55.0       2641.1    480.2
Execl Throughput                                 43.0       1176.6    273.6
File Copy 1024 bufsize 2000 maxblocks          3960.0     229490.7    579.5
File Copy 256 bufsize 500 maxblocks            1655.0      72809.9    439.9
File Copy 4096 bufsize 8000 maxblocks          5800.0     374429.0    645.6
Pipe Throughput                               12440.0     475331.9    382.1
Pipe-based Context Switching                   4000.0      31965.9     79.9
Process Creation                                126.0       2703.0    214.5
Shell Scripts (1 concurrent)                     42.4       3510.5    828.0
Shell Scripts (8 concurrent)                      6.0       1154.5   1924.2
System Call Overhead                          15000.0     590916.1    393.9
                                                                   ========
System Benchmarks Index Score                                         463.6

------------------------------------------------------------------------
Benchmark Run: Sun Jan 12 2025 07:02:47 - 07:31:09
4 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables       51689178.8 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                    10560.7 MWIPS (9.9 s, 7 samples)
Execl Throughput                               4324.4 lps   (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        758792.3 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          282576.0 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       1383510.8 KBps  (30.0 s, 2 samples)
Pipe Throughput                             1893625.3 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 218013.6 lps   (10.0 s, 7 samples)
Process Creation                               9020.4 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   9097.3 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   1184.8 lpm   (60.1 s, 2 samples)
System Call Overhead                        2362850.1 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   51689178.8   4429.2
Double-Precision Whetstone                       55.0      10560.7   1920.1
Execl Throughput                                 43.0       4324.4   1005.7
File Copy 1024 bufsize 2000 maxblocks          3960.0     758792.3   1916.1
File Copy 256 bufsize 500 maxblocks            1655.0     282576.0   1707.4
File Copy 4096 bufsize 8000 maxblocks          5800.0    1383510.8   2385.4
Pipe Throughput                               12440.0    1893625.3   1522.2
Pipe-based Context Switching                   4000.0     218013.6    545.0
Process Creation                                126.0       9020.4    715.9
Shell Scripts (1 concurrent)                     42.4       9097.3   2145.6
Shell Scripts (8 concurrent)                      6.0       1184.8   1974.6
System Call Overhead                          15000.0    2362850.1   1575.2
                                                                   ========
System Benchmarks Index Score                                        1591.8

大体Unmatchedの2倍くらいの速度

2024年に買ったもの

買ったものを書いているけど、これ以外には、家 (賃貸) のトレイが壊れたため、結果として新しいトイレのユニットに入れ替わった (元のトイレは25年前のもの)。今どきトイレは水の使用量が少なくなっていたりするけど、そもそもシャワートイレにしないところが、大家...とは思ったが

Google Pixel 8a

これをメイン機にして、いままで使っていたPixel 6aをテスト機に格下げしました。前までの手頃値段感はなくなったけど継続して買っている。個人的にPixel買っている理由は、Androidのアップデートが長期的に行われそうなところ、aシリーズであれば手頃な値段に落ち着いていることと、万一画面が割れたとしても、iCrackedで当日持ち帰りの修理が可能なところ (Googleでの修理扱いになる) なだけで、これを満たしているのであればどれでもいいんだが

Panasonic 食器洗い乾燥機 SOLOTA NP-TML1

5月に購入。食洗機があると生活が変わるという記事を見たりするのだけど、ふと買ってしまった。確かに便利だし、寝る前に洗い忘れて、朝マグカップを洗うなんてことは日常だったので、生活はより楽にはなった。ただこの食洗機のレビューにいつも書いてあることだけど、これが受け入れられるかどうかで評価が変わる

• 洗浄、乾燥で合計2時間かかる
• 大きさが用途に合わないと、使い物にならない

ただ台数は売れないだろうから、ずっと同じものを5年以上売るんだろうね (Panasonicのロボット掃除機みたく)

象印 オーブンレンジ EVERINO ES-GW26

10月に購入。元々持っていたオーブンレンジ (三菱電機製) は20年以上使っていたしまったく壊れる気配がなかったのだが、新しいものが欲しくなって購入。今どきの電子レンジってこんなに機能豊富なんだなと改めて感動。スチームオーブンと迷ったけど、十分満足

デロンギ コーヒーグラインダー KG79J

12月に購入。コーヒー自体はドルチェグストを使っているのだけど、種類に飽きてきてコーヒー豆を買ってきたくなったのでミルを購入。価格も手頃だし、機能自体は挽く粗さを選べたり満足なのだが掃除が超面倒。メンテンス性が悪いという評判は見てたのだけど、これがね...

RISC-VにおけるCrypto命令 (Crypto Extension)

やっとこさVector Extensionも1.0になり、そろそろいろんなExtensionを実装したSoCも出てくるとは思うけど、年末の移動時間のなかでいろいろ現在のCrypto Extensionを勉強してた

Crypto ExtensioもScalar命令版とVector命令版の２つがあって、Scalar版は組み込みとか用途向けの、レジスタとかを増やしたくない実装用で、Vectorはその名の通りVectorレジスタを使ったもの。試しにAESのEncryptionを実装してみる

Scalar版

Scalar版は以下のようになる。

void
riscv64zkn_aes_encrypt_block_128(uint64_t* expandedKey,
                                 uint8_t *output,
                                 const uint8_t *input)
{
  uint64_t state0 = *((uint64_t *)input);
  uint64_t state1 = *((uint64_t *)(input + 8));

  // Add round key 0 to initial state
  state0 = state0 ^ *expandedKey++;
  state1 = state1 ^ *expandedKey++;

  for (int i = 1; i < 10; r++) {
    uint64_t c0 = __riscv_aes64esm(state0, state1);
    uint64_t c1 = __riscv_aes64esm(state1, state0);
    state0 = c0 ^ *expandedKey++;
    state1 = c1 ^ *expandedKey++;
  }

  // Final round
  uint64_t c0 = __riscv_aes64es(state0, state1);
  uint64_t c1 = __riscv_aes64es(state1, state0);
  state0 = c0 ^ *expandedKey++;
  state1 = c1 ^ *expandedKey;

  *((uint64_t *)output) = state0;
  *((uint64_t *)(output + 8)) = state1;
}

Vector版

Vector版。まだVector Crypto ExtensionのIntrinics命令はStableじゃないので、インラインアセンブラ使ってる。

static vuint32m4_t
vaesz_vs(vuint32m4_t rd, vuint32m4_t vs2)
{
  __asm__("vaesz.vs %0, %1" : "+vr"(rd) : "vr"(vs2));
  return rd;
}

static vuint32m4_t
vaesem_vs(vuint32m4_t rd, vuint32m4_t vs2)
{
  __asm__("vaesem.vs %0, %1" : "+vr"(rd) : "vr"(vs2));
  return rd;
}

static vuint32m4_t
vaesef_vs(vuint32m4_t rd, vuint32m4_t vs2)
{
  __asm__("vaesef.vs %0, %1" : "+vr"(rd) : "vr"(vs2));
  return rd;
}

SECStatus
riscv64zvkn_aes_encrypt_block_128(uint32_t* expandedKey,
                                  uint8_t *output,
                                  const uint8_t *input)
{
  size_t vl = __riscv_vsetvl_e32m4(4);
  vuint32m4_t state = __riscv_vle32_v_u32m4((const uint32_t *)input, vl);

  // Add round key 0 to initial state
  vuint32m4_t K = __riscv_vle32_v_u32m4(expandedKey, vl);
  expandedKey += 4;
  state = vaesz_vs(state, K);

  for (int i = 1; i < 10; r++) {
    K = __riscv_vle32_v_u32m4(expandedKey, vl);
    expandedKey += 4;
    state = vaesem_vs(state, K);
  }

  // Final round
  K = __riscv_vle32_v_u32m4(expandedKey, vl);
  state = vaesef_vs(state, K);
  __riscv_vse32_v_u32m4((uint32_t *)output, state, vl);
}

Conclusion

• RISC-Vの場合Load/Restoreをまとめないとvlenの長さを指定するvsetvliが大量に利用することになるので、速さに直結するかもということと、コンパイラ (gcc、LLVM) の最適化もまだまだっぽい
• 両方ともx86のAES-NIに似た感じなので、AES-NIの経験値があれば、難しくないかも

So-net 光 with フレッツS から別会社の光コラボ回線への転用が地雷すぎる

自分のオープンソースへのコントリビューションする際のメアドのドメインはずっとso-net.ne.jpなのだが (もちろん別にドメイン持ってるし、それを使ったメアドもある) 、いろいろ思うこともあり、自宅の回線をSo-netではない回線に変えることにした

そもそもフレッツ使っているのは2020年ころまでADSL使ってのもあって、NTTから工事手数料無料でフレッツ光に切り替えるキャンペーンを使ったからってのが一番の理由なのだが

当然のことながらPPoEだと遅いときがたまにあるので、IPoEオプションを使っているのだが、別の光コラボ回線に切り替えるにあたって、解約する必要があるようなので、先にSo-net側のIPv6オプションをWeb上で解約した (はずだった)

解約したのに関わらず、解約申込み中のままになっており、数日待てど一切ステータスが変化しない

おそらく月末処理にしているか、間違えて解約する人向けに数日待つ仕様にしているのだろうが、こっちとしては、光コラボ回線への切り替えの日付が決まっているので、即時解約されないと困る

そのため、サポートに問い合わせると、初めの担当者は「転用の日にコース変更とIPv6オプションの解約をWebからすれば問題ない」と回答してきたのだが、どうも転用という作業がどういうことがたぶんわかってないようだ

いろんな情報を集めると、転用元のIPoEが解約されていないと転用先でIPoEが使えないため、下手すると転用の契約自体がキャンセルされるなりして、両方つかえなくなることも起きるらしい

安全に行くなら切り替えの前の日にはIPoEが解約されていたほうがいい感じなので、もう一度サポートに問い合わせた

サポートに「いつ解約になるのかを教えて欲しい。転用が控えているのですぐ解約できないと困る」と伝えたところ、サポート経由だと即時解約が可能らしく、その担当者経由で即時解約してもらった

Webページでのオプション変更では解決できず、サポートにチャットをしないと (So-netは電話サポートは別契約が必要)、解決しないだなんて、地雷だよな

なお、Googleで検索した際に表示されるこれもウソ。こっちは1週間待ったけど、解約申込み中にままだった

2024/9/28追記

1日経って、転用当日 (というよりも転用先の工事予定時間すぎ) に接続を見てみたところ、転用先のIPoEでつながっておらず、従来のフレッツのままということが判明

以前説明してもらったようにIPoEが未だに使えているという状態 = 転用に失敗しているということで、しょうがなくSo-netにまたチャットサポートを投げてみたところ、「エラーが発生してて、解約処理ができてない」ということがやっとわかった

サポートの人に苦言するのは申し訳ないけれど、ちゃんとした社内の技術担当がフレッツ側にチケット投げて作業すればいいはずの話のようにしか聞こえないのに、サポートの人はうちではいつできるのかわからないの一点張りでこの問題の解決する道筋がでないので、積んだ状態。ホント困った。このせいで来月も料金発生するのかと思うと、So-netはISPとしてひどい有様になったんんだなぁと残念な気持ちになった。はぁ

あと別会社の光コラボ回線への転用は、その転用元にとってはユーザーが逃げるということでもあり、そういうところのサポートを対応したくないという気持ちはわかるのだが、出てくるサポートの人が不正確な情報をユーザーに説明するのはどうかと思う

最初の人は切り替わってからコース変更で問題ない (v6オプションのことは触れない) と言っていたり、切り替えにあたってFAQなりWebのセルフサポートで済むようにすれば、ユーザー側は無駄なコストをかけなくてすむし、サポートへの問い合わせというコストを払う必要もないわけだ

So-netはNuro光で良い話を聞かないけど、なるほどなーと思える対応でした。まだ終わってないけどな

Android 14 (Credential Manager) におけるパスキー対応が面倒すぎる

DroidKaigiにココらへんの話をしようと思って、CfP書いたけど落ちたので、自分用の覚書。

Firefox (GeckoView) AndroidでCredentail Managerの対応を入れたのが、GeckoViewとしてはバイナリサイズを大きくしたくないため、JetPackを一切使わずにCredential Manager経由でWebAuthn対応を行うコードをJavaでスクラッチで書いた。おそらくJavaでスクラッチで書いたのはChromeとGeckoViewだけだし、おそらくこの2つの製品以外でスクラッチ実装がされることは今後もないと思う。

しかもGeckoViewはWebブラウザエンジンなわけだから、いろんなWebサイトで実行可能な必要がある (= オリジンを正確に設定する必要がある)。この値を設定するのもおそらくBlinkとGeckoの2つの製品以外でほぼ存在しないであろう。なので、実装にあたって、実装者、すなわち自分しか被害者がいない事例がいろいろあることになるわけだ。自分はGoogleの人じゃないので、社内情報アクセスできないからね。

従来の実装方法

Google Mobile Service (GMS) にFIDO API (https://developers.google.com/android/reference/com/google/android/gms/fido/fido2/package-summary)が提供されていた。これを使うことでWebAuthnの実装が簡単にできるようになっている。またとあるバージョン以降であればパスキーをGoogle Password Managerに登録することが可能。これは古いAndroidでも動作する。

Credential Managerとは

Andorid 14から Credential Managerという仕組みが追加された。このCredential Managerはサービスとして実装されるもので、サードパーティに対して認証要求を移譲できる。ただこのサービスには3つのメソッドしか存在しなくて、登録・認証・削除があるだけだ。幅広い認証情報を扱えるようにAndroidチームの人は考えためであろうけど、この3つのメソッドには引数がBundleしか実質存在しない。すなわちアプリケーションはBundleに各々好き勝手に情報を入れると、OSにインストールされたCredential Managerサービスたちが、登録成功とか返すようになっている。なおBundleに何入れるべきか？なんてものも存在しない

Credential Managerを使ったパスキー実装

パスキーを実装するには、このBundleになにかを入れる必要があるのだが、そんな情報はdeveloper.android.comには一切存在しない。GeckoViewでは一通りのBundle定義をしているが、これらはJetPackのコードとChromeのコードから持ってきている。オープンソースだったからいいようなものだが、これらの謎定義はGoogle社内でしか共有されていないような感じなので、まぁなんというかEU頑張れって感じ。ここには入れていないが、Google Password Managerだけ無視するっぽく見える定義もあったりする

実際問題、JetPackを使った場合はここらのBundle問題はJetPack側で吸収されるので、そこらは問題になりえないのだが、問題はリクエスト用のJSONは自分たちで組み立てないといけないってことだ。 なので、WebAuthnの仕様をちゃんと理解しないといけない。それをアプリケーション開発者に求めるのはどうかと思う。なおレスポンスもJSONむき出しで渡される。検証とかしたい場合は、むき出しで渡されたJSONデータを展開して検証しないといけない。

以前のGMSのFIDO APIではJSONむき出しな仕組みにはなっていない。引数はBuilderが用意されているので、必要なパラメータを設定するだけで行える。ちなみにGeckoViewでいうと、これがCredential Manager版でここがFIDO API版なのだが、Credential Manager版は自分でJSONを組み立てるのに対して、FIDO API版はBuilderで引数を組み立てる。

あと、検証時 (Assertion) には落とし穴が実は存在してて、クライアントサイドで検証する際には、レスポンスのJSONの ClientDataJsonハッシュを使って検証を行うわけだけど、レスポンス内のこの値は正しくない可能性があって、リクエスト時にBundleに入れたClientDataJsonのハッシュが正しい値だったりする (これは2日悩んだ)

現在のCredential Managerがどの認証方法を対応しているか?

そんな方法はない。

とりあえず試してみて、サービスがTYPE_NO_CREATE_OPTIONSを返してくれれば、たぶん対応していないということがわかる。なお、1Passwordは最初のリクエストでサービス自体がクラッシュしたりするので正しく動かなかったりする。GeckoViewだと登録時はResident KeyがRequiredのときだけCrednetial Managerを使うようにしているが、Preferredの場合にどうするかは決めかねている。

また、認証を行おうとしてるクレデンシャルがGoogle Password Managerで認証可能かどうか？みたいなのはFIDO API経由で確認は可能なので、認証可能であればGMSのFIDO2 APIを使って、認証できない場合は Credential Managerを使ういうこともできる。GeckoViewもChromeもそのようなコードを入れている。

結論

GMSのFIDO APIがCredential Manager対応すれば、みんなハッピーだったのでは?やっとサードパーティ製品で対応が増えてきたところだしさ