September 2009 Archives

Testing the latest GTK+-X11 (installed by MacPorts) on my MacBook, but opening particular windows take too long... I found this problem with my own application, but this is common to other GTK-based applications.

Last night I took a profile with GQVIEW, then found the most time consuming part is Pango. But... why?

UN council endorses nuclear curbs.

If we have guns, we'll fire someday.
If we don't have, we'll not fire.
We decided to choose the "option 2".
It's a memorial moment of humankind (in many aspects...).

BTW, what about the case we're fired upon?
That's what we're asked now.

小学校の同級生とばったり、電車の中で会った。
まあ、お互いずっと地元に住んでいるから、会っても不思議じゃないのだけれど。

いま南青山でフロリレージュというフレンチレストランをやっているのだそうだ。ちょっと調べたら、Hanako にも記事が出ていたりして、かなり人気が出ている模様。

いま振り返れば、彼は小学生の時から「僕はレストランをやるんだ！」と言っていて、それを貫き通したんだな、と思う。並大抵の意志では掴み取ることのできない夢だと思う。すごいな。

僕らも、いよいよ31歳です。
僕はちゃんと、なりたかった大人になれてるのかな。

そうそう、同い年の人がやっているお店といえば、京都烏丸御池の「あさきぬ」。こちらは、フレンチほど敷居が高くなくて、僕でも気軽に入れます。

土曜と月曜と。
土曜はへろへろの状態で大学行って、帰りは調子よかったので環八を飛ばして、遠回りして世田谷通りを回って帰宅。
月曜はぶっちぎりの状態で大学行って、国立でグレナデンソーダ飲んで、帰ってきた。吉祥寺から国立までは五日市街道を玉川上水ぞいに 45 分くらい。真っ暗であんまり飛ばせなかったからなので、昼間ならもっと速いかもな。帰りは甲州街道で、調布まで35分。

二日あわせて 67.39km @ 25.1km/h (2h40m50s) odo 7103.7km

ホテルが駅からめちゃめちゃ遠かったため、激しく遅刻。
到着したら、最初のセッションの最後の発表でした。

[ 小容量FPGAによるスケーラブルなシステム評価環境の構築手法 ]

M-Coreアーキテクチャ (すごくたくさんの manycore) を実装するためのプラットフォーム。小さい FPGA をたくさん使うことで、メモリポート数を稼いだり、いろいろ。
ScalableCore unit / board という2種類のボードを組み合わせて mesh 状のシステムを構成する。

100 core をシミュレーションするには100枚のボードが必要? (児玉さん) → いまのところ 1 core / 1 board がシンプルなのでそうしているが、今後検討したい。
configuration とか、メモリへの書き込みはどうしているのか (ふんがさん) → configuration はひとつずつ PROM に書いている。メモリは BlockRAM に初期値を書いたり、次のバージョンでは SD カードから読み込める。

たのしそう...

[ An FPGA-based Tiny Processing System for Small Embedded System and Education ]

TinyCPU: Verilog で 200-300 行くらい。
レジスタは持っていない。完全にスタックアーキテクチャ (逆ポーランド記法で書けばなんでもできるので、コンパイラが簡単に作れる)。
やっぱり授業は大変らしい。

[ メニーコアSoC用形状適応型ネットワークオンチップの検討 ]

256 nodes で Crossbar-Torus 混成網とか。上位が torus で、下を mesh とかにする。

16 cores の中と外をつなぐところはどうなっている? crossbar なら 16+4 (東西南北) で 20x20? (吉瀨先生) → どうやらちがうらしい。外に出るところは MUX/DEMUX があるのか...

mesh mode と crossbar mode があるらしい。crossbar mode だとびゅーっと速く通過できる。局所性を利用するというよりは、低電力な mesh (バケツリレーしないといけない) で性能が足りなくなったら、crossbar (通過できる) に切り替えて高速に動かそうということだそうだ。

[ ネットワークテストベッドGtrcNET-10p3におけるパケットキャプチャおよびルータ機能の実装 ]

バンド幅や遅延をかえて、ネットワークシステムの性能評価をするためのシステム。あるいは、高精度なバンド幅測定やプロトコルのデバッグをすることもできる。
10GbE を XC2VP100 に soft core で実装。まじか。
DDR-SDRAM を 166MHz 裏表で動かすのは大変だそうです。

キャプチャフォワード:
実質的にサイズ無制限のキャプチャがほしいが、目的によってはペイロードは保存しなくてもよく、ヘッダ部分だけあればよい。3 ポートあれば、2ポートの間のヘッダだけを抽出して残りの1ポートから外に出せる。

