2018年12月27日

Go のライトバリアに関するバグを修正した話

はてなブックマークに登録

Goのランタイムのバグを踏んで解決しました。解決までの過程を記事にします。

同じようなランタイムのバグを踏んで、小さい再現コードを作れない場合の参考にしてください。

自分のプログラムを疑う

あるSlackチャンネルで Go で書かれたサーバーのクラッシュが話題になっているのを見つけました。その時に共有してもらったトレースバックです。

runtime: pointer 0xc007b8af97 to unused region of span span.base()=0xc004000000 span.limit=0xc004002000 span.state=1
fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?)
runtime stack:
runtime.throw(0xc046ca, 0x3e)
        /usr/local/Cellar/go/1.11.2/libexec/src/runtime/panic.go:608 +0x72 fp=0xc0001dff00 sp=0xc0001dfed0 pc=0x42bf02
runtime.findObject(0xc007b8af97, 0x0, 0x0, 0xc005eb4780, 0x7f3d1915b7b8, 0x5)
        /usr/local/Cellar/go/1.11.2/libexec/src/runtime/mbitmap.go:399 +0x3b6 fp=0xc0001dff50 sp=0xc0001dff00 pc=0x413bf6
runtime.wbBufFlush1(0xc000047900)

(長いバージョン)

エラーメッセージに "incorrect use of unsafe or cgo?" って言われてるので、まずはそれを疑います。

cgoは使っていませんでした。 unsafe は使わないようにビルドするのは大変なので、コードをチェックアウトして怪しいところを探します。 プロジェクトのコードには見当たりません。vendoringしているコードにはたくさんありますが、このプログラムで実際に利用されてそうな部分で怪しいものはありませんでした。

また、 race はすでに疑っていて、 -race オプション付きで見つけたレースコンディションを全て潰したあとだったようです。

これでランタイムバグの可能性が高くなってきました。

修正済みバグの可能性と、最近のリグレッションの可能性を調べるため、Go 1.11.4 と Go 1.10.5 で試してもらいました。 1.11.4 ですぐに再現し、 1.10.5 では再現しなかったそうです。 もちろん再現確率が違うだけの可能性も残ってるので、リグレッションだと確定したわけではありません。

Goのデバッグ機能を利用して原因特定を試みる

時系列的には上と同時になりますが、Goが標準で持っているデバッグ機能をつかって原因特定できないか試行錯誤をします。

まず大事なのは、スタックトレースとコードを読みクラッシュした状況を理解することです。

今回のケースは、ライトバリアの実装の中で（性能のために）一旦バッファリングしていたポインタを処理する前に有効な（ヒープ内を指している）ポインタかどうかチェックしている箇所で、無効なポインタを見つけたというものです。

悪いポインタがバッファの中から見つかっているために、そのポインタがどの変数に書かれていたのかとか、どのコードによって書かれたのかがわかりません。そこで試してもらったのが、 GODEBUG 環境変数のうち invalidptr=0 と GODEBUG=gcstoptheworld=1 です。

invalidptr=0 を使うと、このポインタのチェックがなくなります。それでクラッシュしなくなれば、問題解決に時間がかかったときのワークアラウンドになります。クラッシュすれば、今度はその悪いポインタが入っている変数を特定するヒントが得られる可能性が高いです。

gcstoptheworld=1 はコンカレントGC自体を無効にするもので、ライトバリアが使われなくなるので同じく悪いポインタを利用している箇所の近くでクラッシュすることが期待できます。

結果として、どちらのオプションを使ってもクラッシュしなくなりました。ここまでの状況を整理した上で、一旦バグ報告しておきました。

https://github.com/golang/go/issues/29362

ローカルでの再現できるようにする

そろそろ手詰まり感が出てきました。腰を落ち着けて、自分で自由に使える再現環境を作ります。

docker-compose を使った開発環境構築手順を教えてもらい、現象を再現できるようになるまで試験環境との差異を調べて減らしていきます。ログの量を同じにしたところで、１日に数回クラッシュをさせられるようになりました。

反省点として、これは手詰まりになる前にさっさとやっておくべきでした。

print & throw デバッグ

runtime.wbBufFlush1 はライトバリア・バッファの中のポインタを処理する関数なので、ライトバリア・バッファにポインタを書き込む場所を探します。 runtime/mwbbuf.go はたった311行の小さいコードなので、すぐに (*wbBuf).putFast() という関数が見つかりました。ここに、 fatal error の原因になっているチェックと throw を仕込んでみます。

runtime: bad pinter: 0xc007435e93
fatal error: XXXXXX

runtime stack:
runtime.throw(0xbeaeb3, 0x6)
    /home/ubuntu/local/go/src/runtime/panic.go:608 +0x72
runtime.(*wbBuf).putFast(0xc00003b290, 0xc007435e93, 0xc007435e93, 0x7f4b766b6d88)
    /home/ubuntu/local/go/src/runtime/mwbbuf.go:143 +0x1f8
runtime.bulkBarrierBitmap(0xc0038a6fd8, 0xc0038a6fd8, 0x8, 0x0, 0xc19258)
    /home/ubuntu/local/go/src/runtime/mbitmap.go:682 +0x12d
runtime.newproc1(0xc194f0, 0xc0002c8708, 0x8, 0xc00222e780, 0x7f1edd)
    /home/ubuntu/local/go/src/runtime/proc.go:3373 +0x441
runtime.newproc.func1()
    /home/ubuntu/local/go/src/runtime/proc.go:3309 +0x4f
runtime.systemstack(0x0)
    /home/ubuntu/local/go/src/runtime/asm_amd64.s:351 +0x66
runtime.mstart()
    /home/ubuntu/local/go/src/runtime/proc.go:1229

goroutine 66219 [running]:
runtime.systemstack_switch()
    /home/ubuntu/local/go/src/runtime/asm_amd64.s:311 fp=0xc0002c86b0 sp=0xc0002c86a8 pc=0x45bb70
runtime.newproc(0xc000000008, 0xc194f0)
    /home/ubuntu/local/go/src/runtime/proc.go:3308 +0x6e fp=0xc0002c86f8 sp=0xc0002c86b0 pc=0x43750e
XXX/game/connection.Keep(0x7435e93)

これで、プロジェクトの connection.Keep 関数から runtime.newproc が呼び出され、そこから bad pointer がライトバリア・バッファに書き込まれていることがわかります。 また、よくみてみると、 bad pointer の壊れている下位バイトが、 Keep 関数の引数と完全に一致していますね。

throw を仕込む前の完全なスタックダンプ（クラッシュしたgoroutine以外の全部のgoroutineが、引数付きで書き出される）を見直してみると、さらに面白い事がわかりました。

runtime: pointer 0xc00659e432 to unused region of span span.base()=0xc004000000 span.limit=0xc004001f80 span.state=1
fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?)

runtime stack:
runtime.throw(0xc0f417, 0x3e)
    /home/ubuntu/local/go/src/runtime/panic.go:608 +0x72 fp=0x7ff10e99fd98 sp=0x7ff10e99fd68 pc=0x42dec2
runtime.findObject(0xc00659e432, 0x0, 0x0, 0xc004ab0180, 0x7ff10d5f3e70, 0x1)

...

goroutine 29115 [runnable]:
XXX/game/connection.Keep.func1(0xc00659e432)
    XXX/game/connection/connection.go:22 fp=0xc0044a97d8 sp=0xc0044a97d0 pc=0x7f1ff0
runtime.goexit()
    /home/ubuntu/local/go/src/runtime/asm_amd64.s:1333 +0x1 fp=0xc0044a97e0 sp=0xc0044a97d8 pc=0x45dc51
created by XXX/game/connection.Keep
    XXX/game/connection/connection.go:22 +0x3d

bad pointer のアドレスと Keep.func1 の引数が完全に一致しています。 Keep 関数のコードを見てみましょう。

func Keep(playerID int32) {
    go func() { // この無名関数が Keep.func1
        err := updateAliveTime(playerID)
        if err != nil {
            logger.Errorf("Failed to keep connection. err=[%v]", err)
        }
    }()
}

なんとなく、スタックに残っていたポインタ (64bit) の下位 32bit を int32 の変数で上書きして bad pointer が生成されてそうなのがわかります。とはいえ、 int32 の変数がある場所をポインタとして扱っているのはコンパイラかランタイムのどちらかのバグのはずです。

ここまで追い詰めたら、この部分に詳しい人ならすぐに解析できるでしょう。一旦ここまでをまとめて報告しておきます。

コードリーディング＆バグ修正

ここまでくれば待っていても誰かが直してくれると思いますが、クリスマスを過ぎてしまって欧米の開発者は holiday に入ってしまっている時期だし、何より楽しいので、 newproc ... putFast までのコードを読んでいきます。

newproc1 が新しい goroutine のための G オブジェクトを用意し、親 goroutine のスタックから新しい goroutine のスタックに最初の関数の引数をコピーした上で、ライトバリアが有効なら bulkBarrierBitmap を呼び出しています。 bulkBarrierBitmap は渡されたビットマップを使ってメモリ中のポインタをライトバリア・バッファに putFast していきます。

本来なら、 Keep.func1 の引数は（クロージャ変数の） playerID int32 一つだけなので、 putFast が呼び出されるはずがありません。 bulkBarrierBitmap の呼び出しの前に print を仕込んでビットマップの内容を表示してみます。すると、 Keep.func1 は引数の長さが１ワードなのに、引数のビットマップは長さが 0 になっていました。

このスタック用のビットマップに関連するコードを読んでみると、該当するスタックの中にポインタが１つもない時は空のビットマップが使われるようでした。なので、 bulkBarrierBitmap はオーバーランして別のデータ（多分実行バイナリ上で隣に配置された別のビットマップ）を参照してしまい、int32 の変数が入っている箇所を間違えて処理しているようです。

bulkBarrierBitmap を呼び出す前にビットマップの長さが 0 でないかテストする事で問題が解消することを確認し、報告しました。

https://github.com/golang/go/issues/29362#issuecomment-449964832

パッチ送信＆再現コード作成

runtime の他の場所で似たことをしている場所を探し、自分の書いた if 文が他の場所と(> 0 か != 0 かのスタイルまで)同一であることを確認した上で、 Gerrit にパッチを送信します。

https://go-review.googlesource.com/c/go/+/155779

また、レビューアーが確認できるように、クラッシュの小さい再現コードも作ってみます。ライトバリアが常に有効になるように、ヒープ上にポインタ変数をたくさん作った上で runtime.GC() をループで呼び出します。また、スタック上に残っていたゴミポインタと int32 の値の合体で偶然 bad pointer を作るのでなく、意図的に bad pointer を作った上で、それを整数型の引数として関数を呼び出します。

残る再現条件は、長さ0のビットマップをオーバーランしたときにたまたまその場所のビットが1になっていることなのですが、この条件は Go プログラムで意図的に作り出すことが難しい。確率を上げるためにとりあえず引数を１つではなく４つにしてみたら、あっさり再現できました。

https://gist.github.com/methane/b61dcfb504d54de5bced1c6e3209a91d

理想的にはこの再現コードをリグレッション・テストに落とし込むなり、 newproc1 に対するユニットテストが書ければ完璧なのですが、この辺は Go のプログラムから直接呼び出されるのではなく Go コンパイラが呼び出しコードを生成する部分でテストが難しいので今後レビューアーと相談します。

@methane
songofacandy at 17:09
｜この記事のURL│Comments(0)│golang 
2018年12月07日

Google Assistant Service プログラミング事始め

はてなブックマークに登録

前回の記事では Google Assistant Library ベースのプログラミングを通じて Google アシスタントの各機能を取り回す試みを行いました。今回はもうひとつの Google Assistant SDK である Google Assistant Service に目を向けてみます。

  • 当ブログ記事「Google Assistant Library プログラミングを楽しむ 」より
    Google LLC は Google Assistant SDK for devices として「Google Assistant Library」「Google Assistant Service」の二種類のセットを提供しています。前者は高水準で稼働環境は狭め、後者は低水準で広範な稼働環境に対応しており、この周到な構成に Google の本気度が窺えます。現時点では一日あたりのリクエスト数に制限はあるものの個人でも無償で利用できることが大きな魅力です。

Google Assistant Service と稼働環境

前回も引用した Google Assistant Library と Google Assistant Service の比較表を再掲します。（2018年12月時点の公式記事より）

Google Assistant Service の最大の特長は、このように gRPC 対応のプラットフォーム＋対応言語環境全般で利用可能であることです。現時点では Google Assistant Library ほどには多機能ではないものの、稼働環境が広く Windows PC や Mac はもとより小振りで消費電力が小さく IoT フロントエンドとして有用な Raspberry Pi Zero / Zero W 系ボードも Google アシスタントクライアントとして利用できることに関心を誘われます。

Google Assistant Service と Google Assistant Library の機能面での違いは SDK 全体のリリースノートを追うことで手早く俯瞰できます。

両者の機能差は今後変化する可能性がありますが、個人的には 2018年12月時点で Google Assistant Service 側にはない要素のうち実用面とのかねあいにおいて以下の三点に留意しています。

  1. Google Assistant Library とは異なりウェイクワードの待機・検知に対応していない
  2. ニュースの読み上げや Google Podcasts に未対応
  3. アラームに未対応 （リマインダは設定可能）

なお、上記 1. は外部の Hotword Detector との連携（後述）によりある程度補うことが可能です。

※余談ながら、Google Home デバイス実機とは異なり今のところ Google Assistant SDK ベースのプログラムの所作に google-home-notifier を絡ませることはできません。たしかに 8009 番ポートを使ったキャスト機構にはハードウェア側要件としての印象が強いものの、google-home-notifier を あち こち で利用しているファンとしてはちょっと残念です。

pushtotalk.py プログラムのこと

Google Assistant Service をセットアップ後の googlesamples/assistant/grpc/ フォルダには「pushtotalk.py」プログラムが配置されます。 このプログラムは名前の示すように Google Assistant Library に含まれる「hotword.py」とは異なり、ウェイクワード（ホットワード）の音声ではなく 'Press Enter to send a new request...' の CUI メッセージを添えた click.pause() API で物理的なトリガーを待って Google アシスタントとの対話を開始する内容で実装されています。
セットアップずみの SDK ディレクトリ下での pushtotalk.py の実行方法は以下の要領です。引数で指定したプロジェクト ID とモデル ID はホスト側へ記憶され、変更の必要がなければ次回以降は省略可能です。

$ pwd
/home/t/wk/GoogleAssistant

$ ls
env

$ source env/bin/activate

(env) $ googlesamples-assistant-pushtotalk --project-id [設定ずみのプロジェクトID] --device-model-id [設定すみのモデルID]

pushtotalk.py を手元の複数の環境で実行した様子の動画を以下に示します。

Windows
 Mac
Linux （32bit）
 Raspberry Pi 3 Model B+
Raspberry Pi Zero W

上の動画のRaspberry Pi 3 Model B+ / Zero W には手持ちの以下の以下のマイクとスピーカーを写真の要領で接続しています。

今回は、前回の hotword.py と対照的なこの pushtotalk.py を試作の下敷きとします。

Hotword Detector について

