今日の発見

昨日と一昨日で、ぐぐっと研究が進んだので、今日はのんびり。
荷物を減らしてウエストポーチひとつにまとめ、自宅から一度多摩川に出て、いつものトレーニングコースを 15km 走り、調布までは戻らずに、天文台の脇を登って職場へ向かうルート。
それで、自宅から職場までは電車と徒歩で 90 分、自転車でまっすぐだと 35 分なのだが、このルートでくると 90 分だということがわかった。電車は雨と荷物が多い時以外、全く役に立たないというか、そういう感じだ。

MacPorts on Snow Leopard: Take 2

Python26 port is now updated, so we can build and install without any hacks!
Things that I couldn’t build with MacPorts:
– screen
– osxutils (hmm, osxutils uses MacOSX10.4sdk ???)
– ncbi_tools
– gcc43
– libsdl
Things I could build successfully:
– coreutils, lv, lha
– ccache, boost, git, subversion
– ncftp, wget
– iverilog, gtkwave
– tgif, ImageMagick, ghostscript, gv, gqview
– a2ps, ptex
– gtk2, pidgin
– gnuplot, EMBOSS
– w3m

FIT ’09: Session 6C

[ よしみさん ]
なんか、発表順が大幅に変わってて、質疑応答だけきいた。すいません。
レーベンシュタイン距離を Cube で。SPARTAN-3 のクラスタ。
並列度がぐわーっと出るのが真ん中だけなので、キビシイそうです。この手の問題はみんなそうですが。
[ 差分法専用計算機におけるFPGA間時分割通信機構の遅延評価 ]
FPGA間の帯域と遅延。
差分法なのでシストリックアーキテクチャでやれる。メッシュネットワーク。
FDTD 電磁波伝搬問題, RB-SOR 熱伝導問題を解いてみた。
通信遅延の許容値とか、時分割した場合のそれとかを計算。時分割のスロット数は 32 とか、わりととれそう。
質問: FIFO がある場合とない場合で、待ち行列に入る順番が不確定になるから、性能はかわらない? 差分法なので、ちゃんとスケジュールできるわけで、問題ないです。もちろん、アプリケーションが異なれば、そのへんのスケジュールが問題になる可能性もあります。
[ 特定用途向け動的再構成回路の演算器精度最適化に関する研究 ]
テンプレートとして 32bit 精度の各再構成演算器の VHDL を食わせる。
あれ?これ整数なのか。むふー。
質問(宮本先生): 時分割になるから性能が落ちると思うんだけど、面積とかそのへんも含めてどうですか? 音声とか映像の許容性能の範囲に入ればよい。
質問(佐野先生): 精度とパイプライン段数と周波数のトレードオフがあるんじゃないかと思うのですが? いまのところ考えていません。
[ やまださん ]
スライス使用率 100% で笑いを取ってました。
質問 (宮本先生): MCS はどうやって計算してますか? 部分グラフの選び方は? MCS は、ちゃんとやるほど難しくないので、力ずくで解いています。部分グラフは、いくつかの制約を満たすようにやっている。
質問 (佐野先生): 動作周波数が低下した原因は MUX? それもあるけど、配線がしんどくなるのが原因。
[ マルチメディア応用ヘテロジニアス… ]
てゆか、FE-GA ですね。hetero だし粗粒度だし、メモリの使い方がキーなのでしょう。
[ システム実時間測定のための Lossless データ圧縮伸張方法 ]
組み込みソフトウェアの開発において、システムの挙動を観測できることは非常に有意義。
ハードウェア実装されたトレーサの生成するトレースデータを圧縮する。
ARM とか MIPS とか PPC とか SH にはそういう HW なトレーサがついていて、専用のピンからその情報をほとんどオーバーヘッドなしで取り出すことができる (知らなかった… かっこいいね)。
トレースデータの場合、時間を相対表現にすると、情報の頻度が高ければタイムスタンプの上位ビットがたくさん0になるので、run length 圧縮。
関数名に id をつけて、それもほげほげ。call/return は1ビット。
LZ 圧縮と同じくらいのスループットで、メモリや回路面積はだいぶ小さい。圧縮率は同程度。
まあ、半分にはなるんだけど、結局その大量のデータをどうするかが問題だそうです。

