So-net無料ブログ作成

RaspberryPiをBeagleBoneBlackに置き換える [プログラム]

BeagleBoneBlackはRev.A6のころに買っていて、あれこれと予定していたのですが、設置までは至りませんでした。
BeagleBonleBlackのCPUには、ハードウェアの暗号化エンジンが載っており、これがデフォルトで使えそうなので、試してみました。
以前、RaspberryPiで、無線LAN間をOpenVPNのサーバ・クライアントで結ぶものを作りました。残念ながら非力なRaspberryPiでは、10Mbps程度の速度しか出ませんでしたが、ハードウェアの暗号化エンジンを使ってどれだけ速くなるでしょうか?

…と思ったのですが,結論からいいますと、ハードウェアの暗号化エンジンを使っているのかどうかも分からないような結果となりました。これは、元々opensslのスピード測定部分にバグがあり、測定時間が3秒どころか0.0何秒になってしまい、測定結果が不正確すぎる値しかでてこない、と言う問題がありました(現在は直っています)。ネット上にある多くの測定結果は、そのときのバグありバージョンで測定されているものですから、元々の「本当の速度」が分からないのでした。


では、順番に。
まず、予備調査として、openssl speedコマンドでそれぞれ速度を測ってみました。

BeagleBoneBlackのwheezyのプレビルドのSDイメージ(stable; console版)を使いました。BegleBoardDebian(http://elinux.org/BeagleBoardDebian)からです。
カーネルは、Linux 3.8.13-bone67 #1 でした。
openssl speed aes-256-cbc は以下の値です。
$ openssl speed aes-256-cbc
Doing aes-256 cbc for 3s on 16 size blocks: 4933445 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 64 size blocks: 1425060 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 256 size blocks: 373241 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 1024 size blocks: 94438 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 8192 size blocks: 11855 aes-256 cbc's in 3.00s
OpenSSL 1.0.1e 11 Feb 2013
built on: Wed Oct 15 18:31:51 UTC 2014
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      26311.71k    30502.96k    31849.90k    32342.65k    32372.05k
RaspberryPiのときは、以下の値で、BBBは2倍速いです。
# openssl speed aes-256-cbc
Doing aes-256 cbc for 3s on 16 size blocks: 2262500 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 64 size blocks: 682967 aes-256 cbc's in 2.98s
Doing aes-256 cbc for 3s on 256 size blocks: 179207 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 1024 size blocks: 45360 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 8192 size blocks: 5680 aes-256 cbc's in 2.98s
OpenSSL 1.0.1c 10 May 2012
built on: Thu Nov  8 03:42:28 UTC 2012
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      12066.67k    14667.75k    15292.33k    15534.66k    15614.28k
さて、BBBの、この約30000kという値、ハードウェアの暗号化エンジンを使っているのでしょうか? ここで、opensslのスピード測定のバグの問題にぶつかってしまうのです。たとえば、次のページ
  http://processors.wiki.ti.com/index.php/Sitara_Device_Crypto_Performance_Comparison
なら、ハードウェアの暗号化エンジンなしで約8000kですが、実はRaspberryPi(15000k)よりも遅いです。半分の速度しか出ていません。これはどうしたことでしょう? CPUのクロック差からして、これはgccやOSのバージョンによる差と考えなければなりません。となると、gccやOSのバージョンが上がると、2〜4倍程度は速くなる可能性がある、ということでしょうか? それも十分考えられます。
ハードウェアの暗号化エンジンを使った場合は、opensslのスピード測定のバグの問題のため、不正確な値しかでていません。なので、実際の速度がどれだけなのか、まったく分かりません。困ったものです。

しかしながら、現行のRaspberryPiの2倍の速度というのは、それなりに魅力的です。なので、ともかく一度BeagleBoneBlackで置き換えてしまいましょう。昨年大問題となったopensslのheartbleed脆弱性のこともありますし。(ただ、このopenvpnTLS-Authを使っていますので問題ありませんでした。攻撃者にTLS-Authキーが知られない限りheartbleedバグを利用することができませんので。)

基本的な方針はRaspberryPiのときと同じです。そして、発生した問題も同じでした(他にもありますが)。

rootfsをROM化するために、fsprotectをapt-getしましたが、相変わらずaufsが使えないため、fsprotectが動作しません。x86版ならサポートされているのに、armはダメです。でも、「必要性」から言えば,PCのx86よりも、小型組込み用のarmのほうが比べ物にならないくらい「必要」としているのですがね。
fsprotectを諦めて、やはり、unionfsを使うことになります。

それから、USB-Etherアダプタが"ethX"じゃなくて、"rename3"になっていました。これはASIXのチップを使ったものです。
"rename3"のまま使用しても構わなかったのですが、まぁ、ちょっと直しましょう。
/etc/udev/rules.d/70-...が悪いのは分かっていますが、どう書くのでしたっけか?
ググってみますと(rename3 ASIX)と同じ目にあわされている人が何人かいて、結局、MACアドレスでeth1にするように記述しました。
# USB device ASIX (AX88x72A)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:yy:zz:uu:vv:ww", NAME="eth1"
その他、openvpnなどの設定は、RaspberryPiでの設定をコピーしてインストールします。これらは変更なしです。

さて、準備はできましたので、前回と同じくunionfsの起動スクリプトを入れて起動しました。…ハングアップしました。
調べると、bin〜をbindマウントして、古いのをunmountしたあたりです。

問題を順に対処していきましょう。
  • ifconfig -aしても、ethが出てきません
    他に何かしたら、D-Busかなにかがないというエラーがでました。
    /sysや/procを「新たにmount」するのはもはやダメらしいです。以前mountしたfsと関係なく、その時点で新しいfsがマウントされてしまうようです。セキュリティのためではないかと思います。よって、以前のものをbindマウントする必要があります。
      mount -t proc proc /proc -> mount --bind 以前 /proc など

  • シリアルコンソールからログアウトすると、シリアルがハングアップします(正確には,gettyが再実行されません)
    明らかに、rootfsを移動したことに問題があるわけですが、どこに問題があったのかわかりませんでした。
    でも、kill -1 1すればgettyが動くことがわかったのですが、…
    結局,直せませんでした。systemdの設定や構造は未だ理解不能です。(/etc/inittabはsystemdでも解釈されるのか?、とか)
    とりあえず、rootの.bash_logoutに
      ( sleep 3; kill -1 1 ) &
    を追加。…、嫌になるくらいひどすぎる回避策ですが、この場合は、動くことが大事であって、無理にでも動けばOKです。

  • カーネル起動パラメータからquietを削除すると、コンソールがハングします
    これもひょっとするとkill -1 1で直るのかもしれません(試していません)が、いずれにしても原因が不明です。messagesの出力のためにconsoleがオープンされたままrootが移動するから?でしょうか。
ともあれ、これでなんとか動き始めました。が、さらに調整が必要でした。
  • もし、sshサーバを動かしているなら、一度再起動したあと、元々のrootfsの /etc/ssh/ssh.regenerate を削除しましょう。
    でないと、毎回起動時にhostkeyが再生成されて、「前回と違うhostkeyだ」と言われてしまいます。
      /bin/rm -f etc/ssh/ssh.regenerate
SDが出来上がったので,PCにSDをもってきて、PCのgpartedでパーティションサイズを変更します。保存やコピーのサイズや時間の節約のためです。
rootfsは400MB未満というコンパクトさ。rootfsとして、1GBもあれば十分でしょう。

イメージファイルとして、バックアップをとっておきましょう。
dd if=/dev/sdX of=SD.img count=YYYYY
YYYYYは、fdiskなどを用いて、(使用しているパーティションの最後のセクタ番号+100)程度を指定します。

BeagleBoneBlackは、eMMCがついています。SDの内容をeMMCに書き込みます。rootfsをROM化してあるので、SD同様、心配無用です。
このバージョンのBBBのDebianでは、eMMCへの書き込みはuEnv.txtを1行修正するだけです。それで起動すると、書き込まれます。終了は、コンソールで確認するか、LED4つが全部点灯するかでわかります。SDを抜いて、電源を入れ直します。電源を入れ直さなければならない理由はCPUがそうなっているからです。BBBのCPUは、リセットではsysconfig(起動デバイス順序)を読み直しません。電源on時のみsysconfigを読み直すので、リセットすると、SDから起動しようとしてSDがないのでコンソールからの起動になり、eMMCを読みにいきません。

で、今まで設置していたRaspberryPiと入れ替えました(相手側はRaspberryPiのままです)。起動したら、そのまま問題なく動作しました。
あとは、同様にして無線ルータの相手側もBeagleBoneBlackに入れ替えます。

これで、当初の目的は達成できました。
実際に、openvpnと無線LANを通してファイル転送速度を調べると、
RaspberryPi        1.1MB/s (以前の結果)
BeagleBoneBlack    2.5MB/s
となり、約2.3倍の速度が出ていました。


さて、opensslのスピードの続きです。
  http://datko.net/2014/03/21/bbb_upgrade_3_13/
の情報によると、kernel 3.13以降はHW暗号エンジンがデフォルトらしいです。…さっきインストールした3.8.18って何? 古すぎっ。
で、そこにあるようにkernel updateを、ついでに、RCじゃない最新版まで引き上げましょう。
wget https://rcn-ee.net/deb/wheezy-armhf/v3.18.2-bone1/install-me.sh
chmod +x install-me.sh
./install-me.sh
したら、
Error: this script is no longer supported for [repos.rcn-ee.net]
Please use:
cd /opt/script/tools/
git pull
sudo ./update_kernel.sh
or:
sudo ./update_kernel.sh --kernel v3.x.x-x
ですと。BeagleBoneBlackの情報はあまりにも早く、むしろ早すぎるくらいに、情報が古くなります。私がここに書いたものも、もう既に古くなっていることでしょう。
さて、正しいkernelのアップデートはどうするかというと、DebianなんだからDebian流にやればよいのです。
apt-cache search linux-image
ここに3.19のRCまでありました。でも、念のため、3.18.2を入れます。
apt-get install linux-image-3.18.2-bone1
再起動して、早速測定。
openssl speed aes-256-cbc
Doing aes-256 cbc for 3s on 16 size blocks: 4963187 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 64 size blocks: 1432710 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 256 size blocks: 375715 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 1024 size blocks: 95073 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 8192 size blocks: 11910 aes-256 cbc's in 3.00s
OpenSSL 1.0.1e 11 Feb 2013
built on: Thu Jan  8 22:02:29 UTC 2015
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa, --noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      26470.33k    30564.48k    32061.01k    32560.12k    32522.24k
全然変わってません。
なので、結局、ハードウェアの暗号化エンジンを使っているのかどうかわかりませんでした。

共通テーマ:パソコン・インターネット