関連研究の紹介:
NetFPGA, BEE3 など。

データのサイズが大きくなさそうなので、SRAM のほうがよさそうですがどうでしょう (吉瀨先生) → 遅延を入れたりすることを考えると、パケットをためておく必要があるので、充分なサイズが必要。1GB くらい。

[ 再構成デバイスMPLDの高密度実装に適した構成手法 ]

弘中研の学生さん。
メモリにもなる LUT を使った PLD. 高密度に実装できるところがポイント。
配置配線ツールとかもちゃんとある。

チップはフルカスタムで作った？ (ふんがさん) → ほぼ手作りです。でも、規模が大きくなりすぎて検証できなくて、ちゃんと動かなかった。アナログ設計なので、nanosim なんかでシミュレーションしても不定値になるところがわからなかったりする。

[ LEDR/4相2線プロトコルコンバータを用いた非同期FPGAの構成 ]

FPGA はレジスタが多いので、クロック分配が大変 (電力食うし) 。じゃあ非同期にしましょう、というお話。
4相2線は小面積なので、演算器に向いており(FPGAはビット幅が自由なので、束データ方式は使いづらい)、LEDR (Level-Encoded Dual-Rail: 2相2線方式の一種) は長い配線に向いている (4相2線はデータ間にスペーサが必要だが、LEDRなら不要。ただし、回路的には面倒) 。
プロトコルコンバータをいれればいろいろ作れるんだな。かっこいい。

4相2線の場合はスペーサになるときに、すべてのロジックが 0 になったことを確認しないと、過渡的にへんな信号が出ることがあるので、気をつけてください (名古屋先生)
Switch block や connection block 間の配線のすべてのトラックは data x 2 + ack の3本のセットになる? つまり普通の FPGA の3倍配線が必要? (渡辺先生@岡山大) → はい。

[ レンズ結像系を用いない4コンテキストプログラマブル光再構成型ゲートアレイ用ライター ]

渡辺先生@静岡大の学生さん。
レンズを使わないで、反射型ホログラムとレーザーだけでいけるものを検討中。レンズで位置を補正できないので、回路構成情報に位置補正情報を埋め込んでしまう。

横から出す方のレーザーは位置あわせが必要? ビーム径は？(弘中先生) → SPD のサイズをあまり小さくすると感度 (というか応答時間) が下がるので、それをカバーできるくらいのものを考えている。パッケージの組み立て精度は充分に出るという前提で、パッケージをライターに入れたときは精度が怪しいから、そこを補正しようということを考えている。

[ FPGAによるHPCのためのストリーム計算に関する一検討　～ 2次元ヤコビ法のためのスケーラブルパイプラインモジュールの設計と評価 ～ ]

Many core とかではメモリのバンド幅がボトルネック。FFTなんかはまだマシだが、計算密度が低いステンシル計算などではピーク性能の半分もでない。ものすごく長いパイプラインを作ってストリーム処理すればいい? でも、そんな都合よくいくかしら。
ステンシル計算なら、平面上の4近傍を見て計算してそれを次のタイムステップで使って・・・というところで計算密度が稼げる。
データストリームの場所場所で必要なバンド幅は異なる。しんどいところにデバイス境界がこないようにしないといけない。そうだよなあ... ここの設計手法が鍵になる気がする。

どれくらいのバンド幅が出ればいいのか、いまので充分なのか (中條先生) → 5GB/sec くらいは実現可能。メモリより太いチップ間の転送バンド幅があればいい。
2次元ヤコビ法ではうまくいきそうだけど、一般化して GPU に勝つ方向ではがんばれる? マルチチップの設計環境とかメモリの抽象化とかができるといいなあ (ふんがさん) → GPU は scale できない気がするので、性能的には勝てるかも。

[ 高精度浮動小数点演算用リコンフィギャラブルアクセラレータに用いる数学関数の実装手法に関する検討 ]

8倍長精度のアクセラレータ HP-DSFP を提案。
CORDICを使いたいけど、ビットシフトができない。ざんねん。多項式近似するぜ。

三角関数の計算には数千クロックかかるのか。むー。
8倍精度はやりすぎな気もしますが、こういうのがあってもいいね。

[ An FPGA-based Architecture for Verifying Collatz Conjecture ]

コラッツ予想: 偶数のときその数を2で割り、奇数の時3倍して1を加えると、任意の正の数が1になる。でも証明はされていない。

僕、昔それをやってたんですけど知ってますか (市川先生) → どーん。

こういう問題は、相手が無限大だからなあ。。。

[ FPGA を用いた回転パターンの実時間検出 ]