MacPorts on Snow Leopard

I’ve started to build my development environment on my MacBook, with freshly installed Snow Leopard.

The MacPorts installer distributed as a package at that time (version 1.7.1) didn’t support 64bit platform (now it supports with 1.8.0, I think), so we had to checkout the latest version from svn repos, as described in MacPorts guide.

I’ve got following error message while building Python 2.6 (as a dependency of gnome-doc-utils) with MacPorts 1.8.99 on my MacBook (MacOS X 10.6.0).

ld: warning: in Python.framework/Versions/2.6/Python, file is not of required architecture
Undefined symbols:
"_PyMac_Error", referenced from:
"_Py_Main", referenced from:
_main in python.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

And the Ticket 20284 on MacPorts discussion list helped me much… The patch is available there (But, this patch fails while staging Python into destroot.)

Another way is to build gnome-doc-utils with +python25 variant, if you aren’t interested in python 2.6. This enables to build gnome-doc-utils.

Things that I couldn’t build with MacPorts:
– screen
– osxutils (hmm, osxutils uses MacOSX10.4sdk ???)
– ncbi_tools
– gcc43

Things I could build successfully:
– coreutils, lv, lha
– ccache, boost, git, subversion
– ncftp, wget
– iverilog, gtkwave
– tgif, ImageMagick, ghostscript, gv, gqview
– a2ps, ptex
– gtk2, pidgin
– gnuplot, EMBOSS

Others:
– tuntaposx: see this entry.

FIT ’09: Session 4C