前掲の Google Assistant Service 側未対応の機能のうち、実用上の影響がもっとも大きいのはウェイクワードの待機・検知ができないことでしょう。Google Assistant Library プログラムにおいては Google Home デバイスと同様にハンズフリーでアシスタントとの応酬が可能であることを考えあわせると淋しく感じられますが、この点は外部の Hotword Detection ソフトウェアを併用することで補うことができます。

ただし、外部の Hotword Detector との連携は Google アシスタントネイティブでのウェイクワードサポートではなく、あくまでも Assistant API を呼び出すためのトリガーを外側に用意する手立てに他ならないため以下の注意が必要です。

  • ウェイクワード設定の柔軟性や認識精度はすべて Detector 側の要件である
  • Google アシスタントの発話中にウェイクワードで介入することはできない

こういった事情を理解した上で Hotword Detector を併用すれば、間口の広い Google Assistant Service を様々な環境でより便利に利用することができるでしょう。

Porcupine と Snowboy

現時点でのスマートスピーカー向きの代表的な Hotword Detector として、Picovoice （カナダ系）による Porcupine と、 KITT.AI （中国系） による Snowboy が挙げられます。後者はすでに随所で取り上げられていますね。どちらも機械学習に基づく精度の高さ・低負荷・マルチプラットフォーム対応・カスタマイズの柔軟性をアピールポイントとしており、後発の Picovoice は両者の比較記事を公開しています。

手元ではどちらも使い始めてまだ日が浅いのですが、今のところウェイクワードを認識する能力そのものに際立った性能差は感じておらず負荷の度合いについては未検証です。今の時点で把握している両者の一長一短を挙げてみます。

対応プラットフォームの広さ： Porcupine ◎

  • Porcupine
    • Raspberry Pi/ Android/ iOS/ watchOS/ Linux/ Mac/ Windows/ web browsers
  • Snowboy
    • Raspberry Pi/ 64bit Mac OS X/ 64bit Ubuntu 14.04/ iOS/ Android/ ARM64 (aarch64, Ubuntu 16.04)

カスタムウェイクワードへの対応： Snowboy ◎

  • Snowboy
    • 任意のカスタムウェイクワードの作成・使用が可能
    • 日本語を含む主要 15か国語 or "Other" から言語を指定可能
    • 肉声でのモデル作成に対応 〜 モデルはサーバへ保存され別話者分を含め追加学習が可能
    • 操作性のよいブラウザ I/F が提供されている
      （クリックで大きく表示）
  • Porcupine
    • モデル作成には専用の CUI ツール「Porcupine Optimizer」を使用する。同ツールのソースコードは非公開で Windows/ Mac/ Linux 向けバイナリが配布されている
    • ウェイクワードのバリエーションはライブラリに同梱の英単語辞書に含まれる語彙の範囲に限定される。複数単語の組み合わせは可。モデルファイルの作成方法は以下の要領
      $ pwd
      /home/t/wk/Porcupine

      $ tools/optimizer/linux/i386/pv_porcupine_optimizer -r resources/ -p linux -o . -w "OK google"
    • 特定の話者の肉声に基づくモデリング・学習を行うことはできない
    • モデルファイルはプラットフォームごとに独立しており（バンドル分も同様）、Windows/ Mac/ Linux 用以外のモデルファイルの作成には商用ライセンスが必要
    • 作成したモデルファイルには 90日間の使用期限が伴う。再作成に制限はない

手元では今のところ PC では Porcupine、Raspberry Pi では Snowboy の要領で使い分けています。下の動画はそれぞれの動作の様子です。

※ ふたつの動画でのウェイクワード検知時・対話終了時の応答音はいずれも Snowboy の resource/ ディレクトリ下の wave ファイルによるものです。これらが耳に馴染んだため Porcupine との連携においても同じ要領で使用しています

  • 32bit Linux 環境での Porcupine - pushtotalk.py 連携
  • Raspberry Pi Zero W での Snowboy - pushtotalk.py 連携

試作

前回記事での hotword.py （Google Assistant Library） ベースの試作に続き、今回は Google Assistant Service の pushtotalk.py を下敷きにプログラムを作成します。作業上の便宜から開発は PC で行いましたが、Google Assistant Service ベースなので指先に乗るサイズの Raspberry Pi Zero W ボードをはじめ広範な環境で実行可能であることに夢が広がります。オールインワンのダンボールキットも製品化されていますね。

今回はシンプルな切り口として前回の Google Assistant Library 版の各プログラムと同じ動きをするものを作ってみることにしました。Google Assistant Serivice プログラミングは奥が深くまだまだ習作の段階ではありますが、事始めとして取り組んだ内容を以下に掲載します。

1. 指定テキストに基づく音声合成と読み上げ

テーマ： Google アシスタントの音声合成機能を単体で利用する。いわゆる Text to Speech。

［前回 Google Assistant Libray 版試作へのリンク］

内容

  • プログラムを起動するとテキスト連続入力モードへ
  • エンターキー区切りで入力した任意のテキストがそのままアシスタントに読み上げられる
  • ウェイクワードは使用しない

デモ： 動画 27秒
  

（前回分）
  

考えたことなど

  • 前回と同様、まず TTS を試したいと考えた
  • ここでのポイントは、「音声データではなく任意のテキストで Assistant へ指示を渡す」ことにある。だが、Google Assistant Library に存在する send_text_query API と同等の機能を持つものが Google Assistant Service には見当たらず、現時点で Google Assistant Service プログラミングに関する情報はネットにも乏しい
  • ヒントを探してまず pushtotalk.py をあらためて読む。このコードでの指示と応答の応酬は事前に用意した対話用ストリーム上での start_recording() 〜 stop_recording() を経て start_playback() 〜 stop_playback() を呼び出す内容で巧みなく実装されており、Google Assistant Service においては音声データ以外の方法で Assistant とのやりとりが不可である可能性も頭をよぎった
  • 手を動かすうちに SDK ディレクトリ配下の「googlesamples/assistant/grpc/textinput.py」プログラムの存在に気づいた。コードへのリンクとこのプログラムの実行例を示す
    • textinput.py - github.com/googlesamples 
      (env)t@PC-533:~/wk/GoogleAssistant$ ./textinput.sh 
INFO:root:Connecting to embeddedassistant.googleapis.com
: こんにちは
<you> こんにちは
<@assistant> こんにちは、TAnabeさん 
どうしましたか？
: 今何時？
<you> 今何時？
<@assistant> 時刻は、17:25です。
: 今晩、雨降る？
<you> 今晩、雨降る？
<@assistant> 夜は、雨の心配はないでしょう
今夜の山口は雨ではないでしょう。 気温10度、晴れるでしょう。
---
（weather.com でもっと見る）
:
  • このように textinput.py は音声を一切使わずテキストの入出力のみで Assistant とやりとりを行う内容のシンプルな内容であり、Assistant への指示に音声ではなくテキストを指定可能であることをまっすぐ示している。それを実現するためには google.assistant.embedded.v1alpha2 の AssistConfig クラスの text_query メンバ（"The text input to be sent to the Assistant. This can be populated from a text interface if audio input is not available.") を利用すればよいことを以下のコードで知った
    • textinput.py#L83-L100 
      083|        def iter_assist_requests():
084|            config = embedded_assistant_pb2.AssistConfig(
085|                audio_out_config=embedded_assistant_pb2.AudioOutConfig(
086|                    encoding='LINEAR16',
087|                    sample_rate_hertz=16000,
088|                    volume_percentage=0,
089|                ),
090|                dialog_state_in=embedded_assistant_pb2.DialogStateIn(
091|                    language_code=self.language_code,
092|                    conversation_state=self.conversation_state,
093|                    is_new_conversation=self.is_new_conversation,
094|                ),
095|                device_config=embedded_assistant_pb2.DeviceConfig(
096|                    device_id=self.device_id,
097|                    device_model_id=self.device_model_id,
098|                ),
099|                text_query=text_query,
100|            )
  • では、これに対する Assistant からの応答をテキストではなく音声データで受け取ることは可能か？ textinput.py でのレスポンス処理箇所は以下の内容
    • textinput.py#L109-L121 
      109|        text_response = None
110|        html_response = None
111|        for resp in self.assistant.Assist(iter_assist_requests(),
112|                                          self.deadline):
113|            assistant_helpers.log_assist_response_without_audio(resp)
114|            if resp.screen_out.data:
115|                html_response = resp.screen_out.data
116|            if resp.dialog_state_out.conversation_state:
117|                conversation_state = resp.dialog_state_out.conversation_state
118|                self.conversation_state = conversation_state
119|            if resp.dialog_state_out.supplemental_display_text:
120|                text_response = resp.dialog_state_out.supplemental_display_text
121|        return text_response, html_response
  • ここでふたたび pushtotalk.py のコードを追い、上と同じ self.assistant.Assist() ループ中の次の記述に注目した
    • pushtotalk.py#L149-L153 
      149|            if len(resp.audio_out.audio_data) > 0:
150|                if not self.conversation_stream.playing:
151|                    self.conversation_stream.stop_recording()
152|                    self.conversation_stream.start_playback()
153|                    logging.info('Playing assistant response.')
  • textinput.py での self.assistant.Assist() レスポンスのループにおいては audio 要素にまったく触れていないが、あるいはテキストベースで指示を受けた場合の応答においても resp.audio_out.audio_data がセットされるのではないかと根拠なく想像。とりあえずループ内に print(len(resp.audio_out.audio_data)) 文を挟んで実行してみた。以下はその画面表示結果 
    : 今何時？
<you> 今何時？
0
1600
1600
（引用中略）
1600
1600
244
<@assistant> 時刻は、18:43です。
  • どうやら正解らしい。実際に resp.audio_out.audio_data を順次ファイルへ出力し、それを Audacity に Raw データとして取り込んだところ 16ビット 16000 Hz のモノラル PCM データであることが確認された。つまり、textinput.py では音声でのレスポンスが不要であるため参照されていないものの、入力データが音声であってもテキストであっても Assistant からは常に音声形式とテキスト形式の応答が返されるらしい
       
          （mp3 形式へ変換したもの）
  • それなら話は早い。ここでは音声ストリームデータの再生のみができれば良い。コードを追い、pushtotalk.py での対話に使用されている conversation_stream の source, sink の両メンバが googlesamples.assistant.grpc.audio_helpers.py の SoundDeviceStream のインスタンスであることを確認し、同クラス内部の _audio_stream の実体が sounddevice パッケージの RawStream であることを知り 前掲のコードに次の要領で再生処理を加えた 
    import sounddevice as sd

           :
        text_response = None
        html_response = None
        s = sd.RawStream(
            samplerate=audio_helpers.DEFAULT_AUDIO_SAMPLE_RATE, 
            dtype='int16', 
            channels=1,
            blocksize=audio_helpers.DEFAULT_AUDIO_DEVICE_BLOCK_SIZE)
        for resp in self.assistant.Assist(iter_assist_requests(),
                                          self.deadline):
            assistant_helpers.log_assist_response_without_audio(resp)
            s.write(resp.audio_out.audio_data)
            s.start()
            if resp.screen_out.data:
                html_response = resp.screen_out.data
            if resp.dialog_state_out.conversation_state:
                conversation_state = resp.dialog_state_out.conversation_state
                self.conversation_state = conversation_state
            if resp.dialog_state_out.supplemental_display_text:
                text_response = resp.dialog_state_out.supplemental_display_text
        return text_response, html_response
           :
  • 以上の経緯を経て Google Assistant Service ベースでの TTS プログラムが形になった。前回の Google Assistant Library 版と同じく IFTTT 上に用意した「オウム返しアプレット」を併用

ソースコード

2. 利用者の発話内容をテキストへ変換

テーマ： Google アシスタントの音声認識機能を単体で利用する。いわゆる Speech to Text。

［前回 Google Assistant Libray 版試作へのリンク］

内容

  • ウェイクワードの検知に Porcupine を利用。対象ワードは「picovoice」
  • 「エディタを起動」でテキストエディタを起動
  • 発話内容のテキストを連続してエディタへ書き出す
  • この手のことはひと昔以上前から商用化されていたが、認識精度が段違いに向上しておりすでに口述筆記や印刷物のテキスト書き起こしの下書きにも使える水準と言ってよいだろう
  • いろいろ肉付けすれば PC 上で Google アシスタントを Cortana, Siri 風のツールとして利用できるかも

デモ： 動画 41秒
  

（前回分）
  

考えたことなど

  • 利用者の発話内容をアシスタント側が認識した結果のテキストを取得したい
  • そのためには以下の手順を踏めばよいことを pushtotalk のコードで知った
    • pushtotalk.py#L138-L148 
      138|        for resp in self.assistant.Assist(iter_log_assist_requests(),
139|                                          self.deadline):
140|            assistant_helpers.log_assist_response_without_audio(resp)
141|            if resp.event_type == END_OF_UTTERANCE:
142|                logging.info('End of audio request detected.')
143|                logging.info('Stopping recording.')
144|                self.conversation_stream.stop_recording()
145|            if resp.speech_results:
146|                logging.info('Transcript of user request: "%s".',
147|                             ' '.join(r.transcript
148|                                      for r in resp.speech_results))

ソースコード

  • PicovoiceWithGoogleAssitantService_input.py - github.com/mkttanabe
    • Porcupine をインストールしたディレクトリ下へ配置して実行のこと
    • Porcupine/resource ディレクトリ下に前掲の ding.wav, dong.wav が必要
    • デモ動画ではパラメータに "--keyword_file_paths resources/keyword_files/picovoice_linux.ppn" を指定

3. 利用者の発話内容を他言語へ連続翻訳

テーマ： Google アシスタントの 音声認識 / 文意解釈 / 言語翻訳 / 応答文生成 / 音声合成 の各機能を利用する

［前回 Google Assistant Libray 版試作へのリンク］

内容

  • ウェイクワードの検知に Porcupine を利用。対象ワードは「picovoice」
  • 今回の Google Assistant Service 版では口頭指示により翻訳先言語を切り替える機能を追加した
  • 利用者が日本語の文章を発話するとアシスタントがその翻訳文を読み上げる
  • 一文ごとにウェイクワード等の指示は不要
  • 操作に手がかからないのでオフィスや店舗等の多言語環境用に翻訳専用端末として仕立てられるかも

デモ： 動画 2分30秒
  

（前回分）
  

ソースコード

  • PicovoiceWithGoogleAssitantService_translate.py - github.com/mkttanabe
    • Porcupine をインストールしたディレクトリ下へ配置して実行のこと
    • Porcupine/resource ディレクトリ下に前掲の ding.wav, dong.wav が必要
    • デモ動画ではパラメータに "--keyword_file_paths resources/keyword_files/picovoice_linux.ppn" を指定

4. 利用者の発話内容を復唱

テーマ： Google アシスタントの音声認識 / 音声合成機能を利用する

［前回 Google Assistant Libray 版試作へのリンク］

内容

  • ウェイクワードの検知に Porcupine を利用。対象ワードは「picovoice」
  • 利用者が発話したフレーズをオウム返しする
  • 前掲の「指定テキストに基づく音声合成と読み上げ」の音声入力版。いわば翻訳を伴わない Speech to Speech