丸山研のひと。
FFTとかをして比較するのではなくて、回転・拡大縮小されたパターン画像との直接比較を考える。今回は拡大縮小は考えない模様。
相互相関関数をいっぱい計算するので、そこの計算量を頑張って減らしている。
VGA で 410fps, Full HD で 61fps.

- 理論的に誤差がどう、ということより、「検出できればよい」という方向だとどうか。回転の刻み角を減らしたりとか?
- ゆがみの検出とかにも適応できる? → このやり方ではむり
- 回路のうちデータを保持しておくところが大きいと思うけど、回路量のうちメモリの占める割合は? → 全部 LUT 内部でやっており、メモリは使っていない。

[ ロジックエレメントを節約したFPGAラベリング ]

ラベリング: 2値画像の連結成分の、島ごとにユニークな ID を割り当てる。
1 clock / pixel で FPGA に入力するとする。FPGA 内部に保持するのは数行分で、全部のデータを待たずに出力する。ただし、これだと数行掘り下げたときに島がくっつくかもしれないので、入力画像について制約をかける必要はある。

ある程度離れたところでつながっているものについてはあきらめちゃう、ということだが、実アプリで 20-concave というのはどうなのか (堀先生) → スキャンした文字とかだと、わりとこれでもいいかな、という感じ。
うずまきキャンディとか櫛みたいなものがベンチマークの絵で出てくると思うけど、どうでしょう (丸山先生) → 20pixel に入れば... デジタルカメラとかで、コストをかけずに何かの前処理としてラベリングができればいいかな (つまり、ラベリングがメインではないアプリケーションへの適用) と思っている。

[ FPGAアレイCubeを用いたレーベンシュタイン距離計算の性能評価 ]

よしみさんの発表。なんか元気そうで、何よりです。

Cube: XC3S4000 の一次元接続。
8x8 の短い部分文字列についてスコアを計算するモジュールをひとつの FPGA に 16 個。
CellとかGPUと比較。
パイプライン稼働率は 20% くらい。電力効率は 10〜100倍くらい。

パイプライン効率があまり上がらないのはなぜ (中條先生) → 100%出るのが対角線のときだけなので... たくさんデータセットをなげればいい。
データセットのサイズに上限はあるのか (児玉さん@AIST) → 上限はないのだが、いくつかに分割して実行しなければいけなくなる。配列長に対して実行時間の増加は linear.

[ FPGA による電源電圧制御回路の実装および制御精度の評価 ]

そえじーの発表。

ディジタル制御な DC-DC コンバータによる、データセンタとかでの DC 給電が目標。
FPGA で PID 制御をする。DC-DC converter にはどれくらい演算精度が必要か、とか。

100MHz のクロックの位相をずらして 400MHz 相当の時間分解能を手に入れた!
演算自体は4クロックで終わる。

アナログ制御の DC/DC と較べるとどうかは評価しているか (児玉さん@AIST) → PID とかよりもっと難しい (アナログではできない) 制御をやる予定なので、デジタル前提です。

いいね。

[ 配線性を利用する低消費電力指向のクラスタリング及び配置手法 ]

クラスタ外の配線をなるべくクラスタ内に取り込む方向でがんばる。
LB 間の配線数を気にしながら集めていく。

消費電力が改善したのにクリティカルパス遅延が悪化したのはなぜか。どういう状況 (谷川先生) → クラスタ段数が増えちゃうところがあるから?
配置配線にかかる時間は遅くなっているのか (ふんがさん) → あまり変わりません。

[ 実装効率改善へ向けたP同値類に基づくLUTの論理出現率に関する調査 ]

FPGAは柔軟だけど、回路によっては使われない論理ブロックがあったりもする。
でも、完全な論理表現能力がなくてもいいじゃない？

P同値類: (3入力以上とかで) 入力の順番を入れ替えると同じ関数になるもの。

これを使うと、論理関数表現から P-representative 表現にすることで、
3入力: 256 pattern / 8bit → 80 pattern / 7bit
4入力: 64k pattern / 16bit → 3,984 pattern / 12bit
のように必要なメモリ量を縮約できる。

一方でマルチプレクサや配線領域が増加することが問題。
論理関数の使用時における偏りを利用できないか?

MCNC benchmark を 117 種類、2つの異なるテクノロジマッピング手法を用いて評価。
最大105種類のP同値類。35% くらいの論理関数が P 同値類をもつ。

なかなかおもしろい。

k が大きくなるとより有効そう (弘中先生) → がんばります
6入力だけど6入力全部使わないものとかもあるわけで、そういうのをもう少し細かく分けてみたらもっといいかもしれない (児玉さん)

[ 電力を再構成可能なFlex Power FPGAチップの設計と試作 ]

