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 は以下の値です。
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にするように記述しました。
さて、準備はできましたので、前回と同じくunionfsの起動スクリプトを入れて起動しました。…ハングアップしました。
調べると、bin〜をbindマウントして、古いのをunmountしたあたりです。
問題を順に対処していきましょう。
rootfsは400MB未満というコンパクトさ。rootfsとして、1GBもあれば十分でしょう。
イメージファイルとして、バックアップをとっておきましょう。
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を通してファイル転送速度を調べると、
さて、opensslのスピードの続きです。
http://datko.net/2014/03/21/bbb_upgrade_3_13/
の情報によると、kernel 3.13以降はHW暗号エンジンがデフォルトらしいです。…さっきインストールした3.8.18って何? 古すぎっ。
で、そこにあるようにkernel updateを、ついでに、RCじゃない最新版まで引き上げましょう。
さて、正しいkernelのアップデートはどうするかというと、DebianなんだからDebian流にやればよいのです。
なので、結局、ハードウェアの暗号化エンジンを使っているのかどうかわかりませんでした。
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-cbcRaspberryPiのときは、以下の値で、BBBは2倍速いです。
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
# openssl speed aes-256-cbcさて、BBBの、この約30000kという値、ハードウェアの暗号化エンジンを使っているのでしょうか? ここで、opensslのスピード測定のバグの問題にぶつかってしまうのです。たとえば、次のページ
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
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)その他、openvpnなどの設定は、RaspberryPiでの設定をコピーしてインストールします。これらは変更なしです。
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:yy:zz:uu:vv:ww", NAME="eth1"
さて、準備はできましたので、前回と同じく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
rootfsは400MB未満というコンパクトさ。rootfsとして、1GBもあれば十分でしょう。
イメージファイルとして、バックアップをとっておきましょう。
dd if=/dev/sdX of=SD.img count=YYYYYYYYYYは、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 (以前の結果)となり、約2.3倍の速度が出ていました。
BeagleBoneBlack 2.5MB/s
さて、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]ですと。BeagleBoneBlackの情報はあまりにも早く、むしろ早すぎるくらいに、情報が古くなります。私がここに書いたものも、もう既に古くなっていることでしょう。
Please use:
cd /opt/script/tools/
git pull
sudo ./update_kernel.sh
or:
sudo ./update_kernel.sh --kernel v3.x.x-x
さて、正しい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
なので、結局、ハードウェアの暗号化エンジンを使っているのかどうかわかりませんでした。