デモ： 動画 39秒
  

（前回分）
  

ソースコード

  • PicovoiceWithGoogleAssitantService_echo.py - github.com/mkttanabe
    • Porcupine をインストールしたディレクトリ下へ配置して実行のこと
    • Porcupine/resource ディレクトリ下に前掲の ding.wav, dong.wav が必要
    • デモ動画ではパラメータに "--keyword_file_paths resources/keyword_files/picovoice_linux.ppn" を指定

しりとり

テーマ： Google アシスタントの音声認識 / 音声合成機能を利用する

［前回 Google Assistant Libray 版試作へのリンク］

内容

  • ウェイクワードの検知に Porcupine を利用。対象ワードは「picovoice」
  • 日本語の単語でアシスタントとしりとりを行う
  • しりとり向きの適当な単語辞書を使用
  • 日本語形態素解析に Janome ライブラリを利用

デモ： 動画 60秒
  

（前回分）
  

現時点ではプログラミングを行うための実践的な情報をあまり目にすることのない Google Assistant Library と Google Assistant Service を題材に手元で行った試みを二度に分けて紹介しました。幼児の年齢を迎えたばかりの Google アシスタントはこれからこれらの SDK とともに成長を重ねて行くことでしょう。未来へ向かう道すがらの愉しみがまたひとつ増えた思いです。

(tanabe)
klab_gijutsu2 at 09:23
｜この記事のURL│Comments(0)│スマートスピーカ | Google Assistant
2018年11月30日

Google Assistant Library プログラミングを楽しむ

はてなブックマークに登録

Google LLC は Google Assistant SDK for devices として 「Google Assistant Library」「Google Assistant Service」 の二種類のセットを提供しています。前者は高水準で稼働環境は狭め、後者は低水準で広範な稼働環境に対応しており、この周到な構成に Google の本気度が窺えます。現時点では一日あたりのリクエスト数に制限はあるものの個人でも無償で利用できることが大きな魅力です。

Google Home デバイスやスマートフォンアプリを通じて Google アシスタントの存在感はどんどん大きくなっています。その一方で現時点では Google Assistant SDK プログラミングのための実践的な情報を国内外を通じてあまり見かけないことが残念に思われました。ネットの奥深くに息づいている Google アシスタント陣営の一連の機能を本 SDK ごしに柔軟に呼び出すことができればこの強力で魅力的なサービスをさらに活用できるのではないでしょうか。

  • 音声認識
  • 文意の解釈
  • 応答文の生成
  • 音声合成
  • 言語翻訳

そんなわけで手元ではここしばらく Google Assistant SDK に向き合っています。今回はまず Google Assistant Library ベースでこれまでに行った調査と実験の内容を紹介します。

Google Assistant Library と稼働環境

前掲の表にも記載のあるように、今のところ Google Assistant Library の稼働環境は Python を利用可能な linux-armv7l または linux-x86_64 なプラットフォームに絞られます。周辺機器としてマイクとスピーカが必須。セットアップは下記ページからの説明にそって行えば問題ないでしょう。導入手順の詳細は随所で紹介されているためここでは省略します。

手元では作業用に 64bit lubuntu 環境の PC と Raspberry Pi 3 Model B+ を使っています。

hotword.py プログラムのこと

Google Assistant Library をセットアップ後の googlesamples/assistant/library/ フォルダには「hotword.py」プログラムが配置されます。実質 100行ほどの短い内容ですが、`sample` と言いながらこのプログラムを利用すればウェイクワードの検知を含め Google アシスタントとのいつものやりとりをそのまま実現することができます。抽象度が高くフロントエンドをこのようにシンプルに実装できることが Google Assistant Library の大きな特長です。
セットアップずみの SDK ディレクトリ下での hotword.py の実行方法は以下の要領です。引数で指定したプロジェクト ID とモデル ID はホスト側に記憶され、変更の必要がなければ次回以降は省略できます。

$ pwd
/home/t/wk/GoogleAssistant

$ ls
env

$ source env/bin/activate

(env) $ googlesamples-assistant-hotword --project-id [設定ずみのプロジェクトID] --device-model-id [設定すみのモデルID]

hotword.py を PC / Raspberry Pi 3 で実行した様子の動画です。ここでは個人的な好みからウェイクワードへの反応音「ポコッ」の再生をコードに加えています。

  
上の動画のラズパイには手持ちの以下のマイク （USB 接続） とスピーカー （3.5mm オーディオジャック接続） を写真の要領でつないでいます。

一連の試作においてはこの hotword.py を下敷きにすることにしました。コンパクトで見通しのよい内容でありながらアシスタントとの応酬に必要な要素の一式が収められているためカスタマイズを試みるための土台としてはまさに好適でしょう。この記事の最後の項目に Google Assistant Library プログラミングを行う上での基本的な作法をまとめています。あわせて参照して下さい。

試作

今回手がけた試作をデモ動画と素のままのソースコードを添えて以下に掲載します。

1. 指定テキストに基づく音声合成と読み上げ

テーマ： Google アシスタントの音声合成機能を単体で利用する。いわゆる Text to Speech。

内容

  • プログラムを起動するとテキスト連続入力モードへ
  • エンターキー区切りで入力した任意のテキストがそのままアシスタントに読み上げられる
  • ウェイクワードは使用しない

デモ： 動画 48秒
  

考えたことなど

  • まず最初に任意のフレーズをアシスタントに自由に喋らせてみたいと考えた。あの耳に馴染んだ声での発話はなかなか流暢で実用性があり、また、Google アシスタントの普及を背景とする記号的な存在感もある
  • だが、アシスタントの音声合成機能は利用者との対話を通じての一連の処理の中で内部的に呼び出されるものであり通常の操作でこれを単体で利用することはできない。また、SDK である Google Assistant Library にもそれを実現可能とする API は用意されていない
  • ここで TTS を実現するための要件をあらためて整理してみると、以下の二点に集約される
    1. 音声データではなく所定のテキストをアシスタント側へ引き渡すこと
    2. 上のテキストの内容をアシスタントに音声合成させてその音声データを再生すること
  • 上記要件 1. については Google Assistant Library にそのものずばりの「send_text_query」 API が存在することをリファレンスで知った。これは使える
    send_text_query(query)

    Sends |query| to the Assistant as if it were spoken by the user.

    This will behave the same as a user speaking the hotword and making a query OR speaking the answer to a follow-on query.

    Parameters: query (str) - The text query to send to the Assistant.
  • 問題は要件 2. だが、任意のフレーズを発話させる方法をひとつ思いついた。Google Assistant サービスをトリガーとする IFTTT アプレットにおいて 「What do you want the Assistant to say in response?」フィールドへ指定したフレーズは利用者が任意に指定すること可能であり、その内容は当該アプレット実行時のレスポンスとしてアシスタントによって発話される。ということは、Assistant サービストリガーを text ingredient オプションつきでアサインし、その text 引数の内容をそのまま response に指定することで「オウム返し」を行う IFTTT アプレットを用意すればよいのではないか？ 指定必須の固定文言を「オウム返し」などと設定した上で「オウム返し ○○○○○」と話しかければ、アシスタントは当該アプレット実行のレスポンスとして「○○○○○」と発話するはず
  • さっそく以下の要領で「オウム返し」アプレットを用意して試したところ動画のように期待どおりの結果が得られた
  • あとは、任意のテキストの頭に "オウム返し " の文字列を挿入した上で前述の send_text_query API 経由でアシスタントへ引き渡せば良いだろう

ソースコード

2. 利用者の発話内容をテキストへ変換

テーマ： Google アシスタントの音声認識機能を単体で利用する。いわゆる Speech to Text。

内容

  • 「エディタを起動」でテキストエディタを起動
  • 発話内容のテキストを連続してエディタへ書き出す
  • この手のことはひと昔以上前から商用化されていたが、認識精度が段違いに向上しておりすでに口述筆記や印刷物のテキスト書き起こしの下書きにも使える水準と言ってよいだろう
  • いろいろ肉付けすれば PC 上で Google アシスタントを Cortana, Siri 風のツールとして利用できるかも

デモ： 動画 41秒
  

考えたことなど

  • 利用者の発話内容をアシスタント側が認識した結果のテキストを取得したい
  • そのテキストは下のように hotword.py 実行時にコンソールへきっちりエコーバックされるためプログラムで拾えそうだが、リファレンスをみてもその方法がわからない。ほしいのはこの中の「'今何時'」の部分なのだが、、 
    ON_CONVERSATION_TURN_STARTED
ON_END_OF_UTTERANCE
ON_RECOGNIZING_SPEECH_FINISHED:
    {'text': '今何時'}
ON_RESPONDING_STARTED:
    {'is_error_response': False}
ON_RESPONDING_FINISHED
ON_CONVERSATION_TURN_FINISHED:
    {'with_follow_on_turn': False}
  • hotword.py#L61-L63 にヒントがあった。以下のコードでは ON_CONVERSATION_TURN_FINISHED イベントの発生時に 「event.args['with_follow_on_turn'])」というパラメータを評価しており、それは上のコンソール出力内容末尾の二行に符合する 
     61 |    if (event.type == EventType.ON_CONVERSATION_TURN_FINISHED and
 62 |            event.args and not event.args['with_follow_on_turn']):
 63 |        print()
  • ということは、「'今何時'」の部分を取得するには、ON_RECOGNIZING_SPEECH_FINISHED の発生時に「event.args['text']」というパラメータを参照すればよいのではないか？
  • 正解！ これでアシスタント側が音声認識した結果のテキストを自由に拾えるようになった
  • せっかくデスクトップ環境なのでエディタの起動やテキスト入力といった GUI 操作の要素も加味することにした

ソースコード

3. 利用者の発話内容を他言語へ連続翻訳

テーマ： Google アシスタントの 音声認識 / 文意解釈 / 言語翻訳 / 応答文生成 / 音声合成 の各機能を利用する

内容

  • 利用者が日本語の文章を発話するとアシスタントがその英訳文を読み上げる
  • 一文ごとにウェイクワードや翻訳のための指示を入れる不要はない
  • 操作に手がかからないのでオフィスや店舗等の多言語環境用に翻訳専用端末として仕立てられるかも

デモ： 動画 52秒
  

考えたことなど

  • 周知のように Google アシスタントには 「"今何時ですか？" を英語に訳して」の要領で話しかけることでその文章を所定の言語へ翻訳する機能がある
  • ただ、毎回ウェイクワードを使うのも毎回「を○○語に」などと指定するのも微妙に面倒。発話した内容を自動的に翻訳してくれれば手間が省けるだろう
  • 手元では、前掲の「利用者の発話内容をテキストへ変換」と「指定テキストに基づく音声合成と読み上げ」の試作を通じて、次のふたつの処理を行う方法を把握している
    1. 利用者が喋った内容をアシスタントが認識した結果のテキストを取得する
    2. 音声ではなくテキストでアシスタントへ指示を送る
  • なので、発話したあとに上記 1. でその内容をテキストとして取得し、その末尾に「 を○○語に訳して」と加えた上で 2. の手順でアシスタントへ渡してやればいいだろう

ソースコード

4. 利用者の発話内容を復唱

テーマ： Google アシスタントの音声認識 / 音声合成機能を利用する

内容

デモ： 動画 42秒
  

考えたことなど

  • 手元では、前掲の「利用者の発話内容をテキストへ変換」と「指定テキストに基づく音声合成と読み上げ」の試作を通じて次のみっつの処理を行う方法を把握ずみ
    1. 利用者が喋った内容をアシスタントが認識した結果のテキストを取得する
    2. 音声ではなくテキストでアシスタントへ指示を送る
    3. アシスタントに「オウム返し」をさせる
  • これらを利用する。自分の発話内容をテキストとして取得し、その先頭に前掲の IFTTT アプレット用のフレーズ「オウム返し 」を挿入してアシスタントへ渡してやる

ソースコード

しりとり

テーマ： Google アシスタントの音声認識 / 音声合成機能を利用する

内容

  • 日本語の単語でアシスタントとしりとりを行う
  • しりとり向きの適当な単語辞書を使用
  • 日本語形態素解析に Janome ライブラリを利用

デモ： 動画 58秒
  

考えたことなど

  • スマートスピーカーまわりで Actions on Google や Alexa スキルを使った「しりとり」アプリを見かけるが、ここまでの内容を応用すれば Google Assistant Library ベースで実装できるのではないか
  • 単語の既出チェックや品詞の制限、単語の学習機能などちゃんとしたものを作ろうとすればそれなりに手がかかるが、必要最小限の単語リレーをするだけなら割と手早く作れるかも
  • しりとり向きの単語辞書が必要。ネット上のリソースをもとにそこそこの語彙数のものを用意することにする
  • 下記要領での処理を想定
    1. 利用者が単語を発話
    2. その内容をアシスタントが認識した結果のテキストを取得
    3. それを形態素解析にかけて読みを取得
    4. その読みの末尾文字に合致する一件の単語を辞書からピックアップしてアシスタントに発話させる
    5. 単語の末尾が「ン」なら終了

ソースコード

  • 別途

メモ： Google Assistant Library プログラミングの基本

hotword.py を通じて

前述のように Google Assistant Library のインターフェイスは抽象度が高くシンプルに扱うことができる。実ロジック 100 行程度の hotoword.py が Google Home デバイスとほぼ同等に Google Assistant と連携可能であることは興味深い。hotoword.py の内容にあらためて目を向けると、デバイス ID 等の管理情報の取り回し以外の実質的な処理は以下のごく短い内容のみであることが見てとれる。

  • hotword.py#L122-L145 より 
    122 |     with Assistant(credentials, device_model_id) as assistant:
123 |         events = assistant.start()
                 :
144 |         for event in events:
145 |             process_event(event)
    （リファレンスより）
    • class google.assistant.library.Assistant(credentials, device_model_id) - developers.google.com
      Client for the Google Assistant Library.

      Provides basic control functionality and lifecycle handling for the Google Assistant. It is best practice to use the Assistant as a ContextManager: 
      with Assistant(credentials, device_model_id) as assistant:
      This allows the underlying native implementation to properly handle memory management.

      Once start() is called, the Assistant generates a stream of Events relaying the various states the Assistant is currently in, for example: 
      ON_CONVERSATION_TURN_STARTED
ON_END_OF_UTTERANCE
ON_RECOGNIZING_SPEECH_FINISHED:
    {'text': 'what time is it'}
ON_RESPONDING_STARTED:
    {'is_error_response': False}