組み込み。
[ 多機能コンセントのスケジューリング機能による待機電力の削減 ]
多機能コンセント: PLC みたいなアイデアだけど、RFID タグをつかって通信する。
PLCと違うのは、家電に通信機能がついていて、コンセントと通信することが目的であって、コンセントについている制御ユニットどうしは Ethernet かなにかでつながっている。待機電力の削減とか、高齢者みまもりサービスとか、盗電防止とかが目的。
ラッチングリレー (切り替えの時だけぷちっと切れる) を使って電源を落とせる。多機能コンセントの消費電力は 0.7W.
ジリオン・ネットワークスという会社と組んでやっている。
質問 (山田さん): 周波数はどのくらいで動かしている? 数十メガヘルツで、ネットワークに対応するためにリアルタイム性が必要。
質問 (座長): ラッチングリレー使っているのに、0.7W はちょっと多いんじゃないかと思うんですが。PIC の動作周波数を下げるモードとかを使ったらどうか。
質問 (芝浦工大の先生): 待機電力のカットが目的であれば、常時動かしておくのではなくて間欠動作 (30分に一度起きるとか) にしたらどうかしら。通信のところの消費電力を評価に入れるべきではないかと思う。
質問 (わし): これ、電源の口ひとつについて一つ制御ユニットがあるの? まとめたほうがいいと思うんだが…
[ 長時間トレース技術を用いた組込みソフトウェア開発の効率向上に関する検討 ]
組み込みのデバッグはいろんな依存関係の問題 (タイミングとか) があって再現性が低く、大変。長時間トレースが取れれば、再現することなく解析をすることができる。
– ログが大きくなりすぎたら大変だから、データマイニングしよう。
– 外部記憶装置を使いたい。
– CPU に負荷をかけると、いろいろ状況がかわるので、よろしくない。
– 外部バスにデータを流して、外に logger をつなぐことにした。
「異常度」を数値化して、高負荷状態でもちゃんと記録できることを確認。
質問 (山田さん): 学習データを作るところが大変でない? なんかスクリプト一発で、一度やっちゃえば大丈夫だそうです。
[ 組込みシステムにおける通信のロバスト性向上に関する研究 ]
低コストのネットワークマイコンボードはいろいろな家電をネットワーク化するのに便利。でも、DoS とかには弱いよね。
今回は Ping flood を例にやってみた。
Echo request がきたときにアドレスを憶えておき、一定時間以内にもう一度来たら、それは捨てちゃう。
まー、家電はこれくらいでいいのかなあ… と思うが、どうなんでしょう。
[ 位置・姿勢制御可能な測域センサによる不整地移動ロボットの3次元環境計測 ]
アームの先に測域センサをつけて、ロボット周辺の正確な環境形状を取得する。
センサはレーザーレンジファインダ。北陽電気社 (URG-04LX )。最大 4m まで、100msec で一周ぐるっととれる。でも、一周ぐるっととるデータは 2次元だけなので、3次元に拡張する必要がある。そこで、これにモータをつけて、回転させながら使うのが一般的。
しかし、これでは深い溝などがあると、死角ができたりして、いまいちなので、アームに載せて動かすことで、前方斜め下方向もちゃんと見られたり、壁の向こうがわを見たり、階段の下側をのぞき込んだりできる。
階段の上り下りがちゃんと測定できることを確認。誤差評価とかもしており、下方向では5.5% 以下に収まっているので、走行可能であるかどうかを確認するには充分。
質問(さきほどの日立の方): 既存の手法と較べるとどれくらい改善したかという数字はある? 計ってはいないのだが、とりあえず目視ではうまくいけている感じ。
質問(座長): レーザが反射する・しないとかで、うまくいく・いかないというのはある? 表面が黒かったりするとよくない感じです。
質問(わし): アームをどうやって動かすかが鍵だと思いますが、なにかくふうは? いまは手動でやっているそうなので、これから考えるそうです。
これはすごくかっこいいぞ!!!!!!
[ 計測点群の補間に基づいたタイヤ空気圧モニタリングシステムの検討 ]
電源を使わずにタイヤ空気圧を監視するそうです。まじですか。
水晶振動子でやるのか。なるほどね。でも、温度補償とかが大変らしい。
圧力周波数・温度周波数・圧力値の3次元ベクトルをたくさん計測してB-splineで近似した保管係数を作り、圧力周波数と温度周波数から圧力を測れるようにする。ECU の小さいメモリでも計算できる手法を提案。浮動小数点演算も使わない。B-splineの基底関数は計算してテーブル引きにするが、そのままだと12kBもあるので、データの相似性 (対称性) を使って半分くらいに減らす。
質問(座長): 本文の 車載PC、ECU、マイコン の違いは? どれもECUのマイコンを指しています。
[ 音声認識の組込みシステム搭載での課題 ]
音声認識ソフト Julius を T-Engine に持って行ったらどうなるか、課題の整理と処理時間の比較。
Julius: オフラインではかなりの認識精度。PC でリアルタイム処理が可能。オープンソース。Unix で動くのや、Windows GUI などがある。IPAのプロジェクトで、奈良先端とかで作っている。
TRON はカーナビの 7 割くらいで、残りは VxWorks らしい。知らなかった…
– 処理能力とメモリの問題
– SH のコンパイラでは #pragma が使えない?
実行時間計るなら、プロファイリングくらいしてほしかった…

FIT ’09: Session 3P

