パスワードを忘れた? アカウント作成
23416 story
プログラミング

メモリ操作の安全性を確保する、ANSI C規格準拠C言語コンパイラ 81

ストーリー by nabeshin
第2種基礎研究 部門より

Nuisan 曰く、

数日前の話になりますが、産業技術総合研究所は4月11日、既存のC言語プログラムにメモリ操作の安全性を付与できるコンパイラ、「Fail-Safe C — release 1」を開発したと発表しました(産総研のプレスリリース)。プレスリリースや開発部門である情報セキュリティ研究センターの解説ページによると、既存のソースコードをそのままこのコンパイラに掛けるだけで、危険なメモリ操作の自己チェック機能を備えた実行可能ファイルが生成されるという仕掛けのようです。さらに、このコンパイラは、ANSI C規格に準拠しながら、厳密には規格違反だが既に一般的になっている様々な記述手法についても安全な範囲でサポートしているとのこと。

バッファオーバーフロー等、メモリ破壊が原因のソフトウェア脆弱性が後を絶たない現状ですが、こういうコンパイラが普及したら少しはそのような状況が改善されるのかなぁ、と期待します。このコンパイラはオープンソースでLinux対応だそうなので、C言語+Linux使いの皆様におかれましては、お手元のソースコードがこのコンパイラを通るかどうか実際に試してみるのも面白いのではないでしょうか。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 技術解説 (スコア:5, おもしろおかしい)

    by Anonymous Coward on 2008年04月16日 15時39分 (#1331271)
    ここにいるバカにも優しく解説してくれている文章があったぞ

    「まず、ポインタ変数nを宣言するのね?」と、あたし。
    int *n;
    そしたら彼、「もうポインタ変数nに値5を代入していいんだぜ」
    *n = 5;
    「え、malloc関数とか使わなくていいの?」
    「大丈夫、*nが表す値と、お前のこと、オレ全力で守るから」
    あたし、泣いちゃった…。

    「Null pointer assignment 」アタシは死んだ。スイーツ(笑)

    ガッ シ、ボカ
    ケータイ小説的プログラミング [srad.jp]

    #違うよ!全然違うよ!
  • by Henrich (121) on 2008年04月17日 9時43分 (#1331766)

    Debian パッケージ [mithril-linux.org]の作成をカッとなってやった。 テストはまったくしていない。人柱を待っている

  • mmap() (スコア:2, 興味深い)

    by Anonymous Coward on 2008年04月16日 15時35分 (#1331267)
    mmap()が使えない時点で、現状のものは却下。
  • by ken3 (3270) on 2008年04月17日 13時04分 (#1331892) ホームページ
    古いmakeコマンドではコンパイルが通らず、新しいものに入れ替えたらOKでした。
    必要なソフトウェアに追記していただくことを希望します。>中の人

    × 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> が有効になるように改造。
  • コンパイルが通っただけじゃだめでしょ。実行時検査がメインみたいだから。
    • タレコミ人です。
      「コンパイラが通るかどうか試す」というくだりは、gccとか既存のコンパイラは通るけれども今回のコンパイラは通らないソースコードって(あるとしたら)どんなものなのかなぁ、という素朴な興味から書いたものです。言葉足らずですみません。

      安全性の検証をしたいのならコンパイル後の実行時の動作まで見ないと意味がない、というご意見(で合ってますか?)には同意です。
      親コメント
  • 実行ファイルのサイズが大きくなったり処理が重くなったり、何らかの副作用が
    ありそうなものですが、どの程度影響があるものなんでしょ。
    リンク先を読むと実行速度の低下に対しての取り組みは行っているという記述がありますが、
    サイズはどうなるのやら。
    • by Anonymous Coward on 2008年04月16日 16時14分 (#1331300)
      https://staff.aist.go.jp/y.oiwa/FailSafeC/status-ja.html [aist.go.jp]
      処理速度に関しては上記を参照。
      親コメント
    • > 自己チェック機能のコスト
      を排除してアセンブラに近い効率を追求したプロ中のプロ向けの言語がC言語でしょ。
      コンセプトが間違ってる。ウィザードを量産する方法を考えるべきだ。

      # ANSIには当初賛同したが今は嫌いだ。Cの美しさを損なった。
      親コメント
  • 性能 (スコア:1, 参考になる)

    by Anonymous Coward on 2008年04月16日 13時03分 (#1331109)
    > 実験したいくつかのベンチマークプログラムの項目について、平均的な処理時間は、通常のC言語コンパイラにより処理した安全でないプログラムと比べておよそ3〜5倍程度となっています。
    > 将来的には、この値を2倍程度まで改善したいと考えており、静的解析やコード最適化などの改善を図っていきたいと考えています。

    性能はあまり気にしないOpenBSDなんかに使ってもらえそう?
  • by tsubone (3599) on 2008年04月16日 13時10分 (#1331117) 日記
    …すみません、使ったこと無いですが。
    でも、大体そんな機能なのかなあと。
  • by Matthew (12158) on 2008年04月16日 13時25分 (#1331136) 日記
    valgrindとは違ったものが出てきてよいのではないですかね。 各工程の各所でテストができるというのはよいですね。
  • そこで cfront の出番ですか?
    --
    屍体メモ [windy.cx]
  • by Anonymous Coward on 2008年04月16日 22時19分 (#1331533)
    私もこういうものは作れないのかなあと脳内でずっと妄想だけしてたので、実際に形にしたことはひたすらすごいと思うんですけど、今どきわざわざC言語を選ぶのは既存の膨大なライブラリとかOSとのインターフェースを使うためですよね。
    それらを100%近く使えない限り残念ながら研究室のオモチャの域は出ないんじゃないかなあと思います。
    サポート予定のライブラリを見るとサーバ用途に特化するつもりなのかもしれませんけど、そういう分野では(安全性と引き替えにしてでも)性能が重要視されるわけですし。
    • by Anonymous Coward on 2008年04月16日 23時37分 (#1331596)
      安全性と引き換えにしてでも性能を重要視する、というスタンスで設計されたサーバを使うのは、怖いなぁ。。。

      #外向けは論外、内向けでも、ちょっとねぇ。
      親コメント
  • by Anonymous Coward on 2008年04月16日 12時43分 (#1331085)
    とてもありえない。

    • by Anonymous Coward
      Objective-Cみたいなものかもしれないよ?
  • by Anonymous Coward on 2008年04月16日 12時49分 (#1331089)
    このコンパイラのファーストコンパイルはなんでやったんでしょ?
    gccあたり?それだとちょっと嫌な予感も…
    • by Anonymous Coward
      OCamlぽいですね
      ソースはソースコード
  • by Anonymous Coward on 2008年04月16日 12時56分 (#1331096)
    lint
    • by Anonymous Coward
      こういうコンパイラが普及すると,ソースレベルでのバグが野放しにされる危険性もありますね.
      • by Anonymous Coward
        こういうコンパイラが普及しても、
        ソースレベルでのチェックは複数人で行うことをやめる必要はないよ。

        「このコンパイラで通ればいいよね。」っていうリーダーがいたら、
        そいつを放り出せ!

  • by Anonymous Coward on 2008年04月16日 12時59分 (#1331099)
    新しく○○にも対応した、とリリースされる度に再コンパイルする必要があることを考えれば、Libsafe [avayalabs.com]的手法の方が利にかなっている気がする。
    Libsafeと比較して、これのメリットって何だろう。
    • Re:libsafe比較 (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2008年04月16日 15時10分 (#1331236)
      ライブラリを置き換えたくらいで、すべてのバッファーオーバーフロー脆弱性が無くなるとでも?
      Libsafeは最もありがちな部分に対策をして効果はあるだろうけども、それですべてではないよね。
      親コメント
  • by Anonymous Coward on 2008年04月16日 13時12分 (#1331119)
    産総研でセキュリティといえば高木浩光さん [takagi-hiromitsu.jp]なのですが、Fail-Safe Cの担当には名前が出てないですね。
    開発に絡んでいるのか、それとも完全に担当外なのか。
    高木さんのブログでどのように評価してくれるのか。必要とあらば身内の制作物でも批判できるのか。
    下世話ですが、高木さんの立ち位置が見てみたいです。
    • by Anonymous Coward on 2008年04月16日 13時21分 (#1331130)
      プレスリリース他を見れば判るけど、技術的に全然関係無い話。
      むしろ、なぜ、専門外の高木さんの名前が出てくるのかどうかが謎。
      そりゃ、彼だってこの分野に関してはここの一般的な読者よりは遥かに詳しいだろうが、
      あくまでも教養レベルの知識にとどまるだろう。
      批判はできるだろうが、噛めるほどの知識はないんじゃないかな。
      親コメント
    • by Anonymous Coward on 2008年04月16日 13時53分 (#1331170)
      >産総研でセキュリティといえば高木浩光さん(以下略)

      野次馬根性で始まり、身内の制作物でも批判できるかどうかなんて下衆の勘ぐりも甚だしいです。
      関心をもつ動機として、野次馬根性を否定する気は無いけど、一応なりとも技術者が、
      技術に対してミーハーな色眼鏡を通してしか評価しかしない事は、
      技術者の立場向上を放棄するようなものです。
      JW-10の開発者の弁 [goo.ne.jp]を読んで見てください。
      ここでの主張に付け加えて、理系の中でも出世レースで知名度を得た一部の人間が全部手柄を持っていく、
      末端でなくても個人個人が報われない仕組みがあるわけで、単純に文系が優遇されている訳ではありません。
      一度、イチローがオリンピックに出なかった理由を考えて見ましょう。

      下衆好みな話題に言及しておくと、

      高木センセの守備範囲を考えると、これに名前出して絡んだりするリソースは無いかと。
      IPA仕事もするようになった鵜飼さん [ipa.go.jp]のほうが、リバースの観点から守備範囲が近そう。
      実装者大岩さんの日記 [www.oiwa.jp]で言及がある [www.oiwa.jp]ように意見交換はしているらしい。
      親コメント
    • 産総研産の Delegate [delegate.org] という、何でも Proxy サーバが、かつて、

      「ソースをみると、バッファオーバフローしまくり」

      「いや、バッファの起点アドレスをランダム化してるから、コアは落ちても exploit は不可能」

      「そーゆー問題じゃない」

      というようなやりとりが、ひとしきり繰り返されて、

      このあたり [delegate.org]で、修正されるに至った。(らしい)

      という経緯を思い出してしまいました。

      既にそのころは Delegate とおさらばしてたので、経過をいちいちフォローしていたわけではないが。
      親コメント
    • by Anonymous Coward
      高木氏はこういう技術的なというか、泥臭い方面での活動は少ないと思ってましたが。
      いつも、もっと上のレイヤーでしゃべってますよね。
      • by Anonymous Coward
        いや、どっちかっつーと高木浩光氏の方が泥臭いことをしゃべってるね。
        今回の FAil Safe C は言語理論屋の成果であってセキュリティの泥臭い対策ではないから高木氏の出る幕はないよ。
        • by Anonymous Coward
          まず、「泥臭い」の自然言語学上の定義からお願いしまつ。
    • 後で外から突っつくのが仕事ですから
    • by Anonymous Coward

      高木氏のいつもの矛先は、対策になってない対策とか、よけい悪くなる対策とか、なわけで、このコンパイラのアプローチに批判すべきポイントなんて存在しないのは自明でしょ。

      速度低下が実用に堪えるかってくらいしか突っ込み所がない。「いいけど誰も使わない」的なことは言う人でないしね。

    • by Anonymous Coward
      とりあえず高木浩光って言いたかっただけちゃうんかと小一時間 (ry
  • by Anonymous Coward on 2008年04月16日 13時24分 (#1331135)
    GNUのツールや*BSDのユーザーランドを全てコンパイルできるぐらいになるといいんですが。
  • by Anonymous Coward on 2008年04月16日 13時30分 (#1331144)
    GCCにはSSP [ibm.com] (別名: Propolice) が既に導入されていますが、これと何が違うのでしょうか。
    参考: スタック保護システム (ppt) [pacsec.jp]
    • by Anonymous Coward on 2008年04月16日 14時39分 (#1331220)
      他のコメントにも出ている, efence, SSP, valgrind(はちょっと目的が違うけど) などは「運が良ければメモリ破壊を防ぐことが出来る」システムです.
      一方,このコンパイラは「メモリ操作に関する安全性を理論的に完全な形で保証している」(プレスリリースより引用)のが特徴だそうです.
      # テストと検証の違いと同じ
      親コメント
      • by Matthew (12158) on 2008年04月17日 14時11分 (#1331937) 日記
        あ、テストじゃなくて証明が得られるのか。よく読まなかった X^D 使ってみよう。
        親コメント
      • by Anonymous Coward
        glibcだと、 FEATURE_TEST_MACROS [linux.or.jp]に_FORTIFY_SOURCE=2ってのが出てるけど、

        #include <features.h>

        しといて、コンパイル時に

        -Wp,-D_FORTIFY_SOURCE=2

        とかすれば、これに近くなるの?

        ちなみに、CentOS 5やFedora 8だと、デフォルトのコンパイルオプションが、

        -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-

  • by Anonymous Coward on 2008年04月16日 13時31分 (#1331145)
    実行速度が速いなら有意義かな。
typodupeerror

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー

読み込み中...