ON_RESPONDING_FINISHED
ON_CONVERSATION_TURN_FINISHED:
    {'with_follow_on_turn': False}
      See EventType for details on all events and their arguments.

  • hotword.py#L47-L66 より 
     47 | def process_event(event):
                  :
 56 |     if event.type == EventType.ON_CONVERSATION_TURN_STARTED:
 57 |         print()
 58 | 
 59 |     print(event)
 60 | 
 61 |     if (event.type == EventType.ON_CONVERSATION_TURN_FINISHED and
 62 |             event.args and not event.args['with_follow_on_turn']):
 63 |         print()
 64 |     if event.type == EventType.ON_DEVICE_ACTION:
 65 |         for command, params in event.actions:
 66 |             print('Do command', command, 'with params', str(params))
    （リファレンスより）
    • ON_CONVERSATION_TURN_STARTED - developers.google.com
      Indicates a new turn has started.

      The Assistant is currently listening, waiting for a user query. This could be the result of hearing the hotword or start_conversation() being called on the Assistant.
      • start_conversation() - developers.google.com
        Manually starts a new conversation with the Assistant.

        Starts both recording the user’s speech and sending it to Google, similar to what happens when the Assistant hears the hotword.

        This method is a no-op if the Assistant is not started or has been muted.
      • stop_conversation() - developers.google.com
        Stops any active conversation with the Assistant.

        The Assistant could be listening to the user’s query OR responding. If there is no active conversation, this is a no-op.
    • ON_CONVERSATION_TURN_FINISHED - developers.google.com
      The Assistant finished the current turn.

      This includes both processing a user’s query and speaking the full response, if any.

ポイント

  • Google Assistant との一連の応酬を開始するには google.assistant.library.Assistant クラスのインスタンスを生成し start() をコールする
  • 応酬中の状況はイベントベースで捕捉可能
    • 対話開始： ON_CONVERSATION_TURN_STARTED
    • 対話終了： ON_CONVERSATION_TURN_FINISHED
    • 後は EventType ごとに必要な処理を記述
  • start_conversation() によりウェイクワードなしで Assistant との対話を開始
  • send_text_query() により発話に代え任意のテキストを Assistant へ送出可能
  • stop_conversation() により Assistant との対話を任意に終了
(tanabe)
klab_gijutsu2 at 10:04
｜この記事のURL│Comments(0)│スマートスピーカ | Google Assistant
2018年09月18日

ISUCON 8 予選で惨敗しました（リュウグウ）

はてなブックマークに登録

@methane です。とうとうISUCON予選敗退を経験してしまいました。 めちゃんこ悔しいです。

16:20には6万点台を出し、そこからはトップ争いを続けて17:47には10万点台を叩き出したものの、その後は2万点台しか出なくなり終了してしまいました。

それまでは調子の悪いときでも数回ベンチをしていれば少なくとも4万点台にはなっていたので、ずっと2万点台しか出なかったのは不運もあったのですが、そもそもスコアが安定しない原因を潰しておけば確実に予選突破できていたはずなのでこれも実力です。

やったこと

役割分担は、僕が全体を見る＆アプリの実装もやる、 makki_d がアプリ、 mapk0y がインフラでした。選択言語はGoです。

最初の方はダッシュボードを作るのに必要な作業を2人にお願いしつつ、自分でもインフラ、アプリのコード両方を見て回りました。

ダッシュボードができてからは getEvent がネックなのが明らかになりました。一方レギュレーションでは予約とキャンセルのスコアが高く、ISUCON2との類似性からもその部分もキーになると判断しました。

getEvent も 予約もキャンセルも、全部 registration テーブルがキーになっています。とくに予約処理は見るからにまずいトランザクションになっているので、 registration テーブルのオンメモリ化に取り掛かりました。

といっても完全なオンメモリ化は諦めていて、ちゃんとDBに書き込んだ上で最新の情報をメモリ上にも載せておくだけです。また、メモリに乗せるのはキャンセルされていない予約だけです。

最初は予約処理とキャンセル処理でメモリ上のデータを正確に更新するところを作りきりました。これができたのがすでに15時ごろでした。(diff)

これができると、次は getEvent でループで registration テーブルを SELECT してるところをメモリ上のデータを使うように書き換えます。 (diff) これが 15:30 頃で、4万点台でやっとトップグループの仲間入りをし、ほっと一息。

次に、さっきの getEvent のループ内で RegisteredAt を求めるためだけに registration を配列から線形探索でやっていたのがネックになっていたので、ループの前に先に sheet id と registered at を対応付ける map を作って置くことで高速化 (16:10ごろ) (diff)

この時点で6万点台は出るようになっていたものの、スコアの乱高下に翻弄され始めます。インフラの設定変更を試してみても大幅にスコアが下がって、設定変更のせいなのかどうか分からなくて迷走してしまいます。 (TIMED_WAIT が多いから nginx -> Go を unix socket に切り替えたものの、スコアが上がらなくなって TCP に戻すなど)

17:00 を過ぎた当たりで、 makki_d が挑戦していたイベント全体のオンメモリ化のバグが取り切れなかったので、 getEvents で event テーブル全体を引いたあとに getEvent で event テーブルを1行ずつ引くという同じテーブルに対する N+1 を潰し (diff)、17:30 には7万7千点。

そこから再起動試験で一度失敗し、2度めの再起動試験で幻の10万点台を 17:47 に出します。

ここで止めておけば良いものの、この一度のハイスコアで「再起動したらスコアがよくなる、なんか遅くなるのは繰り返して実行してるからかもしれない」と誤認してしまいます。 このときに nginx のアクセスログが切れてなかったので、アクセスログを切ってもう一度やろうと指示を出し、結果競技終了までずっと2万点台、最後の1回は1万点台で終了しました。

敗因(技術的問題点)

終了後にメンバーと話し合って、多分これだという問題点を見つけました。

予約とキャンセル処理では、registration のオンメモリキャッシュの一貫性を保護する mutex の中でDBへの更新をしていました。それがつまり気味なのはなんとなく把握していましたが、原因や、ひどいときにどれくらい詰まるのかまでは把握してませんでした。

一方、DBの方でもなにかデッドロックのログが発生していることは気づいていたものの、 admin 系で複雑なクエリがあるので、 admin 系のAPI通しで競合する事があるのかなとあまり気にしていませんでした。

そして、その admin 系の複雑な長いSELECTクエリに、 "for update" が混ざっているものがあることも気づいていて無視していました。

これを総合して考えると、 admin 系の重い SELECT クエリが for update で registration テーブルを盛大に（全体を？）ロックし、予約か削除がロックを握ったままそれを待ち、 getEvent を利用しているすべてのAPIが引きずられて詰まりタイムアウトを発生させる、というシナリオに思い当たります。ベンチマーカーが公開されたら検証してみたいと思います。

実は、mapk0y が作業中に「MariaDBからMySQLに入れ替えます。」「トランザクション分離レベルを read committed から repeatable readに切り替えます」という報告はしてくれていました。SELECTクエリの中で for update が出てくるの、ダーティーリードを避けるためにロックを掛けていたとすれば、 repeatable read に切り替えたときに完全に不要になっていたはず…ぐぬぬ。

訂正: read committed になっていたのは mapk0y が MySQL に入れ替えるときに my.cnf に誤混入しただけで、初期実装は repeatable read だったようです。あのJOINを使ったずっと横スクロールしないと読めない長い一行SELECT文の中に無意味な for update が混じっていたのは、特に必要な理由がない純粋な罠だったのかもしれません。。。

反省点

最大の書換であるところの reservation オンメモリ化を自分でしてしまいましたが、これは makki_d に任せて、自分はもっと調査系に専念するべきでした。手を付けたときに makki_d が他の作業に取り掛かっていたのと、事前練習不足で makki_d が「オンメモリ化」をスラスラ書けるか解らなかったのと、何より「自分が何もできないまま敗北する恐怖」に負けてしまいました。

大きな改修＋それを利用した大規模な高速化が終わってトップグループになったのが16時で、そこからは「競技終了までに何をするか／しないか」に頭が切り替わってしまったので、落ち着いて全体を注意深く調査することができませんでした。

他にも、次のような要因があったと思います。

  • 過去問では report 系APIは整合性検証のためだけに使われることが多かったのでほとんど見てなかった
  • 通過ラインがわからない恐怖から、遅くなる原因追求よりも調子のいいときのスコアアップを優先してしまった

本戦では1位を取るためにスコアアップ優先になるのはある程度しかたありませんが、予選ではトップスコアを取っても通過できなければ意味がありません。来年はもう少し落ち着いて、仕事で負荷対策の調査をするときのようにマズイ点を潰していきたいと思います。

感想

アプリのコードの規模、DBのスキーマの規模ともにISUCONに適したボリュームに抑えつつも、完全オンメモリ化（SELECTを削除し、DBへの書き込みをロック外に追い出しても整合性が担保できる）が難しい複雑なSQLが散りばめられているバランスが素晴らしかったです。いろんなチームがそれぞれの得意なやり方で勝ちを狙えたはずで、本戦にしないのがもったいない、これ以上ないくらいの良問でした。

また、去年の予選でやらかしてしまった原因の「予選で複数台構成」を今年も継承してきたことにも驚きました。参加者視点で見たら、万が一設定をミスってSSHできなくなるような事態になっても試合終了にならない安心感は良いですね。

その複数台構成の活用方法も、去年に比べてずっと自由度が高いのが良かったです。

本当にこれまでで最高のISUCONだったと思います。ありがとうございました。 これが予選なら本戦はどうなるのか、参加できないのが悔しくて仕方ありません。

songofacandy at 11:04
｜この記事のURL│Comments(0)│ISUCON 
2018年09月05日

ESP32 モジュールのフラッシュメモリ暗号化機構に関するメモ

はてなブックマークに登録

ESP-WROOM-32 の内蔵フラッシュメモリについて調べていたところで Flash Encryption に興味を持ちその便利さを実感しました。 利用方法にやや込み入った要素も含まれるため自分用のメモとして一連の情報を控えておくことにします。

重要： この記事には誤りが含まれている可能性があります。たとえその誤りが原因で何処かで何らかの損害が発生したとしても筆者ならびに当社は一切の責任を負いません。実験や操作は上記公式ドキュメントを熟読の上必ず自己責任で慎重に行って下さい。

概要

ESP32 モジュールのフラッシュメモリは esptool を使えば簡単に読み書きできるためバックアップ等に便利ですが、その一方で、自分の手を離れた場所で装置を稼働させる場合などに他者に不正なクローンを作成されたりコードに含まれるセンシティブな情報を読まれてしまう可能性もあります。 こういった懸念は Flash Encryption 機構を利用すれば格段に軽減されます。所定のモジュールのもとで暗号化したイメージを他のモジュールへ持ち込んで稼働させることはできず、そこから情報を窃視することもできません。

ただし、Flash Encryption の利用には大きくふたつの注意すべき点があります。

  1. ESP32 チップ内の OTP メモリへの不可逆な書き込みを伴う
  2. ひとたび Flash Encryption を適用したモジュールにおいてそれ以降のイメージの更新時に再暗号化を実施可能な回数は「3 回」まで

このように、アクティブな開発や実験のフェーズ向きではなくおおむねプログラム完成段階での本番機や製品への適用を想定した機構と言えるでしょう。そういった事情も相まってか、これを積極的に利用している個人ユーザは今のところあまり多くないように見受けられます。

フラッシュメモリ暗号化の多くのメリットを考えると惜しく感じられますが、実際には上記 2. の制限は「事前生成暗号化キー」を適切に取り回すことで回避が可能です。その方法であれば Flash Encryption をごく手軽に扱えるため、たとえばプロトタイピング段階での試作機での利用など様々な活用方法が考えられるでしょう。

以下の記事では、最初に Flash Encryption のしくみの整理を行い、次に上記の事前生成暗号化キーを利用する手順と実際にその操作を行った記録を列挙、最後に Arduino core for ESP32 環境での対応方法等について手元で行った実験の内容とその結果に触れています。 なお、Espressif は別のセキュリティ機構である Secure Boot との併用を推奨していますが、この記事ではまず Flash Encryption 単体に注目しています。

  • 手元では Linux 環境で作業を行っており、記事中のコマンド発行例などに「/dev/ttyUSB0」等の環境に即した記述が含まれます
  • Flash Encryption の操作で使用する esptool, espefuse, espsecure の各ユーティリティは、Linux, MacOSX 環境用には Python スクリプトとして、Windows 環境用には exe 実行形式で提供されています。記事での構文例には上と同じ理由で ".py" の拡張子を記述している箇所があります

Flash Encryption のしくみ

まず、公式ドキュメントの内容をもとに Flash Encryption のしくみを整理します。

全体像

  

  • Flash Encryption は ESP32 モジュールの内蔵フラッシュメモリ上の所定のパーティションの内容を AES-256 で暗号化するもの
  • 暗号化キーは当該モジュールで初めて暗号化を行う際に ESP32 チップ内の efuse 領域内にランダムに生成され永続的に保持される。生成されたキーへの外部からのアクセスはデフォルトで不可
    • ESP32 efuse の詳細 => espefuse - github.com/espressif
  • 暗号化はブートローダが行う。具体的には、make menuconfig - [Security Features] - [Enable flash encryption boot] オプションを有効にした状態でビルドしたブートローダが、他のパーティションイメージとともに make flash された後の初回起動時に一括して暗号化を実施する
    • つまり、上記オプションはその目的に即したブートローダコードを生成するものであり、その他のパーティションイメージは通常の内容でビルドされる
  • 暗号化の対象は以下のとおり
    • ブートローダ （オフセット 0x1000, 最長サイズ 0x7000 バイト）
    • パーティションテーブル （オフセット 0x8000, サイズ 0xC00 バイト）
    • Type = app のパーティション
    • encrypted フラグの指定されたパーティション
      • ただし、手元の確認では設定上 spiffs パーティションの定義に「spiffs,data,spiffs,0x291000,0x16F000,encrypted」の要領で指定を付与し暗号化を有効にしたところプログラム実行時に次のエラーが発生した： "spiffs can not run on encrypted partition"
    • nvs パーティション （key-value ストア領域） を暗号化することはできない。 spiffs と同様に nvs にも専用の API セットが用意されておりそっち側の実装とのかねあいだったり？
    • ドキュメント上の関連箇所の引用。ちなみに手元ではまだ使ったことのない「phy」パーティションについての言及があるが、「physical access readout」が NG につき esptool 等で読み出し不能であるためトレードオフを理解した上で利用すべきだろう
      • None of the default partition tables include any encrypted data partitions.
      • It is not necessary to mark “app” partitions as encrypted, they are always treated as encrypted.
      • The “encrypted” flag does nothing if flash encryption is not enabled.
      • It is possible to mark the optional phy partition with phy_init data as encrypted, if you wish to protect this data from physical access readout or modification.
      • It is not possible to mark the nvs partition as encrypted.
  • 稼働中のプログラムからフラッシュメモリ上のデータ参照の際の復号は透過的に行われる

注意点

Flash Encryption においては 8 ビットの「FLASH_CRYPT_CNT」efuse が非常に重要。あらかじめその役割と意味を正しく把握しておく必要がある。

  • まず、手元にある Flash Encryption 未実施の ESP32-DevKitC に対し Espressif 提供の espefuse ユーティリティの summary コマンド, dump コマンドを実行した結果を以下に示す 
    $ espefuse.py --port /dev/ttyUSB0 summary