[ 周波数領域での暗号モジュールの電力解析 ]
東北大。SASEBO使う。
対策としては、Masking (中間値をランダム化)、Hiding (相補式ロジックなどで電力を平均にしたり、ノイズ減を入れて消費電力をランダム化する)などがあるが、高コストだし、カスタムメイドなチップが必要。
EMC なフィルタなんかを入れて対策することはできないか? それには強いスペクトルよりも、漏洩防止に有効なスペクトルがどこにあるのか、を探すことが重要。
質問 (岩井さん): スペクトルはどうやって決まっていると考えられる? チップがそもそも出すものとか、寄生容量とか。基板にアクセスされると容量とかをいじられる可能性があるが、そこはがっちり固めればいい(銀行なんかのシステムではそうなっている)。
質問 (日立の方): 動作周波数を変えた場合はどうなる? 動作周波数を変えてみたが、同じような結果になった。チップのパッケージをむいてやると、すごく高いスペクトルまで出るが、普通はそうでもないので、パッケージがすでに強烈にフィルタとして効いている。
[ AESのハードウェア実装に対するテンプレート攻撃 ]
東北大 take II.
リファレンスデバイスが手に入ると、デバイスの事前情報が手に入るので攻撃が簡単になる。これが template attack.
CPA だと 1200 波形必要だが、Template attack では 130 波形でいける!
ラウンド鍵でも、5000:2400 とか、まあ、とにかくすごいね…
暗号に依存しきった世界ですが、はたして大丈夫だろうか。
質問: テンプレートを作る HW と、対象はまったく同じ HW? 同一基板です。
[ AES の実装方法の違いによる CPA の比較 ]
ハミング距離モデルとハミング重みモデルでは、HW実装の場合、前者が強いが、SW実装だと、逆になるっぽい。いずれにしてもソフトウェア実装の方がデータがとりにくそう。
質問 (東北大のひと): SW実装の場合はSRAMを使うとデータがとりやすくなると思うんだけど、BlockRAM でやっている? あと、PowerPC なんかは、パイプラインとか分岐のほうでずれたりしていない? メモリは全部内部。分岐なんかでずれている可能性はある。1サイクルずれちゃうとだめなので、ちょっと考えないとだめっぽいですね。
[ GPGPU を用いた暗号攻撃 ]
AES に対する brute force attack.
メモリの問題で鍵空間に制約。限られた鍵空間であれば、Corei7の 12倍くらい。
でも、この実装はCPU-GPU とか GPU-GPU の通信がいらないので、たくさん GPU があればlinearに速くなる。
質問: AES の実装はどうなってる? 大きな S-BOX を使えば shiftRows が減って、速くなりそうですが。ShiftRows は LUT を使ってるので充分速いんだけど、メモリが小さいので大きな S-BOX は難しいです。
[ SASEBO-Rを使用した電磁波解析と電力解析の比較 ]
電磁波解析は周辺環境の影響を受けやすい。
先行研究では磁界プローブが使われているが、デバイス近傍以外でも電源まわりの電磁波がとれそうな気がするので、より安価な手法でできないかを検討する。
電力解析ではシャント抵抗のところで電圧を測り、電磁波解析ではシャント抵抗に導線を巻き付けて漏洩電磁波を測定してみた。
質問: 帯域制限をかけるとやりやすくなる、というのと、最初の、フィルタかけちゃうと見えなくなる、というのと違う気がするんだけどどうですか? 高周波成分を削って、下の帯域を取り出したことが効いていて、それは最初の発表とも矛盾しない結果だと思う。
質問: シャント抵抗のところ以外ではみていない? 抵抗の LSI 側のほうが、GND側よりいい感じだということがわかっている。抵抗のところで反射が起きていて、GND 側ではうまく拾えないのかもしれません。
質問 (座長): いまは線を巻いてやっているが、筐体の外部のような遠いところから拾えちゃう可能性は? 電源ラインは遠くまで伸びているので、そこで拾えるとすると脅威になりうる。
[ CryptMT の FPGA への実装 ]
eSTREAM phase 3 に残った暗号。
booter というのがあって、初期ベクトルと鍵で mother generator のシフトレジスタを初期化する。
Virtex-II Pro で 1800 スライスくらい?
スループットとしては 2GHz の Athlon64 よりちょっと速く、だいたい 3.9Gbps くらい。
質問: 高速化や省電力化で他のアーキテクチャで実装する、ということは考えられる? CryptMT については、いまは仕様書をほぼそのままでやっているが、シフトレジスタを減らしたりとか、そういうところを詰めていきたい。Trivium とか (いま 40LUT でやっている!) を並列化することは、まだこれからの課題。

