メモリ操作の安全性を確保する、ANSI C規格準拠C言語コンパイラ 81
ストーリー by nabeshin
第2種基礎研究 部門より
第2種基礎研究 部門より
Nuisan 曰く、
数日前の話になりますが、産業技術総合研究所は4月11日、既存のC言語プログラムにメモリ操作の安全性を付与できるコンパイラ、「Fail-Safe C — release 1」を開発したと発表しました(産総研のプレスリリース)。プレスリリースや開発部門である情報セキュリティ研究センターの解説ページによると、既存のソースコードをそのままこのコンパイラに掛けるだけで、危険なメモリ操作の自己チェック機能を備えた実行可能ファイルが生成されるという仕掛けのようです。さらに、このコンパイラは、ANSI C規格に準拠しながら、厳密には規格違反だが既に一般的になっている様々な記述手法についても安全な範囲でサポートしているとのこと。
バッファオーバーフロー等、メモリ破壊が原因のソフトウェア脆弱性が後を絶たない現状ですが、こういうコンパイラが普及したら少しはそのような状況が改善されるのかなぁ、と期待します。このコンパイラはオープンソースでLinux対応だそうなので、C言語+Linux使いの皆様におかれましては、お手元のソースコードがこのコンパイラを通るかどうか実際に試してみるのも面白いのではないでしょうか。
技術解説 (スコア:5, おもしろおかしい)
#違うよ!全然違うよ!
Debian パッケージ (スコア:3, 興味深い)
Debian パッケージ [mithril-linux.org]の作成をカッとなってやった。 テストはまったくしていない。人柱を待っている
mmap() (スコア:2, 興味深い)
Fedora系列でビルドしたメモ (スコア:2, 参考になる)
必要なソフトウェアに追記していただくことを希望します。>中の人
× make-3.79.1-18 (Fedora Core 1)
○ make-3.81-7 (Fedora 7 update)
あと、/usr/include/gdbm/ndbm.h をうまく参照するようにチョコチョコと手を
加える必要がありました。configureを採用して解決してほしいところです。
runtime/stdlib/fscw/Makefile
INCLUDE = -I/usr/include/gdbm
tools/embedded-c/ec
my @includes = (); の後に push @includes, "/usr/include/gdbm"; を追加。
template/include/ndbm.h.ec
runtime/stdlib/fscw/ndbm.fscw
#include <gdbm-ndbm.h> ではなく #include <ndbm.h> が有効になるように改造。
コンパイラを通るかどうか試すといっても (スコア:1)
Re:コンパイラを通るかどうか試すといっても (スコア:1)
「コンパイラが通るかどうか試す」というくだりは、gccとか既存のコンパイラは通るけれども今回のコンパイラは通らないソースコードって(あるとしたら)どんなものなのかなぁ、という素朴な興味から書いたものです。言葉足らずですみません。
安全性の検証をしたいのならコンパイル後の実行時の動作まで見ないと意味がない、というご意見(で合ってますか?)には同意です。
Re:コンパイラを通るかどうか試すといっても (スコア:1)
Re:コンパイラを通るかどうか試すといっても (スコア:1)
void func(int n)
{
char ary[n];
の事では?
--- これは拡張ですね。
Re:コンパイラを通るかどうか試すといっても (スコア:1)
ライセンスが、"THE Q PUBLIC LICENSE"というよく知らないライセンスでした。
Qt用?オープンソース?
GPLとか修正BSDとかMITとか、もっと解りやすいライセンスのほうが良かった。。。
私が、Qtを使わないので知らないだけかもしれませんが
# 一応試してみようとしたのでこのツリー
Re:コンパイラを通るかどうか試すといっても (スコア:1, 参考になる)
日本語参考訳
http://www.kde.gr.jp/document/qpl.html
http://www.nslabs.jp/qpl-annotated-ja.rhtml
GPLや修正BSD、MITほどではないですが、KDE並には知られていると思うので、それほどマイナーでもないのではないでしょうか。
Objective CamlもQPLのようですね。
http://caml.inria.fr/ocaml/license.en.html
おそらく、それに合わせたとか、慣れていた、親しんでいたといったことがあるのではないかと推測します。
自己チェック機能のコスト (スコア:1)
ありそうなものですが、どの程度影響があるものなんでしょ。
リンク先を読むと実行速度の低下に対しての取り組みは行っているという記述がありますが、
サイズはどうなるのやら。
Re:自己チェック機能のコスト (スコア:1, 参考になる)
処理速度に関しては上記を参照。
Re:自己チェック機能のコスト (スコア:1)
を排除してアセンブラに近い効率を追求したプロ中のプロ向けの言語がC言語でしょ。
コンセプトが間違ってる。ウィザードを量産する方法を考えるべきだ。
# ANSIには当初賛同したが今は嫌いだ。Cの美しさを損なった。
Re:自己チェック機能のコスト (スコア:3, おもしろおかしい)
> を排除してアセンブラに近い効率を追求したプロ中のプロ向けの言語がC言語でしょ。
根性なしなプログラマ向けの高級アセンブラだと思ってましたが。
Re:自己チェック機能のコスト (スコア:3, 参考になる)
実装は、データにタグをつけて動的型チェックやレンジチェックをやります。
基本データ型やポインタが2ワードになるのが遅くなる原因の一つ。
unsigned int *p = malloc(10); /* pの内部表現は、ポインタ値と、char *型を示すタグの2ワード */
int n = (int)p;
(int *)n = -1; /* ここで実行時にエラーが出る */
(unsigned int *)n = 1; /* こちらは大丈夫 */
上記の例だと、静的な解析でエラーチェックができるけど、かならずしもそういう場合ばかりではないからね。
;; 今ごろプレスリリースかー
性能 (スコア:1, 参考になる)
> 将来的には、この値を2倍程度まで改善したいと考えており、静的解析やコード最適化などの改善を図っていきたいと考えています。
性能はあまり気にしないOpenBSDなんかに使ってもらえそう?
それなんてPurify? (スコア:1)
でも、大体そんな機能なのかなあと。
Re:それなんてPurify? (スコア:3, おもしろおかしい)
Purifyの恩恵を受けつつ、実行速度が1/5~1/3、
もう一声がんばって1/2程度で動いてくれるとしたら、
素晴らしいと思いませんか?
valgrind (スコア:1)
C++は? (スコア:1)
屍体メモ [windy.cx]
コンセプトはおもしろいと思うけど (スコア:1, 興味深い)
それらを100%近く使えない限り残念ながら研究室のオモチャの域は出ないんじゃないかなあと思います。
サポート予定のライブラリを見るとサーバ用途に特化するつもりなのかもしれませんけど、そういう分野では(安全性と引き替えにしてでも)性能が重要視されるわけですし。
Re:コンセプトはおもしろいと思うけど (スコア:1, すばらしい洞察)
#外向けは論外、内向けでも、ちょっとねぇ。
Re:コンセプトはおもしろいと思うけど (スコア:1)
安全性と性能の両立を目指しているということはないでしょうか?
Javaや.NETのサーバなら、それだけでもう安全性は確保できるのでしょうか
また、今回のコンパイラでビルドしたaprが使われるかどうかですが、
「そんなの使わなくてもaprは充分にセキュアだ。石橋を叩いて渡る必要はない」
という判断で採用を見送る可能性もあります。
石橋をいちいち叩いて渡ったりしない人は、安全性を犠牲にしていると思いますか?
Nyaboo
500の安全な標準関数 (スコア:0)
Re: (スコア:0)
教えてください (スコア:0)
gccあたり?それだとちょっと嫌な予感も…
Re: (スコア:0)
ソースはソースコード
そういえば、最近みないなぁ〜 (スコア:0)
lint (スコア:0)
Re: (スコア:0)
ソースレベルでのチェックは複数人で行うことをやめる必要はないよ。
「このコンパイラで通ればいいよね。」っていうリーダーがいたら、
そいつを放り出せ!
Re:lint (スコア:1)
プロジェクトリーダーがそれを止めにかかると、
そのプロジェクトリーダーは放り出されるのであった…
fjの教祖様
libsafe比較 (スコア:0)
Libsafeと比較して、これのメリットって何だろう。
Re:libsafe比較 (スコア:1, すばらしい洞察)
Libsafeは最もありがちな部分に対策をして効果はあるだろうけども、それですべてではないよね。
高木氏はどれくらい絡んでる? (スコア:0)
開発に絡んでいるのか、それとも完全に担当外なのか。
高木さんのブログでどのように評価してくれるのか。必要とあらば身内の制作物でも批判できるのか。
下世話ですが、高木さんの立ち位置が見てみたいです。
Re:高木氏はどれくらい絡んでる? (スコア:1, すばらしい洞察)
むしろ、なぜ、専門外の高木さんの名前が出てくるのかどうかが謎。
そりゃ、彼だってこの分野に関してはここの一般的な読者よりは遥かに詳しいだろうが、
あくまでも教養レベルの知識にとどまるだろう。
批判はできるだろうが、噛めるほどの知識はないんじゃないかな。
Re:高木氏はどれくらい絡んでる? (スコア:1, すばらしい洞察)
野次馬根性で始まり、身内の制作物でも批判できるかどうかなんて下衆の勘ぐりも甚だしいです。
関心をもつ動機として、野次馬根性を否定する気は無いけど、一応なりとも技術者が、
技術に対してミーハーな色眼鏡を通してしか評価しかしない事は、
技術者の立場向上を放棄するようなものです。
JW-10の開発者の弁 [goo.ne.jp]を読んで見てください。
ここでの主張に付け加えて、理系の中でも出世レースで知名度を得た一部の人間が全部手柄を持っていく、
末端でなくても個人個人が報われない仕組みがあるわけで、単純に文系が優遇されている訳ではありません。
一度、イチローがオリンピックに出なかった理由を考えて見ましょう。
下衆好みな話題に言及しておくと、
高木センセの守備範囲を考えると、これに名前出して絡んだりするリソースは無いかと。
IPA仕事もするようになった鵜飼さん [ipa.go.jp]のほうが、リバースの観点から守備範囲が近そう。
#実装者大岩さんの日記 [www.oiwa.jp]で言及がある [www.oiwa.jp]ように意見交換はしているらしい。
産総研/オーバフローで思い出すこと (スコア:1)
「ソースをみると、バッファオーバフローしまくり」
「いや、バッファの起点アドレスをランダム化してるから、コアは落ちても exploit は不可能」
「そーゆー問題じゃない」
というようなやりとりが、ひとしきり繰り返されて、
このあたり [delegate.org]で、修正されるに至った。(らしい)
という経緯を思い出してしまいました。
既にそのころは Delegate とおさらばしてたので、経過をいちいちフォローしていたわけではないが。
Re: (スコア:0)
いつも、もっと上のレイヤーでしゃべってますよね。
Re: (スコア:0)
今回の FAil Safe C は言語理論屋の成果であってセキュリティの泥臭い対策ではないから高木氏の出る幕はないよ。
Re: (スコア:0)
今後のご活躍にご期待ください (スコア:0)
批判の余地がない (スコア:0)
高木氏のいつもの矛先は、対策になってない対策とか、よけい悪くなる対策とか、なわけで、このコンパイラのアプローチに批判すべきポイントなんて存在しないのは自明でしょ。
速度低下が実用に堪えるかってくらいしか突っ込み所がない。「いいけど誰も使わない」的なことは言う人でないしね。
Re: (スコア:0)
うーん (スコア:0)
GCCと何が違うの? (スコア:0)
参考: スタック保護システム (ppt) [pacsec.jp]
Re:GCCと何が違うの? (スコア:1, 興味深い)
一方,このコンパイラは「メモリ操作に関する安全性を理論的に完全な形で保証している」(プレスリリースより引用)のが特徴だそうです.
# テストと検証の違いと同じ
Re:GCCと何が違うの? (スコア:1)
Re: (スコア:0)
しといて、コンパイル時に
とかすれば、これに近くなるの?
ちなみに、CentOS 5やFedora 8だと、デフォルトのコンパイルオプションが、
efenceとやることは同じ? (スコア:0)
Re:素朴な疑問 (スコア:1, すばらしい洞察)
>このコンパイラを利用することによる実行時の性能低下が許容できない場合だと、
>問題となる部分だけアセンブラで書いて、そこにセキュリティホールを作りこんでしまうような。
それによって、特にセキュリティに注意する個所をそこだけに絞れるとしたら、
全部普通のCコンパイラで動かすよりはマシなのでは。
# まあさすがにアセンブラはやりすぎとしても。
Javaにだって.NETにだってnative codeとの連携があるし。
>セキュリティに気を配るパワープログラマなら、
>こんな機能に頼らずとも既存のコンパイラ上で安全なコードを書くこともできよう。
世の中にセキュリティホールがあふれてる現状からして、
そんな「パワープログラマ」の降臨なんてまったく期待薄。
というかこの研究の主目的は既存のコードを再コンパイルしてセキュアにすることだし。
>人間が気付かない虫をコンパイラがなるべく発見しようという方針は、
>c言語の創案者たちが否定したんじゃなかったろうか。
Cの設計当初はプログラマを信用して効率を稼ぐって思想だったかもしれないけど、
30年たてば状況は一変どころか二変も三変もしているわけで。