espefuse.py v2.3.1
Connecting.....
Security fuses:
FLASH_CRYPT_CNT        Flash encryption mode counter                     = 0 R/W (0x0)
FLASH_CRYPT_CONFIG     Flash encryption config (key tweak bits)          = 0 R/W (0x0)
CONSOLE_DEBUG_DISABLE  Disable ROM BASIC interpreter fallback            = 0 R/W (0x0)
ABS_DONE_0             secure boot enabled for bootloader                = 0 R/W (0x0)
ABS_DONE_1             secure boot abstract 1 locked                     = 0 R/W (0x0)
JTAG_DISABLE           Disable JTAG                                      = 0 R/W (0x0)
DISABLE_DL_ENCRYPT     Disable flash encryption in UART bootloader       = 0 R/W (0x0)
DISABLE_DL_DECRYPT     Disable flash decryption in UART bootloader       = 0 R/W (0x0)
DISABLE_DL_CACHE       Disable flash cache in UART bootloader            = 0 R/W (0x0)
BLK1                   Flash encryption key                              
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W 
BLK2                   Secure boot key                                   
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W 
BLK3                   Variable Block 3                                  
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W 

Efuse fuses:
WR_DIS                 Efuse write disable mask                          = 0 R/W (0x0)
RD_DIS                 Efuse read disablemask                            = 0 R/W (0x0)
CODING_SCHEME          Efuse variable block length scheme                = 0 R/W (0x0)
KEY_STATUS             Usage of efuse block 3 (reserved)                 = 0 R/W (0x0)

Config fuses:
XPD_SDIO_FORCE         Ignore MTDI pin (GPIO12) for VDD_SDIO on reset    = 0 R/W (0x0)
XPD_SDIO_REG           If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset   = 0 R/W (0x0)
XPD_SDIO_TIEH          If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V   = 0 R/W (0x0)
SPI_PAD_CONFIG_CLK     Override SD_CLK pad (GPIO6/SPICLK)                = 0 R/W (0x0)
SPI_PAD_CONFIG_Q       Override SD_DATA_0 pad (GPIO7/SPIQ)               = 0 R/W (0x0)
SPI_PAD_CONFIG_D       Override SD_DATA_1 pad (GPIO8/SPID)               = 0 R/W (0x0)
SPI_PAD_CONFIG_HD      Override SD_DATA_2 pad (GPIO9/SPIHD)              = 0 R/W (0x0)
SPI_PAD_CONFIG_CS0     Override SD_CMD pad (GPIO11/SPICS0)               = 0 R/W (0x0)
DISABLE_SDIO_HOST      Disable SDIO host                                 = 0 R/W (0x0)

Identity fuses:
MAC                    MAC Address                                       
  = 30:ae:a4:02:59:c0 (CRC 9b OK) R/W 
CHIP_VER_REV1          Silicon Revision 1                                = 0 R/W (0x0)
CHIP_VERSION           Reserved for future chip versions                 = 0 R/W (0x0)
CHIP_PACKAGE           Chip package identifier                           = 0 R/W (0x0)

Calibration fuses:
BLK3_PART_RESERVE      BLOCK3 partially served for ADC calibration data  = 0 R/W (0x0)
ADC_VREF               Voltage reference calibration                     = 1100 R/W (0x0)

Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V).

    $ espefuse.py --port /dev/ttyUSB0 dump
espefuse.py v2.3.1
Connecting....
EFUSE block 0:
00000000 a40259c0 009b30ae 00000000 00000036 00000000 00000000
EFUSE block 1:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
EFUSE block 2:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
EFUSE block 3:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  • FLASH_CRYPT_CNT は暗号化を行った回数と暗号化の有効無効状態を管理する。初期値は上のとおりゼロ （BIN: 0000 0000）であり、ブートローダが初めて暗号化を行った時点で BIN:0000 0001 に変化する （不可逆）
  • FLASH_CRYPT_CNT の ON ビット数が偶数の場合は暗号化が無効な状態、奇数の場合は暗号化が有効な状態であることを示す
  • FLASH_CRYPT_CNT の ON ビット数が奇数、すなわち暗号化が有効な状態で別のプレーンなイメージを make flash すると起動不可となる。これは、ESP32 が efuse 領域に保持しているキーで暗号化されたイメージの期待される状況であるにもかかわらず場違いなイメージに直面した結果の所作
  • 上記のような場合には以下の手順で Flash Encryption を無効化することができる （注：手元ではこの操作は未確認）
    1. make menuconfig - [Security Features] - [Enable flash encryption boot] オプションを確実に無効化して make && make flash
    2. 手作業で FLASH_CRYPT_CNT の ON ビット数を偶数にすることで暗号化無効の状態にする。具体的には、espefuse ユーティリティを使って FLASH_CRYPT_CNT に対し burn_efuse コマンドを発行すると現在もっとも上位の ON ビットの左側のビットが ON になる。つまり、FLASH_CRYPT_CNT ＝ BIN:0000 0001 の状態で実行すると BIN:0000 0011 に変化する => ON ビット数が偶数なので暗号化無効状態
      espefuse.py --port /dev/ttyUSB0 burn_efuse FLASH_CRYPT_CNT
    3. ESP32 ボードをリセットすると正常に稼働する

  • OTP メモリである efuse 領域への変更は不可逆であるため、8 ビットの FLASH_CRYPT_CNT に対する上記の「暗号化と無効化」の上限回数は 4 回。以下に状態の一覧を示す。 9. の無効化 4 回めで全ビットが ON ＝ 0xFF になると当該 ESP32 モジュールでの Flash Encryption は永久に無効となる
    1. BIN:0000 0000　工場出荷時
    2. BIN:0000 0001　暗号化 1 回め
    3. BIN:0000 0011　無効化 1 回め
    4. BIN:0000 0111　暗号化 2 回め
    5. BIN:0000 1111　無効化 2 回め
    6. BIN:0001 1111　暗号化 3 回め
    7. BIN:0011 1111　無効化 3 回め
    8. BIN:0111 1111　暗号化 4 回め
    9. BIN:1111 1111　無効化 4 回め

  • なお、ある時点での FLASH_CRYPT_CNT の状態を永続化させたい場合は espefuse.py の write_protect_efuse コマンドを実行する。誤って実行すると手詰まりになるため要注意
    espefuse.py --port /dev/ttyUSB0 write_protect_efuse FLASH_CRYPT_CNT
  • また、以下の事情にも注意が必要
    • Read- and Write- protecting efuses - espefuse - github.com/espressif
      NOTE that efuses are often read/write protected as a group, so protecting one will cause some related efuses to become protected. espefuse.py will confirm the full list of efuses that will become protected.

事前生成暗号化キーの利用による Flash Encryption

ESP32 チップ内部に保持されるフラッシュメモリ暗号化キーはホスト PC 上で生成することが可能です。キーの生成を ESP32 側で行うとそれ以降の暗号化処理は前述の FLASH_CRYPT_CNT の管理下でブートローダへ委ねることになりますが、ホスト PC 上でキーを生成すれば開発者が主体的に所定のイメージの暗号化を行うことが可能となり、貴重な FLASH_CRYPT_CNT を消費することなく Flash Encryption を継続的に利用できます。ホスト PC 上で生成したキーは espefuse ユーティリティの burn_key コマンドで ESP32 の efuse 領域へ書き込んだ上で使用します。

概要

ドキュメントより。

  • Reflashing via Pregenerated Flash Encryption Key - Flash Encryption - esp-idf.readthedocs.io
    Reflashing via Pregenerated Flash Encryption Key

    It is possible to pregenerate a flash encryption key on the host computer and burn it into the ESP32’s efuse key block. This allows data to be pre-encrypted on the host and flashed to the ESP32 without needing a plaintext flash update.

    This is useful for development, because it removes the 4 time reflashing limit. It also allows reflashing the app with secure boot enabled, because the bootloader doesn’t need to be reflashed each time.

    Important

    This method is intended to assist with development only, not for production devices. If pre-generating flash encryption for production, ensure the keys are generated from a high quality random number source and do not share the same flash encryption key across multiple devices.
           :
    Google 訳：
    事前生成されたフラッシュ暗号化キーによるリフラッシュ

    ホストコンピュータにフラッシュ暗号化キーを事前に生成し、ESP32のefuseキーブロックに書き込むことができます。これにより、データをホスト上で事前暗号化し、平文フラッシュ更新を必要とせずにESP32にフラッシュすることができます。

    これは4回のリフラッシュ制限を取り除くため、開発に役立ちます。また、毎回ブートローダをリフラッシュする必要がないため、セキュアブートを有効にしてアプリをリフラッシュすることもできます。

    重要

    このメソッドは、開発の支援のみ目的としており、本番用のデバイス用ではありません。プロダクション用のフラッシュ暗号化を事前生成する場合は、キーが高品質の乱数ソースから生成され、複数のデバイス間で同じフラッシュ暗号化キーを共有しないようにしてください。
           :
多くの個人ユーザの作業の大部分はまさに「開発」であり、その過程でフラッシュメモリ暗号化の恩恵を享受できることは有り難い。事前生成暗号化キーを利用した Flash Encryption の流れを下図に示す。

手順

以下の一連の手順では、既出の esptool, espefuse に加え、espsecure ユーティリティを使用する。

初回の暗号化を終えるまで

第一段階として、まず初回の暗号化までを完了させる。ホスト PC 上で生成した暗号化キーを ESP32 の efuse へ先行して書き込むことがここでのポイント。

  1. 暗号化キーをホスト PC 上で生成する。初回のみ。絶対に紛失しないこと
    espsecure.py generate_flash_encryption_key ./mykey.bin
  2. 生成したキーを ESP32 の efuse へ書き込む。取り消し不可
    espefuse.py --port /dev/ttyUSB0 burn_key flash_encryption ./mykey.bin
    ※この手順で下記「3. 初回の Flash Encryption」に先行して efuse へ暗号化キーを書き込むことにより、本来はブートローダによる初回の暗号化実行の前処理として ESP32 チップ内で行われる暗号化キーの生成がスキップされる
  3. 初回の Flash Encryption を実行
    初回の暗号化は事前生成キーを使わない場合の手順と同じ
    1. make menuconfig で [Security Features] - [Enable flash encryption boot] オプションを有効にして保存終了
    2. make を実行
    3. make flash monitor を実行
    4. flash 後のリセットを経てブートローダによる暗号化が始まる（完了まで電源を落とさないこと）。シリアル出力の monitor は Ctrl+']' で終了
    5. 暗号化が完了するとブートローダが ESP32 にリセットをかける 〜 暗号化されたイメージでプログラムが起動
    6. 前掲の espefuse.py --port [PORT] summary コマンドを実行し先頭の FLASH_CRYPT_CNT が「1 R/W (0x1)」に変わっていることを確認

ホスト PC 上でのイメージの暗号化とフラッシュメモリへの書き込み

初回の暗号化は上の手順で OK。それ以降にビルドしたイメージについては手元で暗号化を行った上で ESP32 へ転送すればよい。以下の例は app パーティションイメージ分だが、必要に応じて他のイメージも暗号化して書き込む。なお、ビルドしたままの状態のブートローダイメージを再度フラッシュしてはならない。ESP32 側ではブートローダ自体もすでに暗号化されているため。

  1. 更新したプログラムを make してイメージをビルドする。make flash は行わないこと
  2. espsecure.py ユーティリティを使ってホスト PC 上で当該イメージを暗号化する。--address はイメージビルド時点のパーティション定義にそって指定する。 下記例では元のプレーンなイメージが「build/mySimpleApp.bin」であり、出力する暗号化イメージが「build/mySimpleApp_Encrypted.bin」である
    espsecure.py encrypt_flash_data --keyfile ./mykey.bin --address 0x10000 -o build/mySimpleApp_Encrypted.bin build/mySimpleApp.bin
  3. 暗号化したイメージを esptool で ESP32 フラッシュメモリへ書き込んで完了
    esptool.py --port /dev/ttyUSB0 --baud 921600 write_flash 0x10000 build/mySimpleApp_Encrypted.bin

前項の操作を行った記録

手元で実際に前項の操作を行いその様子と結果を記録しました。これが初めての Flash Encryption の操作で、各動画は一発撮りしたものです。

テスト用のプログラムとして以下の「mySimpleApp.c」を使用。LED 点滅ループ中に Flash Encryption の有効無効状態をシリアル出力する内容。 

#include <stdio.h>
#include "esp_flash_encrypt.h"
#include "esp_event.h"
#include "esp_log.h"
#include "driver/gpio.h"

const char *secretData = "**** this is secret data ****";
const char *TAG = "TAG";

void app_main()
{
  ESP_LOGI(TAG, "%s", secretData);
  gpio_set_direction(GPIO_NUM_2, GPIO_MODE_OUTPUT);
  int sts = 1;
  for (int i = 0; i < 10; i++) {
    if (esp_flash_encryption_enabled()) {
      ESP_LOGI(TAG, "Flash Encryption is enabled");
    } else {
      ESP_LOGI(TAG, "Flash Encryption is disabled");
    }
    gpio_set_level(GPIO_NUM_2, sts);
    sts = !sts;
    vTaskDelay(1000 / portTICK_PERIOD_MS);
  }
}
まず Flash Encryption 有効化前の素の状態のボードに対し make flash monitor を行った様子。"Flash Encryption is disabled" の出力が見える。

動画 A
  

以下、事前生成暗号化キーを使った Flash Encryption 操作の記録。

  1. 暗号化キーをホスト PC 上で生成 〜 生成したキーを ESP32 の efuse 領域へ書き込む 
    $ espsecure.py generate_flash_encryption_key ./mykey.bin
espsecure.py v2.3.1

$ espefuse.py --port /dev/ttyUSB0 burn_key flash_encryption ./mykey.bin
espefuse.py v2.3.1
Connecting......
Write key in efuse block 1. The key block will be read and write protected (no further changes or readback). This is an irreversible operation.
Type 'BURN' (all capitals) to continue.
BURN
Burned key data. New value: 6a 60 3c a7 d0 3f d4 9f b0 a3 f9 ca 77 61 10 47 30 57 80 c5 5c fd bc a0 ce 30 3e 36 b1 b5 ac c4
Disabling read/write to key efuse block...
    動画 B
  2. 上記 1. 操作後の efuse の状態 
    $ espefuse.py --port /dev/ttyUSB0 summary
espefuse.py v2.3.1
Connecting......
Security fuses:
FLASH_CRYPT_CNT        Flash encryption mode counter                     = 0 R/W (0x0)
FLASH_CRYPT_CONFIG     Flash encryption config (key tweak bits)          = 0 R/W (0x0)
CONSOLE_DEBUG_DISABLE  Disable ROM BASIC interpreter fallback            = 0 R/W (0x0)
ABS_DONE_0             secure boot enabled for bootloader                = 0 R/W (0x0)
ABS_DONE_1             secure boot abstract 1 locked                     = 0 R/W (0x0)
JTAG_DISABLE           Disable JTAG                                      = 0 R/W (0x0)
DISABLE_DL_ENCRYPT     Disable flash encryption in UART bootloader       = 0 R/W (0x0)
DISABLE_DL_DECRYPT     Disable flash decryption in UART bootloader       = 0 R/W (0x0)
DISABLE_DL_CACHE       Disable flash cache in UART bootloader            = 0 R/W (0x0)
BLK1                   Flash encryption key                              
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -/- 
BLK2                   Secure boot key                                   
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W 
BLK3                   Variable Block 3                                  
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W 