FIT ’09: Session 2P

[ SHA-1, RC6 複合ユニットによる Share 検知 ]
弘前大の学生さん。
ファイル共有ソフトの使用を検知するシステム (Share というのはファイル共有ソフトで、Winny の後継らしい)。
NIC 上の FPGA (Altera) に実装する。
SHA-1 と RC6 を使ってヘッダか何かの magic number を検出して見つけるっぽい。
SHA-1: 1107LE, RC6:3754LE, Overall: 5123LE
Cyclone EP1C20F400C7
質問 (わし): いまのチップだと全体の面積の 1/4 くらい。市販の IP コアとは比較してない (探しておくれー)。
質問 (座長): アルゴリズムはこれ (例の番号の) が普通。足を引っ張っているのは SHA-1。通信データのばらつきはパケットのデータ長のばらつきが原因。パケット長 (ペイロード長) を判定する回路は含まれている。
[ パケットフィルタリング機能を搭載したNICによるDoS攻撃対策 ]
前橋工科大の方。
HTTP-GET flood 攻撃を FPGA な NIC で阻止したい。
Apache でフィルタするのではレイヤが高すぎて、マジメに攻め込まれたらしんどい。
そこで、Apache では攻撃の検出と source IP アドレスの特定をして、NIC のほうでパケットを落とす。
NIC 上の IP address blacklist は CAM とかを使い、サブネット単位とか何かで、わりとリソース使用を抑える方向でやりたいと思っている。
実装はまだしてない。
サブネット単位 (24bit) ならCAM なんか使わなくてもできそうだけどな。64k word x 256bit とかなら、2MB に収まるので、外付けの SRAM (18Mbit とか) がひとつあれば余裕でパイプライン処理できる。32bit 全部だと、512MB 必要なので、ちょっとしんどいな。
質問 (座長): blacklist の実装が問題。Aho-Corasick とか Hash とか?
質問 (わし): メモリのアドレスとデータのフィールドを巧く使えば簡単に実装できるんでは?
質問 (その他): NIC が IP レイヤをやるとかいうことではない。
[ P2P ファイル交換ソフトウェア環境 Winnyp を対象とした観測 ]
Winny でどんなファイル (種類、サイズ) が流通しているかのサーベイとか。
質問 (座長): Winny と Winny2 で流通しているファイルの内容の分布に差異があるのはなぜ? データ収集をした期間は一週間。ただ、データの重複を除いたりする作業に時間がかかる。
質問 (弘前大の方): 観測したノードは全体のどれくらいか: 観測するのに使うマシンを増やしていって、ノード数が飽和したところで打ち切った。
[ Packet Filtering Unitの評価 ]
弘前大パート II.
質問 (座長): 送信元ポート番号でフィルタするところが謎。でも、これは signature を圧縮するためらしい(どこか外で検知して signature つくるのか?)
質問 (前橋工科大): ホワイトリストを変更した場合は再合成が必要? yes.
[ 自己組織化マップによる不正アクセスの予測 ]
神奈川工科大の人。SOM ですよ!
Signature 型では登録データに基づいて判定をするので、亜種みたいなやつは検出できない。
Anomaly 型では「正常な状態でなくなった」ことを検出するので、false positive が多い。
Snort の定義を学習データにつかう。
ちゃんと ROC なんかも評価しており、なかなかちゃんとやっている気がする。適応型フィルタにもなれるしね。かっこいい。
質問 (わし): SVM とかはどうですか? SOMは教師なし学習ができることがポイントだと考えている。あと、視覚的に見せられるのも、人が監視するシステムに応用が利きそうでいいかなー、と。
[ 分散型通信制御セキュリティシステムの開発 ]
Linux で L2 filtering.
質問 (座長): 問題が発生したセグメントを落とすんだったら MAC アドレスごとにフィルタしなくてもいいんでない? L2箱だとネットワークの構成 (L3箱があるとか) によっては入れにくい?