Flex power FPGA の新チップ。動いてる。しかも CAD も!!
チップは 90nm.

設計はどうやっている? (ふんがさん) → 自動配置配線はまったく使っていません (!!!)
チップ製造後のテストはどうやりました? (飯田先生) → 業者に出してテストもしたけど、自分たちでやったのと違う...
製造前の見積もりと現実の違いは? (谷川先生) → 1/10 くらいになるはずだったけど、半分くらいになってしまった。速いトランジスタだと Vth 変更の効きが悪いとか、いろいろあるけどこれから検討。
動くことは確認できたわけだが、集積度が普通の FPGA に負けないこともポイントだと思う。そのへんはどうか (児玉さん) → やっぱり overhead は大きいかも...

[ Dual-Vthセルの利用による動的リコンフィギャラブルプロセッサのリーク電力削減の評価 ]

[ YAWARA: 自己最適化計算機システム・プロジェクト ]

実行前最適化処理 (コンパイラとか) の限界。複数のプログラムの同時実行や、入力データによる挙動の変化をカバーすることができない。
ユーザ透過な形で動的な最適化をすることができないか?

メタレベル計算原理に基づく柔構造計算機: プログラムの実行と並行してその挙動を把握し、その履歴に基づいて将来を予測して計算機を造り替える能力をもつ計算機。

最初は FPGA とかでやろうと思っていたが、VLIW でたくさんスレッドを走らせる方向に行っている、とのこと。それが正解だと思う。

しかし、こういうのは意外と楽しそうで、発表を聴けてよかった。

Today I had 20+ PCs to run Microsoft Update :(
I've found that one of them can't download any update modules (while it can show the list of updates). This is because winhttp's proxy configuration (it's separated from wininet's proxy configuration that we can manage from the "Internet Options" dialog) was broken.
There's no GUI to configure winhttp's proxy setting, but "proxycfg" command does... and I have done.

Strange strange Windows...

Movable Type をやっと新しくしました。
うごけー。

打ち上げ成功おめでとうございます。
無事に ISS にドッキングしてくれるまでは、気が抜けないんでしょうけれど。

実は友人が HTV の設計に携わってました。
自分が作ったものが宇宙にいく、というのはどんな感じなんだろうなあ。
いいね。

今日はちょこっとトレーニングしてから出勤。
15km 全力で走り、15km 適当に走って大学。帰りは 10km。

最初の 15km はいつもの多摩川で、視界に入ったロードレーサーはいつもどおり、全部追い抜いた。
調子はまあまあだと思うが、乗ったあとときどき膝が痛むので、しばらく慎重にいこうと思う。

37min17s, HR average 165, peak 193, T/E 4.5
57min21s, HR average 155, peak 187, T/E 3.7

50.72km @ 27.3km/h (1h51m07s) odo 7036.3km

昨日と一昨日で、ぐぐっと研究が進んだので、今日はのんびり。
荷物を減らしてウエストポーチひとつにまとめ、自宅から一度多摩川に出て、いつものトレーニングコースを 15km 走り、調布までは戻らずに、天文台の脇を登って職場へ向かうルート。

それで、自宅から職場までは電車と徒歩で 90 分、自転車でまっすぐだと 35 分なのだが、このルートでくると 90 分だということがわかった。電車は雨と荷物が多い時以外、全く役に立たないというか、そういう感じだ。

久々に乗った上に、荷物が重たくて、しんどかった。
帰りは調布飛行場のほうをぐるっと回って、帰宅。

25.7km @ 23.8km/h (1h03m16s), odo 6985.6km

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

[ よしみさん ]

なんか、発表順が大幅に変わってて、質疑応答だけきいた。すいません。

レーベンシュタイン距離を 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 圧縮と同じくらいのスループットで、メモリや回路面積はだいぶ小さい。圧縮率は同程度。
まあ、半分にはなるんだけど、結局その大量のデータをどうするかが問題だそうです。

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

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.

組み込み。

[ 多機能コンセントのスケジューリング機能による待機電力の削減 ]

多機能コンセント: 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 が使えない?

実行時間計るなら、プロファイリングくらいしてほしかった...

[ 周波数領域での暗号モジュールの電力解析 ]

東北大。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 でやっている!) を並列化することは、まだこれからの課題。

[ 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箱があるとか) によっては入れにくい?

Currently distributed version of tuntaposx doesn't compile on 10.6, but the patched version is available at: http://marianmi.comp.nus.edu.sg/downloads/. Great work.
I've replaced /Applications/Tunnelblick.app/Contents/Resources/{tun,tap}.kext with this, and now TunnelBlick is running. Great.