Efuse fuses:
WR_DIS                 Efuse write disable mask                          = 128 R/W (0x80)
RD_DIS                 Efuse read disablemask                            = 1 R/W (0x1)
CODING_SCHEME          Efuse variable block length scheme                = 0 R/W (0x0)
KEY_STATUS             Usage of efuse block 3 (reserved)                 = 0 R/W (0x0)

Config fuses:
XPD_SDIO_FORCE         Ignore MTDI pin (GPIO12) for VDD_SDIO on reset    = 0 R/W (0x0)
XPD_SDIO_REG           If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset   = 0 R/W (0x0)
XPD_SDIO_TIEH          If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V   = 0 R/W (0x0)
SPI_PAD_CONFIG_CLK     Override SD_CLK pad (GPIO6/SPICLK)                = 0 R/W (0x0)
SPI_PAD_CONFIG_Q       Override SD_DATA_0 pad (GPIO7/SPIQ)               = 0 R/W (0x0)
SPI_PAD_CONFIG_D       Override SD_DATA_1 pad (GPIO8/SPID)               = 0 R/W (0x0)
SPI_PAD_CONFIG_HD      Override SD_DATA_2 pad (GPIO9/SPIHD)              = 0 R/W (0x0)
SPI_PAD_CONFIG_CS0     Override SD_CMD pad (GPIO11/SPICS0)               = 0 R/W (0x0)
DISABLE_SDIO_HOST      Disable SDIO host                                 = 0 R/W (0x0)

Identity fuses:
MAC                    MAC Address                                       
  = 30:ae:a4:02:59:c0 (CRC 9b OK) R/W 
CHIP_VER_REV1          Silicon Revision 1                                = 0 -/W (0x0)
CHIP_VERSION           Reserved for future chip versions                 = 0 -/W (0x0)
CHIP_PACKAGE           Chip package identifier                           = 0 -/W (0x0)

Calibration fuses:
BLK3_PART_RESERVE      BLOCK3 partially served for ADC calibration data  = 0 -/W (0x0)
ADC_VREF               Voltage reference calibration                     = 1100 -/W (0x0)

Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V).


    $ espefuse.py --port /dev/ttyUSB0 dump
espefuse.py v2.3.1
Connecting....
EFUSE block 0:
00010080 a40259c0 009b30ae 00000000 00000036 00000000 00000000
EFUSE block 1:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
EFUSE block 2:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
EFUSE block 3:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  3. make menuconfig で [Security Features] - [Enable flash encryption boot] を有効化した後で make を実行 
    $ make
CC build/bootloader/bootloader_support/src/bootloader_clock.o
CC build/bootloader/bootloader_support/src/bootloader_flash.o
CC build/bootloader/bootloader_support/src/bootloader_init.o
CC build/bootloader/bootloader_support/src/bootloader_random.o
CC build/bootloader/bootloader_support/src/bootloader_sha.o
CC build/bootloader/bootloader_support/src/bootloader_utility.o
CC build/bootloader/bootloader_support/src/efuse.o
                     （中略）
CC build/xtensa-debug-module/trax.o
AR build/xtensa-debug-module/libxtensa-debug-module.a
LD build/mySimpleApp.elf
esptool.py v2.3.1
To flash all build output, run 'make flash' or:
python /home/t/esp/esp-idf/components/esptool_py/esptool/esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 115200 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 /home/t/Arduino/my/for_ESP-IDF/mySimpleApp/build/bootloader/bootloader.bin 0x10000 /home/t/Arduino/my/for_ESP-IDF/mySimpleApp/build/mySimpleApp.bin 0x8000 /home/t/Arduino/my/for_ESP-IDF/mySimpleApp/build/partitions_singleapp.bin
    余談ながら、上の最終行のコマンド例中の「--after hard_reset」の記述が気になり Advanced Options - espressif/esptool Wiki で確認したところ、「--after no_reset」オプションの存在を知った。デフォルトは「--after hard_reset」。esptool 操作後に自動的にリセットがかかると具合のわるい場合があるが、no_reset 指定でそれを回避できることを覚えた。
    動画 C
  4. make flash monitor --- ブートローダが各パーティションを暗号化している状況が見てとれる。その後起動した mySimpleApp からのメッセージ出力が "Flash Encryption is enabled" に変化している 
    $ make flash monitor
