パスワードを忘れた? アカウント作成
42468 story
Google

Google、ActiveX対抗技術「Native Client」を公開 65

ストーリー by hylom
ActiveXの悪夢、再燃? 部門より

Googlee 曰く、

Googleが8日、Webブラウザ上でネイティブバイナリコードを実行する「Native Client」を公開した。同様の技術にはInternet Explorerで動作するマイクロソフトのActiveXがあるが、Native ClientはWindowsだけでなくMac OS XやLinuxでも動作するのが特徴。

Native ClientはランタイムとWebブラウザ用のプラグイン、そしてGCCベースのコンパイラから構成されており、SourceForge.JPマガジンによると

セキュリティでは、インナーサンドボックスとよぶソフトウェアコンテナシステムを利用して、静的な分析技術によりネイティブコードモジュールとホストシステム間で意図しないインタラクションの発生を防ぐ

とのこと。Native Clientは修正BSDライセンスで公開されており、対応プラットフォームはx86版のWindowsおよびMac OS X、Linux。対応ブラウザはFirefoxおよびSafari、Google Chrome、Opera。

オープンソースということで移植などは困難ではないかもしれないものの、ユーザビリティ的にもセキュリティ的にも、プラットフォーム依存のバイナリを動かすということが必要なのだろうか、とタレコミ子は思ってしまうのだが……。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by hohehohe (11394) on 2008年12月11日 1時02分 (#1471123)
    paperは読んでませんが本家のコメントによると [slashdot.org]

    - Win, Mac, Linuxで共通の44個のシステムコールを持つ
    - 既存のexecutableは使えない。再コンパイルしないといけない。例えばretは安全なものに置き換わる
    - GPUは使えない
    - 危険なコードはローダによってはじかれる
    - call gateを使ってる(・・・trampoline codeとかはよくわからなかった)
    - AMDの64bitにx86のセグメントはないのでこの手法は使えない
    --
    AVG anti-virus data base out of date
    • 利用できるAPI (スコア:2, 参考になる)

      by Anonymous Coward on 2008年12月11日 12時52分 (#1471365)
      このページ [googlecode.com]によると、Native Client(NaCl)から利用できるAPIは

       NewlibのC LibとMath Lib
       gccのstdc++ Lib
       Gecko/MozillaのプラグインAPIであるNPAPIのサブセット

      その他

       video、audio操作用のBasic Multimedai Interface
       NPAPI用の追加機能
       ブラウザとのやりとりをするためのSimple RPC

      それ以外に組み込みのランタイムコールとしてファイルIOとソケットなんかを提供するようだ。

      うーん、結構多いな。サンプルも見てみよう。
      親コメント
  • 脆弱性は? (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2008年12月10日 19時40分 (#1470978)
    またブラウザに穴を空けるようなことを・・・と思ってしまう。
  • by nezuku (25740) on 2008年12月10日 20時59分 (#1471013)
    他の多くのRIA技術との違いはx86プロセッサ上という制約が存在する点でしょうが、
    現状それでもどうにかなってしまうほどに、x86アーキテクチャが普及しているからこそできる手段ではありますね
    #考えようによっては、Atomをはじめとする携帯端末向けx86プロセッサを後押しする技術ではあるかも

    そうでなくとも携帯端末向けにはARM辺りのネイティブコードでOSを横断・・・といったこと考えられるでしょうが。
    • 他の多くのRIA技術との違いはx86プロセッサ上という制約が存在する点でしょうが、 現状それでもどうにかなってしまうほどに、x86アーキテクチャが普及しているからこそできる手段ではありますね

      x86 → x86-64 アーキテクチャへの移行途中なのに!

      またもや 64bit 普及に歯止めがかかってしまい、OS が 64bit でも IE と IE(32bit) を使い分け続ける状況が続いてしまうような気がします。

      それとも 64bit ブラウザから 32bit の Native Client コードを実行できるのでしょうか。

      親コメント
      • 64bit ブラウザから 32bit の Native Client コードを実行できるのでしょうか。

        これ、できそうな気がするんですが。
        x86-64は「バイナリレベルで後方互換」とかいってませんでしたっけ。うろ覚えしてるだけなので、あれですが…。
        64bitの良さは生かせないけど、制約になるほどのものでもない気がします。
        親コメント
  • ネイティブバイナリコードを実行する必要がある事というと
    ウイルススキャンソフトとかデフラグソフトとか
    そういったソフトをブラウザ上で動かすための、
    手段を提供するための布石に見える。

    段々、Googleが環境を整えてきている感がします。
  • by deaf_ear (31391) on 2008年12月10日 23時36分 (#1471080) 日記
    某所に納める時には、ActiveX、SSI、IIS関係禁止なんだよね。
    これはどうなんだろ。

    枯れた技術って何だろうって、最近思います。
    誰もが使えて、極一部であってもなじみがある。
    最先端は求めない。平易な技術が求められ容易に理解できることこそ重要。
    でも、その技術者、ノウハウのベース構築あって次があるのは間違いない。

    でも、平易に利用できるという部分で、
    今後も求められる技術基礎部分のレベルは上がるが、(たぶん)ユーザーにはよりよい利便性が提供される。
    その世界では、基礎技術者向けではないフレームワーク作りの負担が増えて、
    難度を上げーの、技術者蟻地獄の悪循環に陥ると。(予想)
    # 社会の教科書で時間がないから、近代史全部省かれて、独自で再勉強みたいな。

    どう、平易にすれば良いのでしょうね。
    皆さんの会社ではどうしているのだろう。そういう技術者教育。
    --
    がんばろう。と自分に言い聞かせる。
  • by Anonymous Coward on 2008年12月10日 20時13分 (#1470991)
    ActiveXもそうだけど、閉じた空間だけで考える分には便利だよな。
    マルチプラットホームなのが本当に利点となり得るかが疑問だけどね。
  • by n_ayase (36873) on 2008年12月10日 20時22分 (#1470997) ホームページ 日記
    Javaアプレットとどう違うんでしょう、機能的に。
    Windows以外でもOS依存のコードを動かせる、というだけ……?
    --
    神社でC#.NET
    • by Anonymous Coward
      軽くてJAVAアプレットやFlashの代替になるなら大歓迎。

      #JAVAは重いし、Flashも広告にやたら使われてて重いしバッテリ食うしウザイし、だからって無効にしたら表示できないサイトが出るし。
      • Re:うーん (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2008年12月10日 23時14分 (#1471075)
        >Flashも広告にやたら使われてて

        それだったらNative Client広告に切り替わって同じ悩みが再来するような・・・
        親コメント
        • Re:うーん (スコア:1, 興味深い)

          by Anonymous Coward on 2008年12月11日 2時22分 (#1471152)
          そんな無駄に手間のかかる広告は作らないと思います。作るとするならアドウェアであって、それには対策してある、と。
          プラットフォームの一つとしては興味深いし、閉じてないネットワーク上で利用するならどんなサービスが可能かとか面白いかもしれませんね。ついでに、そこに広告を紛れ込ませるならどこまでならOKか、もね。

          # Flashも今と昔のものではすっかり違うのに、同じ感覚で
          # アニメを要求してくる作成会社とか何とかならんかなι
          親コメント
      • Re:うーん (スコア:1, 参考になる)

        by Anonymous Coward on 2008年12月11日 8時45分 (#1471211)
        いつの時代のJavaお使いですか?
        親コメント
  • by Anonymous Coward on 2008年12月10日 22時07分 (#1471036)
    http://nativeclient.googlecode.com/svn/trunk/nacl/googleclient/native_... [googlecode.com]
    2.2. A Sandbox in a Sandbox
    Native Client is built around an x86-specific intra-process
    “inner-sandbox.” We believe that the inner-sandbox is robust;
    regardless, to provide defense in depth [12], [15]
    we are also developing a second “outer-sandbox” that
    implements isolation at the process boundary.
    The inner-sandbox uses static analysis to detect security
    defects in untrusted x86 code. Previously, such analysis
    has been challenging for arbitrary x86 code due to such
    practices as self-modifying code and overlapping instructions.
    In Native Client we disallow such practices through
    a set of alignment and structural rules that, when observed,
    insure that the native code module can be disassembled
    reliably, such that all reachable instructions are identified
    during disassembly. With reliable disassembly as a tool, our
    validator can then insure that the executable includes only
    the subset of legal instructions, disallowing unsafe machine
    instructions.
    The inner-sandbox further uses x86 segmented memory
    to constrain both data and instruction memory references.
    Leveraging existing hardware to implement these range
    checks greatly simplifies the runtime checks required to
    constrain memory references, in turn reducing the performance
    impact of safety mechanisms.
    • by Anonymous Coward on 2008年12月10日 23時56分 (#1471092)
      関数ポインタはどうするのかなあと思ったのだが、structural rulesでなんとかするのかな。
      内部表現が関数アドレスじゃなくなってたりして。

      誰か調べて教えてたもれ。
      親コメント
    • 訳したけど何だかさっぱりです。Java VMがバイトコードを実行するのに対して、これはx86コードを実行するんだというのが今のところの理解ですが合ってますでしょうか?

      Javaでもx86コードを実行できる(JNIではなくx86コードを理解するライブラリがある)ので、発想としてはそんな感じ??

      ---

      2.2.サンドボックス内サンドボックス

      Native Clientはx86特有の内部のプロセス"インナーサンドボックス"に構築されます。

      インナーサンドボックスは堅牢であると信じています。とにかく、徹底的な防御を提供するため、プロセス境界の分離を実装する第2の"アウターサンドボックス"も開発しました。

      インナーサンドボックスは、信頼できないx86コードにおいて、セキュリティーの問題を検出するために静的解析を利用します。
      以前から、このような解析は自己書き換えコードやオーバーラップ命令といったような慣習による不定なx86コードを課題としてきました。

      Native Client では、このような慣習を認めず、アラインメントと構造的なルールのセットを通し、それらが観測されたときは、ネイティブコードモジュールは信頼できるようにディスアセンブルされ、ディスアセンブルをする間に全ての到達可能な命令が特定されることを保証します。

      信頼できるディスアセンブリにより、私たちのバリデータは、実行可能コードは許可された命令のサブセットだけを含み、安全ではないマシン命令を禁止することを保証することができます。

      インナーサンドボックスはさらに、データと命令のメモリ参照の両方に制約を与えるため、x86のセグメント化されたメモリを使います。

      これらの範囲チェックを実装するために既存のハードウェアを活用することで、メモリ参照に制約を与えるために必要な実行時チェックを大いに簡素化し安全機構のパフォーマンスへの影響を減らします。
      親コメント
  • by shoji12 (14093) on 2008年12月11日 11時41分 (#1471305)
    GPhoneと同じで、Googleに都合の良い命令体系を持った、単純で高速なCPUの仕様を作ろうとしているのではないか?
    ブラウザ専用かつオープン仕様なCPU。汎用でなく高価でなくどの半導体メーカでも作れるCPU。
    みんなでコードを書けば必要十分な命令体系が見えてくる。
  • by Anonymous Coward on 2008年12月10日 19時12分 (#1470965)
    Native Client ですね。
    • Re:Native Code?Client? (スコア:3, 参考になる)

      by Anonymous Coward on 2008年12月10日 20時32分 (#1471004)
      結局はJavaの代替技術ですよね。大きな違いはJavaがクロスプラットフォームな中間生成コードを送るのに対して、完全にプラットフォーム依存なバイナリを送る(≒ActiveX)ってことで、技術的にはActiveXに近いですが、理念的にはJavaアプレットだと思えばしっくりきます。

      実はこれってアリなんじゃないかなぁ、と思います。Javaと比べてみると、最大のデメリットは、サーバー側のバイナリの量が増えることですが、オーサリングソフトがしっかりしていれば、あまり負担にはなりませんよね。ソース1つで[プラットフォーム数]倍のバイナリを吐くだけですし。実質的なダメージは、サーバーにおける容量に相当するもの(+キャッシュ)だけです。しかし、転送時は1ページビューにつき送る量は増えないどころか、むしろ減るので、現実的にはあまり負担になるとは思えません。そういう意味では、ユーザーにもウェブ開発者にもメリットがある方式ではないでしょうか。

      強いて言うなら、UAがプラットフォームの申告を偽った時におかしくなるくらいですが、GMailのようなAJAXは既にプラットフォームごとに違うスクリプトを送り込むことを余儀なくされているわけで、それに比べれば、まだマシというか、なんというか、きっちり動いてくれそうな気がします。ただ、いくらオープンソースでも、オーサリング(ウェブ開発者)が対応するプラットフォームを決めるわけですから、マイナーなOS/CPUは辛いですね。JavaやFlashと違って、単に移植できたから万歳というわけには行きません。それとも、ここへさらに仮想環境を咬ませるような複雑な時代へ突入するのでしょうか……
      親コメント
      • Re:Native Code?Client? (スコア:2, 参考になる)

        by bero (5057) on 2008年12月11日 3時21分 (#1471169) 日記
        >完全にプラットフォーム依存なバイナリを送る(≒ActiveX)ってことで、

        プラットフォームという言葉はCPU、ハードウェア、OSを含む言葉なので
        誤解#1471137 [srad.jp]を招いていると思います

        CPU(x86)依存だがOS非依存なバイナリというべきでしょう。

        ちなみにX Window Systemのグラフィックドライバや拡張機能も同様です。
        (コレと違って安全性チェックはありませんが)
        親コメント
      • >大きな違いはJavaがクロスプラットフォームな中間生成コードを送るのに対して、
        >完全にプラットフォーム依存なバイナリを送る

        という点ですが
        「Windowsでも、scons-out/nacl以下は同じで、Macと同様にFirefoxで問題なく表示できてますので、同一html/nexeでポータビリティありそうなのが確認できました.」
        http://b.hatena.ne.jp/takuma104/20081209#bookmark-11220424 [hatena.ne.jp]
        「takuma104さんのブコメ(引用者注:上の文章)によると、同じバイナリ (ELF フォーマット) が Mac でも Windows でもそのまま動いたとのこと。3.2 で書かれている、セキュア ELF ローダ (sel_ldr) とその先にあるランタイムで、プラットフォーム間の差異を吸収しているのでしょう。」
        http://blog.deadbeaf.org/2008/12/09/google-native-client/ [deadbeaf.org]
        という指摘がありますので「完全にプラットフォーム依存」なバイナリを送るものの、それを実行できないはずの環境でも「中間生成コード」のようになんとかして実行しちゃう技術なんでしょうか…?

        とりあえず、いいたかったのは、どうもバイナリも(主要部分は)共通らしいということなんですが。
        (でもランタイムみたいなものはやっぱりOSの数だけバリエーションかできるのか…。)

        たしかに、x86マシン同士ではOSなどが異なっていても、同じことをするプログラムなら、マシン語レベルでも変わらない部分があるはずなので、その差さえ上手く吸収すれば動いちゃうってことなんでしょうけど。本気で、それを考えることがすごい。(で、それが正直どうなってるのか、いまいち分からないんですが…。)

        でもこれ、趣味で「使ってみよう」というようなレベルでは、Javaとの違いは、NaClのが多少速いかもということと、書くとき使えるのがC/C++だということ、ぐらいでしょうか。
        親コメント
        • Re:Native Code?Client? (スコア:1, 参考になる)

          by Anonymous Coward on 2008年12月11日 7時43分 (#1471194)
          linux、Mac、Windowsそれぞれ用のミニOSがブラウザのプラグインとして用意されていて、
          そのミニOS上のx86バイナリが共通だということです。

          アイデアとしてはJavaからはっきり後退しているんですけども。

          > でもこれ、趣味で「使ってみよう」というようなレベルでは、Javaとの違いは、NaClのが多少速いかもということと、書くとき使えるのがC/C++だということ、ぐらいでしょうか。

          その通りですが、APIもリッチのようです。
          親コメント
      • しかし、Java の実行環境はクロスプラットフォームではない。
        • by Anonymous Coward

          Java の実行環境はクロスプラットフォームではない。

          意味がわかりません。実行環境がクロスプラットフォームなものって何ですか?
          • by Anonymous Coward
            お題目はともかく、そんなモノは存在しない。
    • by nekopon (1483) on 2008年12月11日 8時33分 (#1471205) 日記
      SourceForge.jp Magazine [osdn.jp]からして間違ってるのか! (誰か通報して
      親コメント
  • by Anonymous Coward on 2008年12月10日 19時31分 (#1470972)
    これはいかに
  • by Anonymous Coward on 2008年12月10日 19時37分 (#1470977)
    > セキュリティでは、インナーサンドボックスとよぶソフトウェアコンテナシステムを利用して、静的な分
    > 析技術によりネイティブコードモジュールとホストシステム間で意図しないインタラクションの発生を防
    > ぐ

    実行前デバッガー?

    # ちがうって…
  • by Anonymous Coward on 2008年12月10日 20時04分 (#1470989)
    研究レベルでは昔からあったよね。今さらという感じ。
  • by Anonymous Coward on 2008年12月10日 20時21分 (#1470996)
    ActiveXというよりも、Silverlightの対抗技術ですか?
    • by kyle (3923) on 2008年12月10日 21時08分 (#1471020) 日記
      むしろ Flash の対抗ではなかろうか。
      Google の真の competitor は、MS ではなく Adobe なのでは
      ないかと思う今日このごろ。
      親コメント
    • Re:今さら何を… (スコア:3, 参考になる)

      by Anonymous Coward on 2008年12月10日 22時23分 (#1471039)
      ローカルリソースにアクセスできるかどうかが、java Applet/ActiveXと、Silverlight/Flashの
      大きな違いなはずです。

      Native Clientはどうかとういうと、
      mootoh.log - Native Client [deadbeaf.org]
      をみてみると、やっぱしActiveXに近いような気がします。

      酔っぱらいでイキオイで投稿したので、間違ってても許してね
      親コメント
      • by Anonymous Coward on 2008年12月10日 22時56分 (#1471059)
        ActiveX + コード検証 + サンドボックスというところけ
        似たようなもんだからどれにも似てるのはしかたないな
        親コメント
    • by Anonymous Coward
      むしろAlchemyの対抗技術?
  • by Anonymous Coward on 2008年12月10日 22時38分 (#1471050)
    むしろ、超高速JVMを作ってくれたらいいのに。
    JNLP使えば、ブラウザの足かせから解放されるよ〜

    # まぁ、ブラウザはむしろ今は足かせと言うより
    # 使い込んだ靴みたいなものか
typodupeerror

192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり

読み込み中...