Flashing binaries to serial port /dev/ttyUSB0 (app at offset 0x10000)...
esptool.py v2.3.1
Connecting........_
Chip is ESP32D0WDQ6 (revision 0)
Features: WiFi, BT, Dual Core
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Flash params set to 0x0220
Compressed 25296 bytes to 14703...
Wrote 25296 bytes (14703 compressed) at 0x00001000 in 1.3 seconds (effective 156.4 kbit/s)...
Hash of data verified.
Compressed 140160 bytes to 68713...
Wrote 140160 bytes (68713 compressed) at 0x00010000 in 6.1 seconds (effective 184.8 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 103...
Wrote 3072 bytes (103 compressed) at 0x00008000 in 0.0 seconds (effective 1885.7 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
MONITOR
--- idf_monitor on /dev/ttyUSB0 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:7400
load:0x40078000,len:0
ho 12 tail 0 room 4
load:0x40078000,len:17796
entry 0x40078724
I (31) boot: ESP-IDF v3.1-dev-1171-g358c822 2nd stage bootloader
I (31) boot: compile time 16:28:39
I (31) boot: Enabling RNG early entropy source...
I (37) boot: SPI Speed      : 40MHz
I (41) boot: SPI Mode       : DIO
I (45) boot: SPI Flash Size : 4MB
I (49) boot: Partition Table:
I (52) boot: ## Label            Usage          Type ST Offset   Length
I (60) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (67) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (75) boot:  2 factory          factory app      00 00 00010000 00100000
I (82) boot: End of partition table
I (86) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x05888 ( 22664) map
I (103) esp_image: segment 1: paddr=0x000158b0 vaddr=0x3ffb0000 size=0x02284 (  8836) load
I (107) esp_image: segment 2: paddr=0x00017b3c vaddr=0x40080000 size=0x00400 (  1024) load
0x40080000: _iram_start at /home/t/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

I (113) esp_image: segment 3: paddr=0x00017f44 vaddr=0x40080400 size=0x080cc ( 32972) load
I (136) esp_image: segment 4: paddr=0x00020018 vaddr=0x400d0018 size=0x11ccc ( 72908) map
0x400d0018: _flash_cache_start at ??:?

I (161) esp_image: segment 5: paddr=0x00031cec vaddr=0x400884cc size=0x00668 (  1640) load
0x400884cc: esp_rom_spiflash_program_page_internal at /home/t/esp/esp-idf/components/spi_flash/spi_flash_rom_patch.c:412

I (162) esp_image: segment 6: paddr=0x0003235c vaddr=0x400c0000 size=0x00000 (     0) load
I (174) boot: Loaded app from partition at offset 0x10000
I (174) boot: Checking flash encryption...
W (179) flash_encrypt: Using pre-loaded flash encryption key in EFUSE block 1
I (187) flash_encrypt: Setting CRYPT_CONFIG efuse to 0xF
I (205) flash_encrypt: Disable UART bootloader encryption...
I (205) flash_encrypt: Disable UART bootloader decryption...
I (208) flash_encrypt: Disable UART bootloader MMU cache...
I (214) flash_encrypt: Disable JTAG...
I (218) flash_encrypt: Disable ROM BASIC interpreter fallback...
I (237) esp_image: segment 0: paddr=0x00001020 vaddr=0x3fff0018 size=0x00004 (     4) 
I (237) esp_image: segment 1: paddr=0x0000102c vaddr=0x3fff001c size=0x01ce8 (  7400) 
I (247) esp_image: segment 2: paddr=0x00002d1c vaddr=0x40078000 size=0x00000 (     0) 
I (253) esp_image: segment 3: paddr=0x00002d24 vaddr=0x40078000 size=0x04584 ( 17796) 
I (701) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x05888 ( 22664) map
I (709) esp_image: segment 1: paddr=0x000158b0 vaddr=0x3ffb0000 size=0x02284 (  8836) 
I (712) esp_image: segment 2: paddr=0x00017b3c vaddr=0x40080000 size=0x00400 (  1024) 
0x40080000: _iram_start at /home/t/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

I (716) esp_image: segment 3: paddr=0x00017f44 vaddr=0x40080400 size=0x080cc ( 32972) 
I (736) esp_image: segment 4: paddr=0x00020018 vaddr=0x400d0018 size=0x11ccc ( 72908) map
0x400d0018: _flash_cache_start at ??:?

I (762) esp_image: segment 5: paddr=0x00031cec vaddr=0x400884cc size=0x00668 (  1640) 
0x400884cc: esp_rom_spiflash_program_page_internal at /home/t/esp/esp-idf/components/spi_flash/spi_flash_rom_patch.c:412

I (763) esp_image: segment 6: paddr=0x0003235c vaddr=0x400c0000 size=0x00000 (     0) 
I (768) flash_encrypt: Encrypting partition 2 at offset 0x10000...
[0;3oets Jun  8 2016 00:22:57

rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:7400
load:0x40078000,len:0
ho 12 tail 0 room 4
load:0x40078000,len:17796
entry 0x40078724
I (30) boot: ESP-IDF v3.1-dev-1171-g358c822 2nd stage bootloader
I (30) boot: compile time 16:28:39
I (30) boot: Enabling RNG early entropy source...
I (36) boot: SPI Speed      : 40MHz
I (41) boot: SPI Mode       : DIO
I (45) boot: SPI Flash Size : 4MB
I (49) boot: Partition Table:
I (52) boot: ## Label            Usage          Type ST Offset   Length
I (59) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (67) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (74) boot:  2 factory          factory app      00 00 00010000 00100000
I (82) boot: End of partition table
I (86) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x05888 ( 22664) map
I (103) esp_image: segment 1: paddr=0x000158b0 vaddr=0x3ffb0000 size=0x02284 (  8836) load
I (107) esp_image: segment 2: paddr=0x00017b3c vaddr=0x40080000 size=0x00400 (  1024) load
0x40080000: _iram_start at /home/t/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

I (113) esp_image: segment 3: paddr=0x00017f44 vaddr=0x40080400 size=0x080cc ( 32972) load
I (136) esp_image: segment 4: paddr=0x00020018 vaddr=0x400d0018 size=0x11ccc ( 72908) map
0x400d0018: _flash_cache_start at ??:?

I (163) esp_image: segment 5: paddr=0x00031cec vaddr=0x400884cc size=0x00668 (  1640) load
0x400884cc: esp_rom_spiflash_program_page_internal at /home/t/esp/esp-idf/components/spi_flash/spi_flash_rom_patch.c:412

I (163) esp_image: segment 6: paddr=0x0003235c vaddr=0x400c0000 size=0x00000 (     0) load
I (175) boot: Loaded app from partition at offset 0x10000
I (175) boot: Checking flash encryption...
I (180) flash_encrypt: flash encryption is enabled (3 plaintext flashes left)
I (188) boot: Disabling RNG early entropy source...
I (193) cpu_start: Pro cpu up.
I (197) cpu_start: Starting app cpu, entry point is 0x40080e4c
0x40080e4c: call_start_cpu1 at /home/t/esp/esp-idf/components/esp32/cpu_start.c:225

I (0) cpu_start: App cpu up.
I (208) heap_init: Initializing. RAM available for dynamic allocation:
I (214) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (220) heap_init: At 3FFB32C0 len 0002CD40 (179 KiB): DRAM
I (227) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (233) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (239) heap_init: At 40088B34 len 000174CC (93 KiB): IRAM
I (246) cpu_start: Pro cpu start user code
I (264) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (265) TAG: **** this is secret data ****
I (265) TAG: Flash Encryption is enabled
I (1265) TAG: Flash Encryption is enabled
I (2265) TAG: Flash Encryption is enabled
I (3265) TAG: Flash Encryption is enabled
I (4265) TAG: Flash Encryption is enabled
I (5265) TAG: Flash Encryption is enabled
I (6265) TAG: Flash Encryption is enabled
I (7265) TAG: Flash Encryption is enabled
I (8265) TAG: Flash Encryption is enabled
I (9265) TAG: Flash Encryption is enabled
    動画 D
  5. 上記 4. 初回暗号化完了後の efuse の状態 -- FLASH_CRYPT_CNT efuse の値が正しく「0x01」に変化 
    $ espefuse.py --port /dev/ttyUSB0 summary

espefuse.py v2.3.1
Connecting.....
Security fuses:
FLASH_CRYPT_CNT        Flash encryption mode counter                     = 1 R/W (0x1)
FLASH_CRYPT_CONFIG     Flash encryption config (key tweak bits)          = 15 R/W (0xf)
CONSOLE_DEBUG_DISABLE  Disable ROM BASIC interpreter fallback            = 1 R/W (0x1)
ABS_DONE_0             secure boot enabled for bootloader                = 0 R/W (0x0)
ABS_DONE_1             secure boot abstract 1 locked                     = 0 R/W (0x0)
JTAG_DISABLE           Disable JTAG                                      = 1 R/W (0x1)
DISABLE_DL_ENCRYPT     Disable flash encryption in UART bootloader       = 1 R/W (0x1)
DISABLE_DL_DECRYPT     Disable flash decryption in UART bootloader       = 1 R/W (0x1)
DISABLE_DL_CACHE       Disable flash cache in UART bootloader            = 1 R/W (0x1)
BLK1                   Flash encryption key                              
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -/- 
BLK2                   Secure boot key                                   
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W 
BLK3                   Variable Block 3                                  
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W 

Efuse fuses:
WR_DIS                 Efuse write disable mask                          = 128 R/W (0x80)
RD_DIS                 Efuse read disablemask                            = 1 R/W (0x1)
CODING_SCHEME          Efuse variable block length scheme                = 0 R/W (0x0)
KEY_STATUS             Usage of efuse block 3 (reserved)                 = 0 R/W (0x0)

Config fuses:
XPD_SDIO_FORCE         Ignore MTDI pin (GPIO12) for VDD_SDIO on reset    = 0 R/W (0x0)
XPD_SDIO_REG           If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset   = 0 R/W (0x0)
XPD_SDIO_TIEH          If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V   = 0 R/W (0x0)
SPI_PAD_CONFIG_CLK     Override SD_CLK pad (GPIO6/SPICLK)                = 0 R/W (0x0)
SPI_PAD_CONFIG_Q       Override SD_DATA_0 pad (GPIO7/SPIQ)               = 0 R/W (0x0)
SPI_PAD_CONFIG_D       Override SD_DATA_1 pad (GPIO8/SPID)               = 0 R/W (0x0)
SPI_PAD_CONFIG_HD      Override SD_DATA_2 pad (GPIO9/SPIHD)              = 0 R/W (0x0)
SPI_PAD_CONFIG_CS0     Override SD_CMD pad (GPIO11/SPICS0)               = 0 R/W (0x0)
DISABLE_SDIO_HOST      Disable SDIO host                                 = 0 R/W (0x0)

Identity fuses:
MAC                    MAC Address                                       
  = 30:ae:a4:02:59:c0 (CRC 9b OK) R/W 
CHIP_VER_REV1          Silicon Revision 1                                = 0 -/W (0x0)
CHIP_VERSION           Reserved for future chip versions                 = 0 -/W (0x0)
CHIP_PACKAGE           Chip package identifier                           = 0 -/W (0x0)

Calibration fuses:
BLK3_PART_RESERVE      BLOCK3 partially served for ADC calibration data  = 0 -/W (0x0)
ADC_VREF               Voltage reference calibration                     = 1100 -/W (0x0)

Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V).


    $ espefuse.py --port /dev/ttyUSB0 dump espefuse.py v2.3.1
Connecting......
EFUSE block 0:
00110080 a40259c0 009b30ae 00000000 00000036 f0000000 000003c4
EFUSE block 1:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
EFUSE block 2:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
EFUSE block 3:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  6. 上記 4. 初回暗号化完了後にあらためてプレーンな app イメージを esptool で書き込んで make monitor -- アプリの起動が適切に弾かれる 
    $ esptool.py --port /dev/ttyUSB0 --baud 921600 write_flash 0x10000 build/mySimpleApp.bin; make monitor
esptool.py v2.3.1
Connecting....
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 0)
Features: WiFi, BT, Dual Core
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 140160 bytes to 68713...
Wrote 140160 bytes (68713 compressed) at 0x00010000 in 1.5 seconds (effective 730.5 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
MONITOR
--- idf_monitor on /dev/ttyUSB0 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:7400
load:0x40078000,len:0
ho 12 tail 0 room 4
load:0x40078000,len:17796
entry 0x40078724
I (31) boot: ESP-IDF v3.1-dev-1171-g358c822 2nd stage bootloader
I (31) boot: compile time 16:28:39
I (31) boot: Enabling RNG early entropy source...
I (37) boot: SPI Speed      : 40MHz
I (41) boot: SPI Mode       : DIO
I (45) boot: SPI Flash Size : 4MB
I (49) boot: Partition Table:
I (52) boot: ## Label            Usage          Type ST Offset   Length
I (60) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (67) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (75) boot:  2 factory          factory app      00 00 00010000 00100000
I (82) boot: End of partition table
E (86) esp_image: image at 0x10000 has invalid magic byte
W (92) esp_image: image at 0x10000 has invalid SPI mode 255
E (99) boot: Factory app partition is not bootable
E (104) boot: No bootable app partitions in the partition table
user code done
    前掲のドキュメント記述のように「flash read err, 1000」のエラー出力とリブートのループを予想したがここではこのように「boot: Factory app partition is not bootable」の表示で停止した。このあたりの事情はまだよくわからない
    動画 E
  7. ここでソースコードに小さく変更を加える。メッセージにビックリマークを書き加えただけ
    変更前
    ESP_LOGI(TAG, "Flash Encryption is enabled");

    変更後
    ESP_LOGI(TAG, "Flash Encryption is enabled!!!!");

  8. make を経て PC 上で app イメージを暗号化し esptool でフラッシュメモリへ書き込むと期待通り上の変更が反映された状態で起動 
    $ make
CC build/main/mySimpleApp.o
AR build/main/libmain.a
LD build/mySimpleApp.elf
esptool.py v2.3.1
To flash all build output, run 'make flash' or:
python /home/t/esp/esp-idf/components/esptool_py/esptool/esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 115200 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 /home/t/Arduino/my/for_ESP-IDF/mySimpleApp/build/bootloader/bootloader.bin 0x10000 /home/t/Arduino/my/for_ESP-IDF/mySimpleApp/build/mySimpleApp.bin 0x8000 /home/t/Arduino/my/for_ESP-IDF/mySimpleApp/build/partitions_singleapp.bin

$ espsecure.py encrypt_flash_data --keyfile ./mykey.bin --address 0x10000 -o build/mySimpleApp_encrypted.bin build/mySimpleApp.bin
espsecure.py v2.3.1

$ esptool.py --port /dev/ttyUSB0 --baud 921600 write_flash 0x10000 build/mySimpleApp_encrypted.bin; make monitor
esptool.py v2.3.1
Connecting....
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 0)
Features: WiFi, BT, Dual Core
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 140176 bytes to 138083...
Wrote 140176 bytes (138083 compressed) at 0x00010000 in 2.2 seconds (effective 509.0 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
MONITOR
--- idf_monitor on /dev/ttyUSB0 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:7400
load:0x40078000,len:0
ho 12 tail 0 room 4
load:0x40078000,len:17796
entry 0x40078724
I (31) boot: ESP-IDF v3.1-dev-1171-g358c822 2nd stage bootloader
I (31) boot: compile time 16:28:39
I (31) boot: Enabling RNG early entropy source...
I (37) boot: SPI Speed      : 40MHz
I (41) boot: SPI Mode       : DIO
I (45) boot: SPI Flash Size : 4MB
I (49) boot: Partition Table:
I (52) boot: ## Label            Usage          Type ST Offset   Length
I (60) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (67) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (75) boot:  2 factory          factory app      00 00 00010000 00100000
I (82) boot: End of partition table
I (86) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x0588c ( 22668) map
I (103) esp_image: segment 1: paddr=0x000158b4 vaddr=0x3ffb0000 size=0x02284 (  8836) load
I (108) esp_image: segment 2: paddr=0x00017b40 vaddr=0x40080000 size=0x00400 (  1024) load
0x40080000: _iram_start at /home/t/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

I (113) esp_image: segment 3: paddr=0x00017f48 vaddr=0x40080400 size=0x080c8 ( 32968) load
I (136) esp_image: segment 4: paddr=0x00020018 vaddr=0x400d0018 size=0x11ccc ( 72908) map
0x400d0018: _flash_cache_start at ??:?

I (163) esp_image: segment 5: paddr=0x00031cec vaddr=0x400884c8 size=0x0066c (  1644) load
0x400884c8: esp_rom_spiflash_program_page_internal at /home/t/esp/esp-idf/components/spi_flash/spi_flash_rom_patch.c:412

I (164) esp_image: segment 6: paddr=0x00032360 vaddr=0x400c0000 size=0x00000 (     0) load
I (175) boot: Loaded app from partition at offset 0x10000
I (175) boot: Checking flash encryption...
I (180) flash_encrypt: flash encryption is enabled (3 plaintext flashes left)
I (188) boot: Disabling RNG early entropy source...
I (194) cpu_start: Pro cpu up.
I (197) cpu_start: Starting app cpu, entry point is 0x40080e4c
0x40080e4c: call_start_cpu1 at /home/t/esp/esp-idf/components/esp32/cpu_start.c:225

I (0) cpu_start: App cpu up.
I (208) heap_init: Initializing. RAM available for dynamic allocation:
I (215) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (221) heap_init: At 3FFB32C0 len 0002CD40 (179 KiB): DRAM
I (227) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (233) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (240) heap_init: At 40088B34 len 000174CC (93 KiB): IRAM
I (246) cpu_start: Pro cpu start user code
I (264) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (266) TAG: **** this is secret data ****
I (266) TAG: Flash Encryption is enabled!!!!
I (1266) TAG: Flash Encryption is enabled!!!!
I (2266) TAG: Flash Encryption is enabled!!!!
I (3266) TAG: Flash Encryption is enabled!!!!
I (4266) TAG: Flash Encryption is enabled!!!!
I (5266) TAG: Flash Encryption is enabled!!!!
I (6266) TAG: Flash Encryption is enabled!!!!
I (7266) TAG: Flash Encryption is enabled!!!!
I (8266) TAG: Flash Encryption is enabled!!!!
I (9266) TAG: Flash Encryption is enabled!!!!
    動画 F
これで FLASH_CRYPT_CNT を気にすることなく Flash Encryption を利用できるようになりました。

Arduino core for ESP32 環境ではどうする？等の実験と結果

ここまでは公式ドキュメントの記述を解釈しながら事前生成暗号化キーを使い ESP-IDF ベースで Flash Encryption の操作を行ってきました。より利用者の多い Arduino core for ESP32 環境での事情が気になります。現時点ではこの点に関する的確な情報が見当たらないため手元で調査と実験を行いました。

実験 1: Flash Encryption 有効状態でのバックアップ・レストアは可能？

前項までの確認の結果、現在手元には FLASH_CRYPT_CNT efuse の値が 0x01 の ESP32 ボードがある。ここにはアプリ「mySimpleApp」の本体のイメージをはじめ暗号化された一式が格納されている。

まず素朴に、この状態でフラッシュメモリ全領域のバックアップとレストアが可能であるか否かに関心を持った。 さっそく esptool を使い下記要領でバックアップとレストアを試したところ、Flash Encryption 不使用時と同様に問題なく処理できることを確認した。物理的な読み書きの際に間で細工をしたりはしないらしい。まずはひと安心。

esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0 0x400000 flash4MB.bin

esptool.py --port /dev/ttyUSB0 --baud 921600 write_flash 0 flash4MB.bin

実験 2: パーティションイメージを復号してみる

次に、esptool で読み出した所定の暗号化ずみパーティションを espsecure ユーティリティ の decrypt_flash_data コマンドで正しく復号可能であることを確認した。こういった整合性は一連の文脈の中で適切に保たれている。 以下は暗号化されたパーティションテーブルをホスト PC 上に読み出して復号する例。decrypt_flash_data コマンドにおいても --address 指定が必須であることに注意が必要。

esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x8000 0xc00 partition_table_Encrypted.bin

espsecure.py decrypt_flash_data --keyfile ./mykey.bin --address 0x8000 -o partition_table_plain.bin partiiion_table_Encrypted.bin

なお、サイズ不定のブートローダーについては、プロジェクトのビルド時に build/bootloader/ 下に生成された暗号化前の bootloader.bin のファイルサイズ（ここでは 25,296 バイト）を指定して暗号化イメージを採取。上記と同じ要領で復号可能だった。

esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x1000 25296 bootloader_Encrypted.bin

espsecure.py decrypt_flash_data --keyfile ./mykey.bin --address 0x1000 -o bootloader_plain.bin bootloader_Encrypted.bin

実験 3: 全パーティションのイメージを採取・復号・再暗号化して書き戻すと？

上のようにパーティションテーブルとブートローダのイメージの取得と復号の確認を終えたところで、他のパーティションイメージもすべて採取し、適宜復号と再暗号化を行った上で ESP32 へ書き戻してやれば普通にプログラムが動作するのではないかと考え実際に手を動かして試してみた。

まずパーティション定義を参照し各パーティションイメージを個別に採取する。 

# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0x6000,
phy_init, data, phy,     0xf000,  0x1000,
factory,  app,  factory, 0x10000, 1M,

前掲のように nvs は暗号化されておらず、読み出し不可の phy は中身がすべて 0xFF だった。後者はいずれにせよ mySimpleApp では使用していないためひとまずこのままにしておく。Type = app の factory パーティションについてのみ復号を行った。実行したコマンドを以下に控える。

esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x9000 0x6000 nvs.bin
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0xf000 0x1000 phy_init.bin
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x10000 0x100000 factory_Encrypted.bin

espsecure.py decrypt_flash_data --keyfile ./mykey.bin --address 0x10000 -o factory_plain.bin factory_Encrypted.bin

次に、復号したブートローダ, パーティションテーブル, factory パーティションをあらためて暗号化する。

espsecure.py encrypt_flash_data --keyfile ./mykey.bin --address 0x1000 -o bootloader_reEncrypted.bin bootloader_plain.bin
espsecure.py encrypt_flash_data --keyfile ./mykey.bin --address 0x8000 -o partition_table_reEncrypted.bin partition_table_plain.bin
espsecure.py encrypt_flash_data --keyfile ./mykey.bin --address 0x10000 -o factory_reEncrypted.bin factory_plain.bin

準備を終えた一式を下記コマンドでフラッシュメモリへ書き戻した。

esptool.py --port /dev/ttyUSB0 --baud 921600 write_flash \
    0x1000 bootloader_reEncrypted.bin \
    0x8000 partition_table_reEncrypted.bin \
    0x9000 nvs.bin \
    0xf000 phy_init.bin \
    0x10000 factory_reEncrypted.bin

この結果、アプリケーション mySimpleApp は問題なく動作した。当初複雑に感じられた Flash Encryption は案外素直な構造らしい。

実験 4: Arduino core for ESP32 環境で開発したアプリ一式を移行してみる

ここまでの結果に続けて、ESP-IDF ではなく Arduino core for ESP32 環境でビルドしたアプリケーションイメージ一式について Flash Encryption 環境での取り回しを試みた。

実験用の題材として Arduino IDE 環境で直近に作成した Google Home に発話させるエージェントプログラムを使った。アプリ内で SPIFFS を利用していることも実験を行う上で何となく好都合。パーティションテーブルは以下の内容。 

# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0x5000,
otadata,  data, ota,     0xe000,  0x2000,
app0,     app,  ota_0,   0x10000, 0x140000,
app1,     app,  ota_1,   0x150000,0x140000,
eeprom,   data, 0x99,    0x290000,0x1000,
spiffs,   data, spiffs,  0x291000,0x16F000,

手元では同アプリを Flash Encryption を適用していない素の ESP32 ボードで運用中。

まず、この非 Flash Encryption なボード A をホスト PC へ接続し、フラッシュメモリからパーティションイメージ一式を採取する。

esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x9000 0x5000 nvs.bin
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0xe000 0x2000 otadata.bin
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x10000 0x140000 app0.bin
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x150000 0x140000 app1.bin
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x290000 0x1000 eeprom.bin
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x291000 0x16F000 spiffs.bin

esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x8000 0xC00 partition_table.bin

ブートローダはサイズ不定だが、Arduino core for ESP32 の場合、[arduino]/hardware/espressif/esp32/tools/sdk/bin/ ディレクトリ下に SPI モード + Flash Frequency 別に用意されているためこれを利用できる。 

$ pwd
/home/t/app/arduino-1.8.5/hardware/espressif/esp32/tools/sdk/bin
$ ls -l
合計 128
-rw-rw-r-- 1 t t 15088  7月 30 21:42 bootloader_dio_40m.bin
-rw-rw-r-- 1 t t 13696  7月 30 21:42 bootloader_dio_80m.bin
-rw-rw-r-- 1 t t 13696  7月 30 21:42 bootloader_dout_40m.bin
-rw-rw-r-- 1 t t 13696  7月 30 21:42 bootloader_dout_80m.bin
-rw-rw-r-- 1 t t 15088  7月 30 21:42 bootloader_qio_40m.bin
-rw-rw-r-- 1 t t 15072  7月 30 21:42 bootloader_qio_80m.bin
-rw-rw-r-- 1 t t 15088  7月 30 21:42 bootloader_qout_40m.bin
-rw-rw-r-- 1 t t 15072  7月 30 21:42 bootloader_qout_80m.bin

本アプリは "QIO" + "80MHz" の指定でビルドしているため「bootloader_qio_80m.bin」をコピーして使う。

  

暗号化の対象であるブートローダー, パーティションテーブル および app0, app1 パーティションのイメージを Flash Encryption 適用ずみの ESP32 ボード B のキーを使って暗号化する。

espsecure.py encrypt_flash_data --keyfile ./mykey.bin --address 0x1000 -o bootloader_Encrypted.bin bootloader_qio_80m.bin
espsecure.py encrypt_flash_data --keyfile ./mykey.bin --address 0x8000 -o partition_table_Encrypted.bin partition_table.bin
espsecure.py encrypt_flash_data --keyfile ./mykey.bin --address 0x10000 -o app0_Encrypted.bin app0.bin
espsecure.py encrypt_flash_data --keyfile ./mykey.bin --address 0x150000 -o app1_Encrypted.bin app1.bin

ここで Flash Encryption 適用ずみの ESP32 ボード B をホスト PC につなぎ替えてから、以下の要領で各パーティションイメージを書き込む。

esptool.py --port /dev/ttyUSB0 --baud 921600 write_flash \
    0x1000 bootloader_Encrypted.bin \
    0x8000 partition_table_Encrypted.bin \
    0x9000 nvs.bin \
    0xe000 otadata.bin \
    0x10000 app0_Encrypted.bin \
    0x150000 app1_Encrypted.bin \
    0x290000 eeprom.bin \
    0x291000 spiffs.bin

以上の手順により、Arduino core for ESP32 環境でビルドを行い素の ESP32 ボード A 上で稼働中の当該アプリが、Flash Encryption 適用ずみのボード B 上で正常に動作した。

Flash Encryption を道具として普段使いするために

上の結果を受けて、Flash Encryption を道具として日常的に利用する上でのポイントを想定した。

  • あらかじめ「初回の暗号化」を経て FLASH_CRYPT_CNT ＝ 0x01 状態となったボードを資材として用意しておく
  • 普段は素のボートを使って Arduino IDE 環境なり ESP-IDF 環境なりで普通にプログラム開発を行う
  • 自分の手を離れた場所にボードを設置する場合は上の要領で素のボードから Flash Encryption 有効化ずみボードへイメージを移行して利用する 
       ESP32 Board A                         ESP32 Board B
+------------------+  copy & encrypt  +------------------+
| Flash Encryption | partition images | Flash Encryption |
|     DISABLED     | ===============> |     ENABLED      | 
+------------------+                  +------------------+

理屈がわかってしまえば移行方法そのものは単純だが、手順が面倒なので適切に一括操作を行うために Python スクリプトを用意した。Linux, MacOSX, Windows の各環境に対応。なお、前項の実験ではブートローダのイメージを SDK ディレクトリからコピーして利用したが、ブートローダコードは固定長ではないもののサイズの上限は 0x7000 バイトであり、素のボードのフラッシュメモリオフセット 0x1000 から 0x7000 バイト分を読み出して処理したところ問題なく動作したためこの方法を採った。これなら元アプリの開発環境が何であるかにかかわらず対応できる。

  1. Flash Encryption の無効なボード A のフラッシュメモリからブートローダイメージをホスト PC へ採取
  2. 同じくパーティションテーブルイメージを採取
  3. 上のパーティションテーブルの内容に基づき各パーティションイメージを採取
  4. 暗号化の必要なイメージを Flash Encryption の有効なボード B 用のキーで暗号化する
  5. イメージ一式をボード B のフラッシュメモリへ書き込む

以下の動画はこのスクリプトを使って前掲の「Google Home に発話させるエージェントプログラム」を稼働させている素のボード A のフラッシュメモリパーティションイメージ一式を暗号化有効なボード B へ移行した様子。

前半： 素のボード A のフラッシュメモリからの各パーティションイメージ採取と暗号化完了まで

後半： 上のイメージを Flash Encryption の有効なボード B に書き込んで当該アプリの稼働を確認

残っている疑問

今回、所定のボードで Flash Encryption を有効化するまでの過程ではドキュメントの内容どおりに ESP-IDF 環境で make menuconfig での暗号化オプション有効化を経て make && make flash を実行する手順を踏んだが、ボード側のお膳立てとしては FLASH_CRYPT_CNT efuse の値を 0x01 にするだけで事足りる可能性も想像される。

もし仮にそうであれば、素の状態のボードに対し事前生成暗号化キーを書き込んだ上で 前掲のように「espefuse.py --port [PORT] burn_efuse FLASH_CRYPT_CNT」コマンドを一度発行するだけで準備 OK かもしれない。手元ではまだ試せていないが関心はある。この件もおって確認したい。

以上、長いメモでした。いろいろ興味深い機構です。

(tanabe)

付記：「残っている疑問」についての追実験 （2018-11-08）

先だって上の「残っている疑問」の項に次のように書き残した。

ボード側のお膳立てとしては FLASH_CRYPT_CNT efuse の値を 0x01 にするだけで事足りる可能性も想像される。

その後手元で検証用の ESP32 ボードを確保した事情もあり、ここまでの話題を失念する前に追実験を行うことにした。以下に結論を示す。

以下の条件を満たせば ボード側の準備が完了する。 この状態であれば、PC 上で所定の事前生成キーにより暗号化したパーティションイメージを esptool で書き込んでそのまま実行することが可能。ESP-IDF を経由する必要はない。なお FLASH_CRYPT_CNT の操作だけでは不可。

  • FLASH_CRYPT_CNT の ON ビット数が 1 (0x01) など奇数であること
    espefuse.py --port /dev/ttyUSB0 burn_efuse FLASH_CRYPT_CNT
  • FLASH_CRYPT_CONFIG の値が 15 (0xF) であること
    espefuse.py --port /dev/ttyUSB0 burn_efuse FLASH_CRYPT_CONFIG 15
  • PC 上で生成した事前暗号化キーを正しく書き込みずみであること
    espefuse.py --port /dev/ttyUSB0 burn_key flash_encryption ./mykey.bin

以下は今回手元で実験に使ったボードでの espefuse.py summary の結果。

まず出荷時の素の状態。 （ちなみにここで使用しているボードは ESP32-DevKitC ではなく ROM BASIC が最初から無効状態のもの） 

$ espefuse.py summary

Security fuses:
FLASH_CRYPT_CNT        Flash encryption mode counter                     = 0 R/W (0x0)
FLASH_CRYPT_CONFIG     Flash encryption config (key tweak bits)          = 0 R/W (0x0)
CONSOLE_DEBUG_DISABLE  Disable ROM BASIC interpreter fallback            = 1 R/W (0x1)
ABS_DONE_0             secure boot enabled for bootloader                = 0 R/W (0x0)
ABS_DONE_1             secure boot abstract 1 locked                     = 0 R/W (0x0)
JTAG_DISABLE           Disable JTAG                                      = 0 R/W (0x0)
DISABLE_DL_ENCRYPT     Disable flash encryption in UART bootloader       = 0 R/W (0x0)
DISABLE_DL_DECRYPT     Disable flash decryption in UART bootloader       = 0 R/W (0x0)
DISABLE_DL_CACHE       Disable flash cache in UART bootloader            = 0 R/W (0x0)
BLK1                   Flash encryption key                              
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W 
BLK2                   Secure boot key                                   
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W 
BLK3                   Variable Block 3                                  
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W 

Efuse fuses:
WR_DIS                 Efuse write disable mask                          = 0 R/W (0x0)
RD_DIS                 Efuse read disablemask                            = 0 R/W (0x0)
CODING_SCHEME          Efuse variable block length scheme                = 0 R/W (0x0)
KEY_STATUS             Usage of efuse block 3 (reserved)                 = 0 R/W (0x0)

Config fuses:
XPD_SDIO_FORCE         Ignore MTDI pin (GPIO12) for VDD_SDIO on reset    = 0 R/W (0x0)
XPD_SDIO_REG           If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset   = 0 R/W (0x0)
XPD_SDIO_TIEH          If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V   = 0 R/W (0x0)
SPI_PAD_CONFIG_CLK     Override SD_CLK pad (GPIO6/SPICLK)                = 0 R/W (0x0)
SPI_PAD_CONFIG_Q       Override SD_DATA_0 pad (GPIO7/SPIQ)               = 0 R/W (0x0)
SPI_PAD_CONFIG_D       Override SD_DATA_1 pad (GPIO8/SPID)               = 0 R/W (0x0)
SPI_PAD_CONFIG_HD      Override SD_DATA_2 pad (GPIO9/SPIHD)              = 0 R/W (0x0)
SPI_PAD_CONFIG_CS0     Override SD_CMD pad (GPIO11/SPICS0)               = 0 R/W (0x0)
DISABLE_SDIO_HOST      Disable SDIO host                                 = 0 R/W (0x0)

Identity fuses:
MAC                    MAC Address                                       
  = 24:0a:c4:9a:56:b0 (CRC 4d OK) R/W 
CHIP_VER_REV1          Silicon Revision 1                                = 1 R/W (0x1)
CHIP_VERSION           Reserved for future chip versions                 = 2 R/W (0x2)
CHIP_PACKAGE           Chip package identifier                           = 0 R/W (0x0)

Calibration fuses:
BLK3_PART_RESERVE      BLOCK3 partially served for ADC calibration data  = 0 R/W (0x0)
ADC_VREF               Voltage reference calibration                     = 1100 R/W (0x10)

Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V).

前述の三条件を満たした状態。暗号化キーを書き込んだ結果「BLK1 Flash encryption key」項の「BLK1」が「R/W」から「-/-」に変化している点に注意 

$ espefuse.py summary

Security fuses:
FLASH_CRYPT_CNT        Flash encryption mode counter                     = 1 R/W (0x1)
FLASH_CRYPT_CONFIG     Flash encryption config (key tweak bits)          = 15 R/W (0xf)
CONSOLE_DEBUG_DISABLE  Disable ROM BASIC interpreter fallback            = 1 R/W (0x1)
ABS_DONE_0             secure boot enabled for bootloader                = 0 R/W (0x0)
ABS_DONE_1             secure boot abstract 1 locked                     = 0 R/W (0x0)
JTAG_DISABLE           Disable JTAG                                      = 0 R/W (0x0)
DISABLE_DL_ENCRYPT     Disable flash encryption in UART bootloader       = 0 R/W (0x0)
DISABLE_DL_DECRYPT     Disable flash decryption in UART bootloader       = 0 R/W (0x0)
DISABLE_DL_CACHE       Disable flash cache in UART bootloader            = 0 R/W (0x0)
BLK1                   Flash encryption key                              
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -/- 
BLK2                   Secure boot key                                   
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W 
BLK3                   Variable Block 3                                  
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W 

Efuse fuses:
WR_DIS                 Efuse write disable mask                          = 128 R/W (0x80)
RD_DIS                 Efuse read disablemask                            = 1 R/W (0x1)
CODING_SCHEME          Efuse variable block length scheme                = 0 R/W (0x0)
KEY_STATUS             Usage of efuse block 3 (reserved)                 = 0 R/W (0x0)

Config fuses:
XPD_SDIO_FORCE         Ignore MTDI pin (GPIO12) for VDD_SDIO on reset    = 0 R/W (0x0)
XPD_SDIO_REG           If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset   = 0 R/W (0x0)
XPD_SDIO_TIEH          If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V   = 0 R/W (0x0)
SPI_PAD_CONFIG_CLK     Override SD_CLK pad (GPIO6/SPICLK)                = 0 R/W (0x0)
SPI_PAD_CONFIG_Q       Override SD_DATA_0 pad (GPIO7/SPIQ)               = 0 R/W (0x0)
SPI_PAD_CONFIG_D       Override SD_DATA_1 pad (GPIO8/SPID)               = 0 R/W (0x0)
SPI_PAD_CONFIG_HD      Override SD_DATA_2 pad (GPIO9/SPIHD)              = 0 R/W (0x0)
SPI_PAD_CONFIG_CS0     Override SD_CMD pad (GPIO11/SPICS0)               = 0 R/W (0x0)
DISABLE_SDIO_HOST      Disable SDIO host                                 = 0 R/W (0x0)

Identity fuses:
MAC                    MAC Address                                       
  = 24:0a:c4:9a:56:b0 (CRC 4d OK) R/W 
CHIP_VER_REV1          Silicon Revision 1                                = 1 -/W (0x1)
CHIP_VERSION           Reserved for future chip versions                 = 2 -/W (0x2)
CHIP_PACKAGE           Chip package identifier                           = 0 -/W (0x0)

Calibration fuses:
BLK3_PART_RESERVE      BLOCK3 partially served for ADC calibration data  = 0 -/W (0x0)
ADC_VREF               Voltage reference calibration                     = 1100 -/W (0x10)

Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V).

事前暗号化キーの書き込みと FLASH_CRYPT_CNT の設定だけでは不可であり FLASH_CRYPT_CONFIG の設定も必要だった。

これで事情がわかったため今後はより手早くボードの暗号化設定を行うことが可能となった。

この狭い狭い情報がほかの誰かの役に立つ機会があるかどうかはわかりませんが、ひとまず自分用にメモしておくことにしました。

(tanabe)
klab_gijutsu2 at 19:32
｜この記事のURL│Comments(0)│IoT 
Blog内検索
最新記事
Go のライトバリアに関するバグを修正した話
Google Assistant Service プログラミング事始め
Google Assistant Library プログラミングを楽しむ
ISUCON 8 予選で惨敗しました（リュウグウ）
ESP32 モジュールのフラッシュメモリ暗号化機構に関するメモ
Google Home でローカルの MP3 ファイルをプレイリスト再生する方法
Google Home を拠点間の双方向コミュニケーションに利用する
最近のPython-dev(2018-06)
SwitchBot を ESP32 で遠隔操作してみた
最近のPython-dev(2018-04)
電波法適合の NFC モジュールで安価な NFC タグを利用する
LVSの高負荷対策 その3 〜drop entryのサービスへの影響について〜
Archives
このブログについて
DSASとは、KLab が構築し運用しているコンテンツサービス用のLinuxベースのインフラです。現在5ヶ所のデータセンタにて構築し、運用していますが、我々はDSASをより使いやすく、より安全に、そしてより省力で運用できることを目指して、日々改良に勤しんでいます。
このブログでは、そんな DSAS で使っている技術の紹介や、実験してみた結果の報告、トラブルに巻き込まれた時の経験談など、広く深く、色々な話題を織りまぜて紹介していきたいと思います。
最新コメント
最新トラックバック
ZenFone3 で撮影した写真ファイル内の、位置情報が壊れている Exif データを修復するコードを書いてみた (仙石浩明の日記)
Exif データにアクセスするコードを自作してみる
無線マイコンの使い方(TWE-LITE)無線マイコンとは編 (NOBのArduino日記！)
「TWE-LITE」ファームウェアプログラミングの試み
PHPで携帯キャリアのIPアドレス帯域を求める (ぱふぅ家のホームページ)
携帯ゲートウェイのIPアドレス帯更新を効率的に確認する方法
PHPで携帯キャリアのIPアドレス帯域を求める (ぱふぅ家のホームページ)
携帯ゲートウェイのIPアドレス帯更新を効率的に確認する方法
証明書をサーバに設定する前にチェックする (パソコン鳥のブログ)
システム管理者の心得？ 〜 OpenSSLコマンドで証明書をチェック
Syndicate this site